Analogie entre l'ergonomie des logiciels et la conception d'un self service
L’ergonomie des restaurants, c’est un peu comme l’utilisabilité des logiciels : à tarif et service identique, la différence est dans la manière dont l’implémentation a été pensée en amont. En déplacement ces deux derniers jours, j’ai eu l’occasion de tester deux self services proposant deux approches totalement différentes d’un même métier.
À ma gauche, une cantine d’entreprise traditionnelle. Le parcours utilisateur est industrialisé et normalisé selon un workflow parfaitement rationnel, et à mon avis, totalement répulsive :
- Plateaux.
- Verres.
- Couverts.
- Entrées (jusqu’à 3 items avec les desserts).
- Fromages / Desserts.
- Plat chaud.
- Boissons.
- Caisse.
- On mange.
- Dépose des couverts dans un bac dédié.
- Dépose du plateau sur un tapis roulant.
Notons qu’il est possible de revenir chercher quelque chose que l’on aurait pu oublier. Cependant, la disposition des lieux et certains éléments (carte d’entreprise à usage journalier unique au lieu d’un système de points), et la nécessité de refaire tout le parcours à chaque fois montrent qu’il s’agit d’un contournement du processus qui a été pensé pour être déroulé dans son entier en une seule fois.
À ma droite, le restaurant de l’hôtel. Le parcours utilisateur y a été pensé de manière radicalement différente et, toujours à mon sens, beaucoup plus accueillante. Même si, nous le verrons plus tard, cela ne va pas sans introduire quelques problèmes.
La chaîne commence également par la récupération des plateaux, qui reste dans les deux cas le pré requis incompressible. Puis les choses changent d’une manière assez subtile pour être mentionnée.
Les différents éléments du repas sont également rassemblés par thématique, mais pas dans le même ordre :
- Entrées.
- Plats chauds.
- Fromages / Desserts.
- Boissons.
Ici, les couverts ne sont pas rassemblés en tête de ligne, mais des bacs sont placés de manière contextuelle. Un bac proposant couteaux et fourchettes accompagne les entrées ; un offrant fourchettes, couteaux, couteaux à viande, cuillère à soupe… est disposé près des plats chauds ; des couteaux et des petites cuillères sont placés près des desserts. Enfin, les verres sont placés à coté des boissons.
La fin du repas change également un peu : au lieu d’un tapis roulant et de bacs dédiés, les plateaux sont déposés sur des chariots et traités en aval.
La reprise du parcours à un endroit donné est là grandement facilité. Je n’ai en effet pas besoin de retourner au début de la chaîne afin de récupérer le verre qui me permettra de boire le pichet de vin que j’aurai récupéré à la fin.
Bon, OK, mais où diable veut-il en venir ?
Considérant disposer d’un lectorat un tant soit peu intelligent, j’imagine qu’à ce stade de l’article, vous ne vous posez plus la question. Pour les autres, je vais expliquer.
Mon premier self service a été conçu autour du processus. Les clients, les couverts et la nourriture sont des pièces dans une chaîne de montage qui entrent à un bout de la chaîne, ressortent à l’autre bout selon un workflow bien établi, le tout en ayant accompli un certain nombre d’actions prédéfinies en interaction avec d’autres pièces définies à l’avance. D’un point de vu industriel, c’est parfait, et cela remplit très exactement son but : nourrir le plus grand nombre de personnes possibles en un minimum de temps avec le moins d’imprécision et d’incertitudes possible. D’un autre coté, c’est loin d’être très user friendly.
Mon second self service a été conçu autour de l’utilisateur, qui est détaché du processus. Ce dernier peut être repris n’importe quand, et certaines étapes non vitales peuvent même être sautées sans que cela remette en cause l’intégrité du processus. Si ce cas est beaucoup plus souple (et beaucoup plus agréable pour l’utilisateur), il y a en revanche une contrepartie non négligeable : on peut faire déjeuner beaucoup moins de gens dans un laps de temps donné.
La conception d’un site ou d’une application web suit un peu la même logique : deux outils fonctionnellement égaux seront totalement différents selon que la conception se fait du point de vue du processus ou de l’utilisateur. Le second cas d’étude n’est pas forcément le meilleur, mais c’est certainement celui qui plaira le plus aux utilisateurs, au détriment peut-être du rendement recherché.
Publié le 13 décembre 2008 à 09h52 Publié sous Ergonomie web et logicielle
Mots clés restaurant, utilisabilité, web, processus, conception, logiciel
Si cet article vous a plu, suivez-moi sur Twitter
3 commentaires sur Analogie entre l'ergonomie des logiciels et la conception d'un self service »
-
Par Luc le 13 décembre 2008 à 13h36 :
-
Par Mère Teresa le 15 décembre 2008 à 00h17 :
Merci pour ce comparatif sympathique.
@Luc : mais si le second self attire plus de monde, les coûts supplémentaires valent bien l’investissement, je crois.
-
Par Cédric le 26 décembre 2008 à 11h19 :
D’un autre côté si le premier self génère beaucoup d’erreurs dans les choix des utilisateurs, on aura d’un côté du mécontentement, et de l’autre des gens qui devront retourner chercher différents ustensiles, donc une perturbation du processus et en plus un plus grand nombre d’ustensiles à laver.
Donc je ne suis pas certain que le second n’ai pas une chance de l’emporter de part sa gestion plus économique.
Paradoxe souvent applicable au logiciel : un logiciel à l’ergonomie mieux pensée peut coûter plus cher, mais faire gagner des centaines d’heures par an aux utilisateurs.
Trackbacks sur Analogie entre l'ergonomie des logiciels et la conception d'un self service
Les trackbacks sont fermés pour cause de spam.
L'ergonomie web, l'utilisabilité et la qualité des logiciels sont trois grandes passions mises au services de ma profession.
Il faut aussi prendre en compte les couts de revients et de fonctionnement.
le premier système coutera moins cher à mettre en place et sera moins cher à utiliser.
Par exemple, tous les couverts sont traités en un seul voyage après l’étape vaisselles, cela prend donc moins de temps de les replacer après cycle d’utilisation complet. donc ça coute moins cher (en théorie).
Pour le logiciel c’est pareil. bien souvent la solution la plus aboutie est celle de l’hotel, mais pour des raisons de cout on se contente de la solution industrielle… hélas…