Dans le cadre de mon prochain départ de mon entreprise actuelle, j’ai compilé divers documents de travail et articles de blogs autour de l’UX. Dans la partie méthodo, un article sur les tests utilisateurs manquait. J’ai donc rédigé le document suivant, adapté ensuite rapidement pour une publication sur mon blog.
Aussi souvent que possible, je fais passer des tests utilisateurs. Comme nous travaillons en méthode agile et que nous n’avons pas de budget pour mettre en place ces tests, il ne s’agit pas de tests très rigoureux type laboratoire de recherche, mais plutôt de tests sporadiques permettant d’apporter de la matière pour faire de l’amélioration continue sur les interfaces déjà développées. Je pourrais également m’essayer au guerilla testing qui est une méthode intéressante pour faire du test sans budget (aller interroger les gens dans la rue, dans un café, etc).
Pourquoi faire des tests utilisateurs
Quand on conçoit une interface, on tombe très vite dans le piège de tendre vers ce qui nous plait, ce que nous comprenons, au détriment de ce qui plaira ou ce que comprendra notre cible. De plus, en s’immergeant dans un projet, on perd vite toute objectivité. Une interface qui nous paraitrait incompréhensible si elle avait été conçue par quelqu’un d’autre peut nous sembler très intuitive, et ce en toute bonne foi, uniquement car nous la connaissons. Un peu comme tous les adeptes de Mac trouvent cet OS hyper intuitif, alors que quelqu’un habitué à Windows sera complètement perdu lors de sa première utilisation.
You are not your user
Malgré cette affiche au-dessus de mon bureau, il est impossible de se mettre réellement dans la peau (et surtout dans la logique) de quelqu’un d’autre. Voilà pourquoi les tests utilisateurs sont cruciaux. En observant quelqu’un d’autre utiliser notre produit, on peut voir très vite où la personne bloque, ce qu’elle comprend et ce qu’elle ne comprend pas, quel chemin elle emprunte et pourquoi. Correctement analysées, ces données d’observations se transforment vite en mine d’information pour les UX-designer et pour les chef·fe·s de produit, permettant aux premier·e·s d’adapter la conception, et aux second·e·s d’adapter les priorités de développement. Même si le contexte n’est pas idéal (pas de budget, cible peu claire…), il vaut toujours mieux récolter des retours, même en quantité limitée, plutôt que de considérer que ce que l’entreprise pense correspond forcément à ce dont le marché a besoin.
En amont
Choix de l’hypothèse à tester
Avant de mettre en place un test, il est nécessaire de savoir ce que l’on veut tester. En fonction des questions que l’on se pose, on fera des hypothèses plus ou moins précises, à partir desquelles on choisira un contexte d’utilisation et une situation à proposer à la personne qui testera l’application.
Par exemple, lorsque je testais la version mobile des catalogues virtuels de grande distribution que nous produisons, mon hypothèse à tester était la suivante :
Les utilisateurs réussissent à préparer leurs courses sans frustration majeure
Cette hypothèse est très large, elle implique de tester à peu près l’intégralité de l’application. Cependant, selon les besoins, on peut choisir des hypothèses beaucoup plus précises, et concevoir un scénario de test afin d’en tester une ou plusieurs.
Écriture de la consigne
Pour tester cette hypothèse, j’avais choisi d’utiliser un catalogue standard et de demander à mes sujets de s’imaginer dans la situation suivante :
Imaginez que vous avez envie de découvrir les promos intéressantes du magasin Auchan de Lyon, car vous y passez le week-end et envisagez d’aller y faire un tour.
L’écriture de la consigne est une étape importante. Il faut surtout s’assurer d’employer des termes neutres, qui n’orienteront pas l’usager·e vers telle ou telle action. Par exemple, plutôt que d’employer le mot « rechercher », j’ai choisi d’utiliser le terme « découvrir » qui est plus neutre et n’oriente pas vers l’utilisation de la fonction recherche.
J’avais également listé les différents éléments dont je souhaitais tester l’ergonomie qui me semblait correspondre à des potentiels besoins réels, me permettant de tester mon hypothèse globale :
- Changement de magasin : sélectionner un magasin proche de Lyon (69)
- Ajout de produits à la liste de courses
- Recherche de promotions intéressantes
- Consultation de la liste de couses
- Suppression d’un produit de la liste
- Partage de la liste de courses (envoie par mail)
Selon le contexte, il peut également être pertinent de laisser la personne testant le produit définir elle-même le scénario d’usage en fonction de ses besoin propres. Cela permet de s’approcher d’un contexte écologique où l’usager·e sera observé·e dans des conditions les plus naturelles possibles.
Choix d’un questionnaire d’évaluation
Cette étape n’est pas indispensable pour mettre en place des tests utilisateurs. Cependant, il peut être intéressant de profiter d’avoir des usager·es sous la main pour récupérer des données supplémentaires. Ces questionnaires pourront être proposés directement en fin de test, ou envoyés sous format numérique pour être remplis avec un délai de quelques jours, évaluant ainsi le souvenir de l’expérience utilisateur. En effet, c’est ce dernier qui influencera les comportements futurs : si les usager·e·s ont un souvenir agréable ils reviendront davantage que si le souvenir est moins bon.
Données quantitatives
Pour récolter des données quantitatives, on pourra choisir d’utiliser un questionnaire d’évaluation de l’utilisabilité (SUS) ou d’UX (Attrakdiff ou UEQ par exemple, lire l’article sur les questionnaires pour plus de détails sur ce sujet).
Données qualitatives
Il pourra être également intéressant de proposer une complétion de phrases en fin de test, pour aller un peu plus loin que les points forts et les points faibles, en dépasser les biais du questionnement direct (plus de détails sur la complétion de phrase dans l’article sur les questionnaires).
Préparation du matériel
Le matériel nécessaire à un test utilisateur est le suivant :
- Un device (ordinateur, tablette, smartphone, selon ce qu’on teste) avec le contenu à tester
- Éventuellement de quoi enregistrer les actions de l’utilisateur·trice sur le device et/ou une caméra ou un dictaphone pour filmer l’entretien
- Une feuille de consentement à faire signer par la personne
- La consigne et le texte d’introduction à lire, afin de donner des informations identiques à chaque testeur·se
- Une fiche à remplir pour noter quelques infos démographiques qu’on aura listées au préalable, et pour noter tout ce qui se passe pendant le test
Si j’avais effectivement tout ça lors de mes premiers tests, j’ai rapidement abandonné l’enregistrement qui fonctionnait une fois sur deux et n’était jamais réutilisé derrière. J’imagine que c’est plus crucial en agence ou dans une grosse entreprise quand il y a un·e client·e ou un·e supérieur·e à convaincre, mais personnellement je n’ai jamais eu besoin de « prouver » avec des images ou du son ce que j’affirmais avoir observé lors de tests utilisateurs.
Recrutement et prétests
Théoriquement, le recrutement est un élément très important de la préparation de tests utilisateurs. Les utilisateurs·trices choisis sont censés être représentatifs de la population utilisant réellement l’interface.
En pratique, comme nous n’avions pas de budget pour indemniser les participant·e·s, je n’ai pas pu faire de campagne de recrutement digne de ce nom. J’ai donc fait passer les tests utilisateurs à mes proches et aux salarié·e·s de l’entreprise ne travaillant pas sur cette application.
De même, il est recommandé de prétester son ou ses scénarios d’usage avant de passer à la « vraie » phase de test. N’ayant moi-même pas de population contrôlée, d’objectif de nombre de tests et d’analyses statistiques, le pré-test n’avait pas vraiment de sens.
Le jour J
Avant le test
C’est bien d’être prêt avant l’arrivée du sujet pour éviter de courir après un papier dans l’imprimante, un crayon sur le bureau, un device sur le banc de test. On commence par accueillir le ou la participant·e et le ou la mettre à l’aise, en lui proposant quelque chose à boire par exemple, avant de lui faire signer le formulaire de consentement.
Au moment de commencer le test, je leur lisais les quelques lignes introductives écrites au préalable afin que tou·te·s mes participant·e·s possèdent la même information. Dans ce court texte, je leur rappelais qu’ils et elles étaient là pour que nous puissions évaluer le système et nous améliorer, et surtout pas pour les juger eux.
Je vais vous observer lors de l’utilisation du catalogue en ligne d’Auchan sur téléphone mobile. Pendant toute la durée du test, vous serez encouragé à verbaliser le maximum de choses que vous faites et que vous pensez. Nous sommes ici pour évaluer l’application, et en aucun votre capacité à l’utiliser. Si vous rencontrez des difficultés, n’hésitez surtout pas à expliquer à haute voix ce que vous ne comprenez pas. C’est cela qui nous permettra d’améliorer l’application. Avant de commencer, je vais vous poser quelques questions.
J’enchainais ensuite sur quelques questions démographiques et des questions concernant leur usage des nouvelles technologies. Puis je leur lisais la consigne et nous commencions le test.
Imaginez que vous avez envie de découvrir les promos intéressantes du magasin Auchan de Lyon, car vous y passez le week-end et envisagez d’aller y faire un tour. Je vais lancer l’enregistrement, puis vous laisser prendre en main l’application et me décrire tout ce que vous voyez et comprenez. Je vous demanderai ensuite d’exécuter des actions précises.
Pendant le test
Pendant la phase de test, il faut surtout ne pas interrompre les participant·e·s, rester neutre, ne pas les influencer vers une solution ou une autre pour mener à bien leur mission.
Je leur demandais d’abord de prendre en main l’application et de me décrire ce qu’ils ou elles voyaient et comprenaient. Outre les retours sur le 1er écran que je récoltais ainsi, cela permettait de mettre en place une interaction dans laquelle ils ou elles parlent pendant que j’écoute.
Quand le flux de parole réduisait, je les encourageais à nouveau à verbaliser leur pensées et actions : « Qu’est-ce que tu comprends ici ? » « Qu’est-ce que tu fais ? Pourquoi ? ». Si je les sentais bloqué·e·s ou hésitant·e·s : « Qu’est-ce qui te dérange ? » « Qu’est-ce que tu ne comprends pas ? ». Si l’on me posait des questions, je répondais par d’autres questions : « à ton avis ? » « Qu’est-ce que tu en penses ? ».
En cas de blocage critique et durable, je leur expliquais comment se débloquer et nous passions à la suite du scénario.
De manière générale, je les laissais parcourir l’application dans le but de découvrir les promos intéressantes. Si des éléments que je souhaitais tester (choix du magasin, recherche, liste de courses) n’étaient pas spontanément utilisés, je leur posais ensuite des questions plus spécifiques afin d’évaluer ces éléments : « Supposons maintenant que tu veuilles voir ce qui existe comme offre de vêtements, comment t’y prendrais-tu ? » « Supposons que tu veuilles t’envoyer la liste des produits qui t’intéressent ». Bien entendu, le fait que les personnes testées n’utilisent pas spontanément telle ou telle fonctionnalité est déjà une information très précieuse.
Après le test
En fin de test, il est important de débriefer avec la personne afin de vérifier qu’elle a bien vécu la situation de test et pour recueillir son impression générale sur l’interface. On pourra lui demander par exemple de lister les points faibles et les points forts de l’interface, de remplir des questionnaires d’utilisabilité ou d’UX, ou de compléter des phrases.
On finit bien évidemment par remercier la personne qui a donné de son temps, avant de courir analyser les données recueillies.
En aval
Une fois le test réalisé, il reste à analyser ces résultats et en sortir des recommandations. Dans le cadre du projet Auchan mobile, j’ai pu réaliser une dizaine de tests cumulés sur 2 périodes différentes (8 en septembre 2014 puis 3 en novembre 2014). Pour analyser ces résultats, j’ai listé dans un fichier excel l’intégralité des problèmes rencontrés, regroupés par grandes thématiques (fiche produit, liste de courses…) et j’ai noté en colonne, pour chaque utilisateur·trice, si tel problème avait été rencontré ou non. Cette méthode m’a permis de mettre en évidence très vite et de manière très visuelle les problèmes les plus courants.
| % concerné | Sujet 1 | Sujet 2 | Sujet 3 | Sujet 4 | ||
| Fonctionnalité 1 | Problème A | 50% | 1 | 1 | ||
| Problème B | 25% | 1 | ||||
| Fonctionnalité 2 | Problème C | 50% | 1 | 1 | ||
| Problème D | 100% | 1 | 1 | 1 | 1 | |
| Problème E | 50% | 1 | 1 |
Sur 8 participant·e·s, réaliser des tests statistiques n’a aucun sens. Cependant, si la moitié des individus remontent un problème, j’estime qu’on peut considérer que cet élément doit être adressé, même sur un échantillon aussi faible que cela.
La plupart des éléments les plus critiques correspondaient au départ à des fonctions manquantes : le zoom dans le catalogue, l’accès aux fiches produits depuis le catalogue, etc. Il n’y avait donc pas grand-chose d’autre à faire que remonter cette information à la Product Owner du projet, en l’aidant à classer les fonctionnalités à développer selon la criticité du manque.
D’autres éléments en revanche mettaient en évidence des problèmes de compréhension des interfaces. Dans ces cas-là, il me fallait repenser les interfaces, faire de nouvelles propositions sous forme de maquette, et aller les défendre auprès de la PO.
Pour prioriser des fonctionnalités, on analysera 3 paramètres :
- Quel pourcentage de notre cible le problème concerne-t-il a priori ? Pour répondre à cette question, on utilisera des données statistiques (pourcentage d’utilisateurs·trices de mobiles sur nos produits par exemple).
- Dans quelle mesure ce problème est-il bloquant ? Les tests utilisateurs permettront de répondre à cette question.
- À quel point la fonctionnalité concernée par le problème est-elle stratégique ? C’est la vision produit de l’entreprise qui permet de répondre à cette question.
Les questions 2 et 3 combinées permettent d’évaluer à quel point les usager·e·s rencontrant le problème sont susceptibles de quitter l’application à cause de lui.
Exemple : si l’ajout de marque-page est très compliqué à comprendre, on pourra parler d’un problème très bloquant mais peu stratégique, donc qui risque peu de réduire le trafic, surtout s’il n’apparait que sur mobile. En revanche, si l’ouverture des fiches produit est visuellement désagréable, le problème est non bloquant mais concerne un élément très stratégique, et utilisé par tou·t·es. Pour peu que le problème soit récurrent sur toutes les plateformes (mobile, tablette, ordinateur), il faut le corriger au plus vite.
Les autres tests que j’ai effectués ont été plus sporadiques, me permettant moins de généraliser les observations que je faisais. Ceux-ci ont néanmoins toujours apporté une valeur dans mon travail, remettant en question tel ou tel point de design, ou mettant en lumière des problèmes évidents dont je n’avais pas réalisé le caractère bloquant.
Ces tests ont été un outil essentiel dans la priorisation de fonctionnalités et d’améliorations ergonomiques. Dans le projet BEEVIRTUA library dont j’ai été la Product Owner la première année, les tests utilisateurs, mêmes peu nombreux et espacés dans le temps, m’ont apporté beaucoup, me permettant d’adapter très vite le design dès qu’un problème critique était relevé.