Comment révolutionner l’expérience utilisateur en 17 caractères
Un titre pompeux, accrocheur et mystérieux… bienvenue sur mon tout premier article Médium !
Aujourd’hui je vais vous parler d’expérience utilisateur (UX), mais plus particulièrement de la capacité d’une interface à nous fournir implicitement de l’information sur son fonctionnement.
Tout est question de suggestion…
Quel est le point commun entre un champ de texte dans Internet Explorer, Mozilla Firefox, Google Chrome ou encore Safari ? C’est un rectangle aux bords foncés et au fond clair.
Ainsi, l’espace qui autorise l’écriture est normé d’une manière relativement similaire sur l’ensemble des navigateurs et ce pour une raison très simple : il est de ce fait extrêmement facile de le reconnaitre. Son apparence nous suggère qu’il est possible de cliquer “dedans” (grâce à un fort contraste induit par le bord plus foncé) et le changement de curseur nous indique qu’il est permis d’y écrire du texte. On parle alors d’affordance ou bien de capacité suggestive d’action.
L’affordance est un anglicisme issu de la psychologie cognitive. Dans le domaine de l’ergonomie c’est la capacité d’un objet à suggérer sa propre utilisation.
Chaque jour, sans même y penser, nous utilisons instinctivement pléthore d’objets du quotidien (eg. table, chaise, verre, porte, etc.) sans réfléchir un seul instant à leur mode d’emploi. Ces objets simples ont, dans la plupart des cas, une très bonne affordance. Dans la plupart des cas, car il n’est pas rare de tomber sur une porte “réticente” qui nous fait nous sentir particulièrement stupide… (vous voyez exactement de quoi je veux parler !)
Vous n’êtes pas seul ! Ça n’arrive pas qu’à vous et ce n’est absolument pas votre faute. Ces portes sont tellement répandus qu’on leur a même donnée un nom. On les appelle des Norman Doors en référence à Don Norman auteur de The Design of Everyday Things.
Les Norman Doors sont des portes qui ont une très mauvaise affordance. Ce défaut est la plupart du temps dû a la suggestion de plusieurs utilisations antinomiques. Certaines portes, par exemple, possèdent une grosse poignée invitant naturellement l’utilisateur à tirer vers lui, alors que le mécanisme (les gonds ou le cadre) suggère que l’ouverture se fait dans l’autre sens.
Le premier réflexe de l’utilisateur sera alors de tirer sur la poignée avant de réaliser (par l’échec) que la porte s’ouvre en poussant. Se crée alors un sentiment immédiat de frustration doublé d’une impression de stupidité. C’est une très mauvaise expérience pour l’utilisateur qu’il faut à tout prix lui éviter !
Pourquoi les développeurs devraient faire de l’UX
En tant que développeur, je suis régulièrement amené à concevoir des interfaces utilisateur. Bien que ce travail soit le plus souvent réalisé en amont par un designer graphique (avec parfois quelques notions d’UX), il n’est pas rare de devoir modifier ou extrapoler certaines vues du logiciel.
Bien que souvent perçu comme le maçon de l’informatique, le travail du développeur ne doit pas, selon moi, s’arrêter à la simple intégration d’une maquette. Le développeur peut (et devrait !) entrer pleinement dans le processus de conception et de développement d’une interface utilisateur. Il ne faut pas oublier qu’il sera le tout premier usager du logiciel !
Ce qui nous amène, digression après digression, au sujet principal de cet article : comment simplifier la vie de vos utilisateurs en une seule ligne de code.
“Il faut ajouter un champ de recherche dans la liste des adhérents !”
Dans l’espace de coworking où je travaille (Mutualāb ❤️), nous avons un logiciel de gestion des adhérents. Celui-ci, présenté sous la forme d’une application web, permet entre autre de créditer le compte de tickets de chaque membre.
Pour ce faire, il faut dans un premier temps sélectionner la fiche de la personne en question, puis lui ajouter le nombre de tickets désirés. Une opération relativement simple sur le papier, mais qui a donné envie de s’arracher les cheveux à ceux qui en avaient encore quelques-uns…
La cause du problème est assez simple à comprendre. La sélection d’un utilisateur se fait au travers de ce qui semble être, à première vue, un menu déroulant classique. Le nombre d’utilisateurs ne faisant que croître, je vous laisse imaginer le calvaire pour trouver un adhérent dans une liste de près de 400 inscrits…
Or, le développeur de l’application, n’étant pas stupide, avait anticipé cette situation. Comme solution à ce problème il a mis en place un composant qui permet de filtrer cette liste en inscrivant directement le nom/prénom de la personne recherchée. Et pour ce faire, en bon développeur un peu fainéant, il a bien évidement utilisé un élément issue d’une bibliothèque de composants connue (des développeurs) qui s’appelle jQuey UI.
Ce qui nous mène à une situation paradoxale où les développeurs n’ont aucun problème à créditer des tickets (car ils connaissent le système utilisé) alors que les utilisateurs lambdas vivent un véritable chemin de croix pour effectuer la même tâche. Sont-ce les développeurs qui possèdent un QI extraordinaire..?
Comme je le titrais plus haut, tout est question de suggestion ! Or, ce qui frappe dans la première version du module de recherche c’est son incapacité à nous indiquer que l’on peut y inscrire du texte. Ce qui explique le désarroi des personnes n’étant pas au fait d’une telle fonctionnalité.
C’est exactement ici que le travail du développeur ne doit pas s’arrêter. C’est ici que l’utilisateur doit remettre en question la qualité de l’interface en lieu et place de ses performances cognitives.
Alors que faire pour améliorer simplement et rapidement l’expérience des utilisateurs du système ? La norme.
Et pour cela, une seule ligne de code suffit.
Puisque, comme nous l’avons constaté plus haut, l’apparence des champs texte est normée, pourquoi ne pas respecter cette norme dans notre champ de recherche ? Ainsi, en rendant celui-ci conforme à ce que les utilisateurs ont l’habitude d’utiliser, on bénéficie de toutes les expériences passées et du savoir accumulé au fil des navigations.
Bien qu’améliorant grandement l’utilisabilité, la solution mise en place pourrait sans doute être encore affinée. Je pense par exemple à l’ajout d’un label indiquant que ce champ permet d’effectuer une recherche. On pourrait également agrémenter le champ d’une icône 🔍 très souvent associée à la cette fonctionnalité.
En définitive, c’est un changement minime qui peut sembler insignifiant aux yeux de certains, mais qui a pourtant un réel impact sur l’expérience quotidienne des usagers du logiciel.
Alors pourquoi s’en passer ?
Pourquoi ne pas écouter les utilisateurs et leur faciliter la vie quand la solution tient en seulement 17 caractères ?
Sources/inspirations
https://uxplanet.org/designing-more-efficient-forms-structure-inputs-labels-and-actions-e3a47007114f#.jjw5hxcp8
https://www.nngroup.com/articles/form-design-placeholders/
http://99percentinvisible.org/article/norman-doors-dont-know-whether-push-pull-blame-design/
https://www.nngroup.com/articles/icon-usability/
