Affordance vs Signifier
Nos petites astuces sont l’occasion de donner une perspective plus large sur le design et sur la logique qui le sous-tend. Dans The Design of Everyday Things, Don Normann revient sur ce qui fait la force du design, et clarifie quelques notions. « Affordance » et « signifier » sont deux termes qui introduisent une différence fondamentale entre le design traditionnel et le design web, et cette différence justifie qu’on fasse attention aux mots employés quand on conçoit pour le web.
« Affordance » désigne les potentialités d’un objet, lesquelles sont souvent perceptibles dans ses attributs physiques. Je vois une « porte », je sais qu’elle a le potentiel d’être ouverte parce que c’est dans sa nature même. Mais si je ne fais que regarder la poignée et selon la manière dont elle a été conçue, je ne me ferais pas forcément une idée claire de si elle se pousse ou se tire.
« Signifier » désigner le signe qui clarifie la façon dont l’objet peut être utilisé : la forme de la poignée, l’étiquette « pousser », etc.
Les deux combinés vous offrent une représentation mentale du fonctionnement de la porte. Et si vous vous prenez la porte dans le figure, c’est que le concepteur de celle-ci ce sera trompé.
Le design web est un peu différent: le signe et l’action sont intimement liés. Le bouton est donc à la fois la fonctionnalité et le signe de cette fonctionnalité. Plongeons donc rapidement dans cet élément d’UI qui peut être fondamental pour que l’utilisateur interagisse et par là s’engage auprès de vous.
Utilisez un vocabulaire courant
Les labels de boutons contiennent souvent des verbes (« éditer », « sauvegarder », etc.) Il faut faire attention à ce que ces verbes restent proches de l’action qui suit. Par exemple, dans le cas d’un ajout de commentaire, il vaut mieux « commenter » que « sauvegarder » : l’utilisateur aura une meilleure idée des conséquences de son action.
Tenir compte de la destination et du contexte
La destination, c’est également comme ça que se matérialise le résultat pour le système.
En fonction de la construction de l’app ou du site, on peut avoir des boutons qui valident et sauvegardent les données en les affichant sur l’écran où on se trouve (pas trop recommandé, parce que la notion « d’envoi » des données sera mal représentée) ou sur un écran suivant et donc dans un autre contexte d’utilisation.
Dans le premier cas, « Valider » semble approprié mais « Envoyer » sera probablement plus parlant dans le deuxième cas qui conduit l’utilisateur sur un récapitulatif plutôt qu’une sauvegarde des données brutes et l’utilisateur grâce à ce label a bien la notion qu’il transmet ses données ce qui est plus raccord avec son consentement à partager ses données.
Utiliser un verbe d’action en rapport avec le contexte
Dans la suite de l’idée de la « destination », il est très utile de se remettre dans l’état d’esprit de l’utilisateur dans le contexte.
Pour confirmer les actions de l’utilisateur, il vaut mieux utiliser un verbe d’action. A la question « Voulez-vous quitter l’application ? », on préférera les labels « quitter » et « revenir » à « oui » ou « non » qui ne proposent qu’un contenu « logique », là où les premières options aident à confirmer « sémantiquement » l’action.
La méthode « bête »
Les tests dans ce domaine ne sont pas vains et sont simples, il est dommage de ne pas y accorder un peu de temps.
Pour tester les labels des boutons, le plus simple est de soumettre un prototype interactif ou même une maquette. Par exemple un simple écran avec des fausses données et un simple bouton en bas de page.
Dans un premier temps, faites-lui tester de manière « ingénue » (bouton sans label ou avec un label neutre: « action ») pour qu’il verbalise l’action puis remettez l’action dans le contexte (« qu’est-ce qui s’est passé après avoir appuyer sur le bouton? ») pour qu’il exprime d’autres idées de label.
Dans un deuxième temps, retestez avec le résultat de vos recherches, et si possible avec un autre utilisateur. L’idée est de mettre en scène dans le contexte d’utilisation et directement avec vos autres résultats de test pour s’approcher au plus de la réalité. En poussant l’utilisateur à verbaliser, vous obtiendrez des informations qui vous permettra de peupler votre parcours « utilisateur » avec d’éventuels points de douleur et des citations.
L’important est de tester pour éviter de découvrir un blocage a posteriori qui vous aura coûté quelques points d’UX.