Ces concepteurs qui ignorent les utilisateurs…

Petit billet sous forme d’un coup de gueule sur le je m’enfoutisme des applications web de certaines enseignes. En effet, il n’y a rien de plus pénible lorsque l’utilisateur doit mieux connaitre le système de gestion que le fournisseur de service…

La mésaventure

Plaçons le contexte : je veux faire une réservation d’Hôtel sur le site de Disneyland Paris. Ben oui, c’est bientôt l’anniversaire du petit. 3 ans, grand bonhomme… Bon, on ne va pas polémiquer que le fait que le site soit en Flash, que je referme le MacBook pour y aller via le Linux, le tout avec une vélocité qui donnerait sa chance à un Ent lors d’un marathon… On y est, allez, on choisi l’Hôtel Cheyenne, un village de Cow Boys. Et nous voilà devant ce fameux formulaire…

Alors personnellement, j’ai l’habitude de remplir vite les informations les plus simples. Alors donc une nuit, 2 adultes et un enfant (un enfant a de 3 à 17 ans, en dessous c’est un bébé). Ben oui, on ira certainement après l’anniversaire du petit, il aura 3 ans révolus. Ah, après la sélection de l’enfant, un nouveau champ s’affiche : il faut saisir sa date de naissance. Ok, mettons premier août 2008 (si vous souhaitez retenter cette manip’, utilisez par exemple le premier du prochain mois de l’année d’il y a 3 ans). qu’est ce que je n’ai pas saisi là…

Disneyland et la saisie de la date de naissance.

La conséquence de la saisie de la date de naissance.

Comment ça la date de naissance n’est pas valide ? Et ma saisie est effacée maintenant ?

Mais qu’est ce qui s’est passé ?

Oh ce qui s’est passé doit être tout simple car la même chose se produit si vous demandez une date d’arrivée disons au 6 aout (premier week end suivant l’anniversaire du petit), que vous saisissez les champs puis que vous changez la date d’arrivée pour juillet. L’erreur en elle même est logique (on déclare un enfant qui sera un bébé à cette date). Quand on ne saisit pas la date, le système doit avoir un comportement très bête pour suivre une logique de validation des données. En effet, l’habitude de programmation des formulaires web impose une validation de la saisie, procédure compréhensible du fait que le système doit s’assurer s’avoir des données qu’il peut traiter. Il faut donc valider qu’il s’agit d’un enfant et donc comparer sa date de naissance à la date d’arrivée. Or en absence de date d’arrivée, la date d’arrivée par défaut doit être définie à « aujourd’hui », date de saisie du formulaire.

En quoi c’est énervant ?

Pour une raison toute simple : le site Disney me demande de qualifier la personne (adulte, enfant, bébé). Ok, c’est donc déjà moi qui fait le travail d’analyse. Ensuite je dois confirmer cette affectation par une date de naissance… Mais c’est un dialogue de vente ou un examen de maths ? Si je me suis trompé d’affectation (si je change les dates), je dois tout saisir à nouveau sur l’autre affectation. Bref on est non seulement face à un système de validation de saisie complètement passif qui laisse l’utilisateur tout faire à sa place, mais aussi soumis à une « punition » de son erreur et doit saisir tout le formulaire à nouveau.

Quelle solution aurai été préférable ?

Pour une simple question d’usabilité, être moins intrusif. Une fenêtre modale qui apparait pour me dire que la saisie est mauvaise, nécessitant d’aller la fermer, associé à l’effacement des champs saisis, on est vraiment face à une punition imposée au client. Surtout qu’il est dans une phase de saisie, on exige que tous les champs soient cohérents dans l’ordre de saisie… Une approche un peu vieille aurai été de valider la saisie et alerter uniquement au moment où on sélectionne réserver, ce qui envoi le formulaire et fait changer de page. Là on est certain que a saisie n’est pas cohérente.

Mais aujourd’hui, on veut un peu plus de dynamisme. On veut de la réponse en temps réel. Il faut avertir l’utilisateur en temps réel. Ok, pourquoi pas, mais pas de manière intrusive. Un simple message d’avertissement qui apparait à coté du champ et disparait lorsque les champs sont cohérents est préférable à interrompre une saisie de l’utilisateur et lui effacer sa saisie.

Mais le plus énervant, c’est de tout faire à la place de la machine. Elle me demande de qualifier les clients, ok, mais pourquoi me demander la date de naissance ? Pour vérifier la validité de la saisie ? Mais dans ce cas là, prend le relais, au lieu de dire « bon » ou « pas bon », à la fin de la saisie, affecte les personnes dans la bonne catégorie, tu a toute l’information et les règles de gestion qu’il faut. Pourquoi donc est ce encore à l’utilisateur de faire le travail d’automatisme ?

Disney, un cas isolé ?

Pas du tout. Ce cas de gestion d’age de l’enfant est un grand classique. Ceci peut aller jusqu’à l’impossibilité de finaliser un achat en ligne. C’est le cas par exemple pour les achats de billets d’avion. En avion, un enfant de moins de deux ans est un bébé qui voyage sur les genoux d’un adulte et paye peu chère. Au dela, c’est un enfant qui paye un peu plus chère et qui a sa place assise. Sur le site d’Opodo, où la mésaventure m’est arrivée, la saisie est similaire à celle de Disney. On sélectionne le tye de passagers, les dates, le départ, l’arrivée. Le système nous propose des voyages et une fois sélectionnés, on précise certaines informations, comme les dates de naissance pour les enfants/bébés… Lorsqu’on a un vol aller avec un bébé qui fêtera son second anniversaire sur place, et donc qui fera son vol retour en tant qu’enfant… Et bien il est impossible de réserver un aller-retour. Et oui, l’age n’est pas correcte pour l’un des voyages. Évidemment, on comprend que le problème vient du dialogue de vente en lui même. La saisie de la date de naissance, donc la vérification de l’âge, n’est réalisée qu’après avoir réservé des billets, billets choisis en fonction d’une déclaration d’une catégorie d’âge. Alors il y a bien une alternative : ne pas prendre d’aller-retour mais un aller puis un retour (avec le risque de se voir rafler les places).

Bref, l’utilisateur se retrouve donc à faire le travail du système à cause d’une définition foireuse du dialogue de vente.

Quand la meilleur offre n’est pas la meilleur offre.

Ces cas sont pénible pour l’utilisateur qui doit donc faire le travail du système. Mais cela peut aussi avoir de réelles conséquences financières sur l’utilisateur. Prenons un cas classique, celui de la SNCF. La SNCF a un système de tarifications dont la compréhension peut inspirer de nombreux sujets de thèse. Un guichetier doit en général connaitre ces offres et sait vous les proposer. Mais si on passe par leur agence en ligne, le site voyages-sncf.com, qu’est ce qui nous est proposé ? Prenons un Paris Marseille pour 3 adultes et un enfant (notez que cet exemple n’est pas directement reproductible car dépendant des offres, mais se reproduit). Le meilleur prix semble donc être 339,50 € n’est ce pas ?

Et bien non. Le meilleur prix est en réalité de 262,50 €…

Tarifs sans carte

Tarifs SNCF sans carte

Tarifs avec carte.

Tarifs SNCF avec carte.

Alors en fait, non pas tout à fait. Ce tarif est accessible avec une carte Enfant+, tout à fait éligible dans notre situation. Cette carte coute 70 €, ce qui fait que le cout réel est alors de 332,50 €. Évidemment, la différence est moins importante, mais en ces temps de crise, elle paye un sandwich (pour 4). Cette possibilité, le système ne la propose pas alors que là aussi il a toutes les informations en main. Pour voyages-sncf.com, pour bénéficier des meilleurs tarifs, il faut connaitre l’ensemble de leurs offres marketing et faire directement le choix au lieu d’y être dirigé.

En conclusion

Ces trois exemples sont typiques d’applications qui chargent l’utilisateur des taches que pourrait faire le système. Bon, je suis un peu dur avec Voyages-SNCF.com car dans leur cas, il faudrait interroger toutes les possibilités, ce qui représente d’une part une charge qui dégraderai la navigation, et d’autre part qui complexifierai la proposition (mais nous somme dans le cas d’offres complexes). Dans les autres cas, il y a clairement un problème de gestion des données et du métier. En effet, si nous reprenons les dialogues de vente, l’utilisateur doit qualifier les clients (adulte, enfant, bébé). Mais comment les qualifier ? Pour les compagnies aériennes, la transition est à 2 ans, pour Disney, c’est 3… Sachant que la date anniversaire sera demandée, pourquoi ne pas simplifier le dialogue : soit saisir les dates de naissance pour tous ou choisir entre adulte et mineur et saisir la date de naissance des mineurs, le système s’occupant de qualifier en enfant ou bébé…

Bref, il est temps que les concepteurs qui s’occupent du métier s’intéressent à l’usabilité de ce qu’ils produisent. S’inquiéter d’avoir toutes les informations pour les traiter, c’est bien. S’inquiéter de la manière de les obtenir, c’est mieux.

Et vous, y a il des sites qui vous irrite de la sorte ?

À propos de... Darko Stankovski

iT guy, photographe et papa 3.0, je vous fais partager mon expérience et découvertes dans ces domaines. Vous pouvez me suivre sur les liens ci-dessous.

Vous aimerez aussi...

Laisser un commentaire

En naviguant sur Dad 3.0, vous acceptez l’utilisation de cookies pour une navigation optimale et nous permettre de réaliser des statistiques de visites. Plus d'informations

Le blog Dad 3.0 utilise les cookies pour vous permettre une navigation optimale et nous permettre de réaliser des statistiques de visite. Dad 3.0 affichant des publicités, celles-si utilisent également des cookies pour un ciblage publicitaire. En continuant la navigation sur Dad 3.0, vous acceptez le dépôt et la lecture de cookies.

Fermer