Si vous avez à cœur de concevoir des solutions numériques facile d’utilisation pour vos clients et utilisateurs, les tests utilisateur sont une phase fondamentale lors de la conception ou de l’amélioration d’une application web.
Ils aident à optimiser les fonctionnalités d’un MVP (Minimum Viable Product) sans en bouleverser la logique et ils améliorent en profondeur une application dont l’usage est déjà mûr.
Dans le cas des prototypes, ils éprouvent la qualité du produit avant de le lancer ou le mettre en ligne.
Ils ont plusieurs raisons d’être :
Vous n’êtes pas l’utilisateur
Vous n’utilisez pas vos journées de la même manière que vos utilisateurs, vous n’avez pas la même facilité avec les interfaces, vous n’utilisez pas les mêmes applications ou appareils, vous ne jonglez pas de la même manière entre différentes interfaces ou différents dispositifs (peut-être que votre utilisateur ne jongle pas non plus).
Les designers se trompent aussi
Même les designers qui ont un culture étendue sur les usages du web sont surpris de découvrir que tel ou tel label n’est pas compris ou que tel ou tel bouton n’est pas visible.
Leur avis compte bien sûr, mais le designer est surtout là pour trouver des solutions (design, contenu, ou logique), et il faut donc bien avoir répertorié les points de douleur des utilisateurs pour améliorer l’application.
On ne se baigne jamais deux fois dans le même fleuve du numérique
Les compréhensions et les usages évoluent sans cesse et l’arrivée de nouvelles applications sur le marché change la place de la vôtre dans l’univers de votre utilisateur et demande à ce que vous redéfinissiez la valeur de la vôtre.
Un exemple, le test d’usabilité
Le test d’usabilité est un outil parmi d’autres, mais il est très intéressant pour son efficacité et pour la simplicité avec laquelle on le met en oeuvre.
Il mesure si l’enchaînement des interactions conduit bien l’utilisateur au but qu’il s’était fixé en utilisant l’application. L’intervention se situe plus à un niveau ergonomique qu’expérientiel. Les aspects de séduction sont gommés, et l’attention aux détails ne vaut que dans la mesure où ceux-ci permettent de « soulager » l’utilisateur. Ce qui prévaut ici c’est le soucis d’efficacité.
Le cœur du test consiste à simplement observer un utilisateur qui navigue dans votre application. Mais pour que l’observation soit rigoureuse il faut faire attention à plusieurs points.
Se doter d’une grille de lecture
Pour repérer rapidement les points de difficulté et ne pas analyser à tort et à travers, une grille de lecture heuristique aide à décider les moments sur lequel il vaut le coup de s’arrêter. Le test se déroule en temps réel et pour traduire au mieux l’expérience, il vaut mieux éviter d’arrêter l’utilisateur dans le cour de son observation.
Les erreurs qu’on décèle dans ce genre de test sont de deux natures:
- Les erreurs non intentionnelles,
- Les erreurs d’intention.
Les premières sont assimilables a des bugs ou des problèmes de design ; l’utilisateur souhaitait réaliser une action et il n’y a pas réussi ou a été orienté sur une autre action, par exemple (je veux consulter la page « qui sommes-nous ? » et je suis réorienter sur la page « l’entreprise en chiffres »; je veux cliquer sur un bouton, mais il est trop petit et je clique à côté).
Les deuxièmes sont plus difficiles car elles renvoient souvent à un manque général de la compréhension de la fonctionnalité par l’utilisateur. On les pallie par une information ou un réorganisation du parcours de l’utilisateur. L’utilisateur déduit des signes qui composent l’interface le fonctionnement du système (par exemple, vous vous trouvez face à une porte, un signe sur la poignée vous fait comprendre qu’elle se pousse) et s’il y a un décalage entre le fonctionnement du système ou une ambivalence de certains signes, cela provoquera des erreurs dans l’utilisation de votre application (pour suivre l’exemple précédent : pas de chance, il fallait comprendre le signe « tirer la poignée », c’était mal expliqué).
Choisir les testeurs en fonction de leur rapport aux technologies
Les test d’usabilité n’ont pas vocation à couvrir les usages de toutes les cibles, mais plutôt de relever le plus de problèmes ergonomiques possibles. On part donc du principe que les personnes ont à peu près les même capacités psychomotrices.
Si on doit distinguer des profils, il faut plutôt se concentrer, dans le cas d’un usage classique, sur l’affinité et le type de rapport qu’entretient le testeur avec la technologie. Il y a ainsi des personnes qui sont clairement en situation de difficulté face à une interface mais qui s’en arrange en suivant la navigation proposée par l’appli ou le site web. D’autres ont souvent le clic prompt et n’hésitent pas à tester tous les liens et éléments de navigation qu’ils ont à leur disposition.
L’exception étant le cas de l’accessibilité où il faut faire d’abord des choix sur le référentiel, lequel est souvent général (il s’adresse à plusieurs handicaps), et choisir ces utilisateurs avec un panel de handicap le plus large possible (handicap visuel, moteur, etc.).
Les tests d’usabilité ne s’appuient pas sur un grand nombre de testeurs. Dans notre expérience, 6 à 9 testeurs suffisent à détecter les problèmes essentiels. Pour estimer le nombre d’utilisateurs, vous devez prendre en compte également le nombre et la complexité des fonctionnalités que vous testez.
Préparer le scénario d’utilisation
La complexité des cas utilisateur est fonction de leur nombre et du niveau de détail dans lequel vous vous plongez. Idéalement il faut arrêter des cas généraux assez larges et avoir en tête les étapes qui mènent à la complétion d’objectifs simples (inscription, premier post, chercher un interlocuteur), etc.
Préparez bien sûr les éléments dont vous avez besoin pour que le testeur ne soit pas interrompu. Par exemple, fournissez-lui un téléphone avec l’appli et une adresse email préconfigurée pour une inscription, ou connectez-vous à un faux compte utilisateur si vous voulez tester les interactions avec votre testeur.
Guider sans diriger
Le test n’est pas un entretien qualitatif et les interventions du responsable du test ne doivent pas perturber l’utilisateur.
Il vaut mieux intervenir quand l’interprétation claire des intentions du testeur est complexe. Par exemple, si on le voit hésiter ou revenir sur une action au point de l’abandonner, clarifier son intention est primordial.
Idéalement, on peut poser des questions en fin de test pour un ressenti plus global et préciser des points qui n’ont pas été clairs (« vous avez hésité à ce moment, est-ce que vous vous rappelez pourquoi ? »)
Venir à deux
Cela peut paraître superflu, mais conduire le test, observer et noter les problèmes en même temps est difficile. Il faut éviter de louper des moments-clés et il faut bien documenter le test pour faire la part entre ce qu’un observateur projette sur le test et la réalité de la situation.
Réaliser un « screencast » (vidéo du test) est un autre solution mais elle ne permet pas de noter les expressions de l’utilisateur qui montrent son agacement ou son étonnement.
Repérer les problèmes sans se jeter sur les solutions
En se précipitant sur les solutions, alors qu’on a du temps à sa disposition, on risque :
- de ne pas prioriser certaines solutions sur d’autres (il faut faire la part du gain induit),
- de mal cadrer la solution par rapport à l’enjeu (par exemple, refaire un prototype, alors qu’on peut changer la taille ou la position d’un bouton),
- de mal communiquer à son équipe les intentions à l’oeuvre dans un plan de résolution.
Lister les solutions les plus simples
Après avoir listé les problèmes et les avoir regroupés par catégorie, on peut lister les solutions et les prioriser en gardant à l’esprit les principes ci-dessus.
Voir un exemple de liste d’erreurs
Si vous êtes dans une démarche d’amélioration continue, il faut bien sûr lever les problèmes bloquants d’abord, puis écluser les problèmes simples à résoudre ensuite.
Généralement ce sont ceux qui ne requièrent qu’un nombre limité de ressources (un développeur). Penser à la loi de Conway : une organisation complexe génère souvent une solution complexe. La complexité de l’organisation a son sens essentiellement quand le besoin d’expertise se fait ressentir.
Les problèmes plus complexes demandent du temps surtout quand ils sont mêlés à d’autres problèmes et il n’est souvent pas inutile de faire intervenir des experts dans ce cas, tout en gardant à l’esprit cette exigence : vous résolvez d’abord des problèmes d’usabilité, l’amélioration de l’expérience viendra après.
Garder des questions pour la fin
Les questions sont essentielles pour lever des ambiguïtés lors des tests, mais elles ouvrent aussi des perspectives sur des domaines connexes à l’usabilité. Par exemple, sur l’architecture de l’information et sur l’expérience ressentie.
Chaque test a sa finalité propre et il vaut mieux se fier aux données de vos utilisateurs qu’à votre propre avis. Dans une démarche d’amélioration continue, vous avez tout intérêt à mettre en place des boucles itératives qui incluent des tests réguliers pour améliorer un aspect ou un autre de votre application.
Update du 26/03/2019 : Ajout d’un lien vers un exemple d’un tableau en ligne qui liste les erreurs d’usabilité rencontrées lors d’un test.