Je vous propose un petit mode d’emploi pour faire vos tests utilisateurs par vous-même (Do It Yourself). À l’origine de ce mode d’emploi deux présentations à ParisWeb 2011, une de Maurice Svay sur les tests utilisateurs DIY et une de moi-même sur l’usage des tests.
Les ingrédients
Pour faire des tests utilisateurs DIY, il faut :
- 3 à 5 utilisateurs : Le nombre d’utilisateurs est fonction du nombre de problèmes d’ergonomie que vous souhaitez trouver. Dans le cadre d’un test DIY, l’idée est de détecter quelques problèmes puis de les corriger, avant de refaire éventuellement une passation.
- 1 ou 2 observateurs : Ça, c’est vous ! Et éventuellement un collègue qui pourra vous aider. À deux, je vous conseille d’attribuer un rôle à chacun : un observateur et un animateur. Pensez impérativement à garder une attitude « neutre et bienveillante ». Trop d’encouragement ou du dénigrement vont fausser les tests.
- 1 lieu : idéalement une salle de réunion, au calme et où vous ne serez pas dérangé.
- 1 logiciel de capture d’écran : Il en existe de nombreux sur PC, comme Camstudio, sur Mac comme Silverback. Ces deux logiciels permettent d’enregistrer ce qui se passe à l’écran en même temps que le son et la webcam. Le but n’est pas d’avoir des heures de vidéos à dépouiller, mais de pouvoir montrer les problèmes relevés. Cela peut être utilisé pour communiquer avec la hiérarchie ou les développeurs.
- Une consigne : Il faut avoir préparé une consigne précise.
- Un accord de participation ou confidentialité peut être nécessaire.
- Un zeste de matériel : un ordinateur avec une souris. On parle là de tester un site Web ou une application.
- Un site ou service testable : Le site ne doit pas présenter de problèmes techniques.
- Des bons cadeaux : Pour récompenser les utilisateurs « externes »; Une valeur de 40 € par utilisateur est généralement proposé.
Recruter des utilisateurs
Le recrutement des utilisateurs se fait avec les moyens du bord. Le but n’est pas d’avoir une population représentative, mais simplement d’éviter les « Super-utilisateurs ». Donc vous pouvez recruter :
- Au bout du couloir, parmi les collègues qui ne participent pas au projet (la comptabilité, …)
- Des étudiants, c’est toujours dispos et c’est toujours content d’avoir un bon cadeau.
- La famille, c’est intéressant si vous voulez des populations pas trop faciles à atteindre comme les enfants ou les personnes âgées. Mais, attention, ces utilisateurs vont être « gentils » avec vous et vont peu critiquer.
Rédiger la consigne
La consigne peut être lu par l’observateur, puis laissé à disposition de l’utilisateur pour les scénarios. La consigne doit avoir la structure suivante :
- Introduction et règles
- Tâche de découverte
- Scénario A
- Scénario B
- Scénario C
- Scénario D
- Remerciement
Dans l’introduction, il faut expliquer brièvement le pourquoi des tests utilisateurs : « Dans le cadre de l’amélioration du service… nous faisons une série de tests avec des utilisateurs… ». Puis il faut donner les consignes globales : Exprimer ces difficultés à voix haute, le rôle de l’observateur ou l’interdiction d’utiliser Google pour la recherche. Enfin il faut rappeler que l’on teste le site et pas l’utilisateur. L’observateur est là aussi pour rappeler ces consignes par la suite.
La tâche de découverte doit permettre à l’utilisateur de survoler le service et de prendre quelques repères. Elle doit durer 2 ou 3 minutes maximum. L’utilisateur ne doit pas avoir vu les scénarios pour cette tâche sinon il risque d’anticiper sur la suite.
Le nombre de scénarios va varier en fonction de vos besoins. Il faut les organiser de manière logique (On cherche une information avant de commander le produit lié) et si possible avec une difficulté progressive. La passation de l’ensemble des scénarios ne doit pas prendre plus de 30 minutes. Une durée de 15 minutes est idéale pour un site Web grand public.
Pour chaque scénario, il faut :
- Rappeler le contexte du scénario, « Pour les vacances de Noël… », mais vous ne devez pas donner un rôle à l’utilisateur « Vous êtes étudiant et vous »… « Bah non, je ne suis plus étudiant »
- Préciser la tâche à réaliser, sans donner d’indices sur la marche à suivre : « Réservez deux billets de train pour aller de Rennes à Pau le 15 novembre »
- Indiquer précisément l’objectif marquant la fin du scénario : « Jusqu’à l’écran de paiement » ou « Donnez le prix et l’horaire des billets »
- Il faut prévoir un temps maximum de passation.
Pour résumer, une bonne consigne :
- Est directe et concise
- Ne reprend pas les termes du site
- Est centré sur la tâche, l’objectif, pas sur le parcours
Vous pouvez la faire relire ou aussi la faire passer avec une première personne, pour vous assurer qu’elle est bien comprise.
Le déroulement
Pour le déroulement, il y a de nombreuses petites étapes à suivre dans l’ordre.
- Accueillez l’utilisateur.
- Présentez-vous en tant qu’observateur.
- Donnez la compensation, le bon cadeau, comme cela l’utilisateur n’attendra plus récompense et pourra dire ce qu’il pense !
- Mettez en confiance, rappelez que l’on teste le site, pas l’utilisateur.
- Faites signer l’accord de participation, notamment pour utilisateur extérieur ou si vous enregistrez une vidéo.
- (Ré) initialisez le test (si ce n’est pas déjà fait).
- Présentez la consigne, répondez aux questions de l’utilisateur.
- Début de session
- Test de repérage
- Scénarios
- Prenez des notes dans la mesure du possible
- Fin de session
- Répondez aux questions
- Remerciez l’utilisateur
- (Ré) initialisez le test : tous les utilisateurs doivent partir sur la même base. Attention, cette étape peut prendre du temps.
- Prenez des notes, pendant que c’est frais
- Analysez, seul ou à plusieurs.
Voila ! Pour organiser et réaliser des tests utilisateurs DIY, il faut généralement compter deux jours. Une demi-journée de passation, le reste en préparation, recrutement et analyse.
Merci pour ce petit mode d’emploi pour réaliser les recettes utilisateurs !
Attention petite coquille mignonne : un ordinateur avec une souriE 🙂
Merci beaucoup pour ce petit manuel que je vais m’empresser d’utiliser !
Réflexions…
Tests Utilisateurs. « on teste le site et pas l’utilisateur ». On teste l’utilisabilité du site. On évalue l’utilisabilité du site. Évaluation de l’utilisabilité.
Le test utilisateurs. Ça sert à quoi ? À demander l’avis de l’utilisateur ? À évaluer l’utilisabilité ? Dans ce dernier cas, la phase d’analyse n’est-elle pas critique ? La validité des résultats issue de cette phase n’implique-t-elle pas une rigueur du plan d’évaluation (plan expérimental ?).
En général, les méthodologies employées ne sont-elles pas trop limitées pour pouvoir conclure sur la réalité des problèmes observés, pour pouvoir distinguer les « accidents » des vrais problèmes ?
Merci pour cet article, très intéressant. J’aurais aimé le lire à l’époque de mes premiers user tests!
J’ai juste une question, lorsque tu dis : « Rappeler le contexte du scénario, « Pour les vacances de Noël… », mais vous ne devez pas donner un rôle à l’utilisateur « Vous êtes étudiant et vous »… « Bah non, je ne suis plus étudiant » »
—-> Pourquoi ?
Dans le cas où on teste une interface grand public je le conçois tout à fait.
Mais, pour ma part, je travail sur des interfaces d’applications en B to B assez complexes de gestion et comptabilité (hyper sexy….), où le type de métier d’un utilisateur affecte forcément son utilisation de nos logiciels (par exemple un simple salarié, un manager où un comptable, n’utiliseront pas une app de gestion des notes de frais dans le même but. L’un y déclarera ses dépenses, le second validera les dépenses de ses salariés, le 3em gérera la compta et les remboursements des notes de frais).
Dans le cas des users tests, lorsque je n’ai pas d’utilisateurs correspondant aux vrais users finaux, je leur demande justement de se mettre dans la peau d’un personnage. Ça permet d’orienter leur comportement vers de vrais cas d’usages, et je vois mal comment cela pourrait être aussi efficace si je ne demandais pas aux utilisateurs de jouer ce rôle.
Mais il n’est simplement pas possible de jouer certains rôles. Le rôle du comptable n’est « jouable » que par des comptables. Dans ce cas il faut avoir des connaissances particulières pour faire certaines tâches.
Je vais donner un autre exemple, lors d’une formation je fais faire des tests sur ce modèle entre les participants de la formation. Deux documentalistes travaillant pour une entreprise d’outsourcing (Replacement de personnes au chômage) ont proposées de faire les tests sur leur site en « jouant au chômeur ». Il se trouvait que deux autres documentalistes, d’une autre entreprise, étaient présentes dans le groupe. Ces 2 documentalistes ont parfaitement réussi le test. Les deux autres personnes passées sur le site ont échoué à une grande partie des tâches. Donc ce site était fait par des documentalistes pour des documentalistes. « Jouer au chômeur » ne change rien aux modèles mentaux de la personnes.
Donc non, ça sert à rien de dire « Vous êtes machin chose et vous », la personnes est ce qu’elle est. On peux juste lui donner un contexte qu’elle a sans doute déjà rencontré : Prendre le train, Vacances, démarche administrative, etc…
Oui je comprends. Mais entre demander aux users de suivre un modèle très complexe et spécifique, et plus simplement les projeter dans un rôle, une histoire, pour suivre les tâches à effectuer, est-ce qu’il n’y a pas une nuance exploitable ? (c’est un vrai questionnement, je ne dis pas que j’ai la bonne réponse).
Effectivement, on ne peut pas demander au gens de changer leur façon de penser et d’être quelqu’un d’autre, c’est évident. On ne peut pas leur demander de tester des interfaces complexes dont il n’auraient pas la connaissance métier, cela va de soit. Là dessus je te rejoint complètement, c’est une évidence.
Mais donner à l’utilisateur un contexte et un scénario est-ce que ça reviendrais forcément à fausser les tests?
Un exemple : Nous testons une application mobile pour déclarer des dépenses professionnelles. Dire aux users: « vous êtes un commercial itinérant, aujourd’hui vous allez voir un client, vous achetez donc un billet de train Paris-Nantes, déclarez cette dépense avec votre application mobile. »
Selon toi c’est une erreur ? Parce que, si ton utilisateur testeur ne correspond pas à la cible, si par exemple, il ne déclare jamais de dépenses professionnelle, est-ce que lui donner un rôle à jouer ne va pas l’aider à donner du sens aux tâches qu’il effectue?
L’idéal évidemment c’est d’avoir des testeurs aux plus proches du profil des users finaux, mais on ne les a pas toujours sous la main.
Dans ton exemple en réalité tu n’as pas besoin de ce rôle. Tu peux simplement dire « Aujourd’hui vous allez assister à une conférence à Nantes, vous achetez donc un billet de train Paris-Nantes, déclarez cette dépense avec votre application mobile. »
Ça répond à tout les cas de figure (ou presque), tu donnes juste un contexte réaliste et une tâche. Même si il a jamais fait cette tâche il peut très bien se projeter dedans sans être perturber par autres choses. Pas besoin de « Vous êtes un super héros et vous allez sauver la terre (encore une fois) ».
Un autre cas, ou c’est super glissant, c’est quand tu parles d’enfants. Je me suis déjà retrouvé à expliquer le fonctionnement de l’inscription en crèche à une femme qui n’avait pas pu avoir d’enfant en raison d’une maladie handicapante. Il y une minute de flottement, avant qu’on relance la question en déplaçant le sujet sur des procédures liées à son handicap. Donc le truc à éviter c’est « Vous avez des enfants et… »
Ah oui. Clairement. Surtout que, ce qui m’intéresse dans l’idée des scénarios c’est de donner aux utilisateurs un contexte dans lequel ils peuvent se projeter. Effectivement, la question du rôle à jouer n’est pas nécessaire.
Ça a beau être évident dit comme ça, je n’y avais jamais pensé sous cet angle.
Merci Raphaël. Ma prochaine session de test est prévue pour vendredi. Je vais pouvoir revoir mon scénario en conséquence. Merci beaucoup pour ces échanges.
Bonjour Raphaël,
Merci pour cet article très instructif.
Qu’entends-tu par « Tâche de découverte » / « Test de repérage » ? Peux-tu donner quelques exemples ?
Merci.
La tâche de découverte correspond à une première tâche où l’utilisateur est libre de parcourir le site pour le découvrir et se faire une première idée de son organisation. Le but est d’éviter un effet d’apprentissage trop marqué sur le premier scénario.
Bonjour,
Faut-il au préalable questionner l’utilisateur pour connaitre son profil ? (age, utilisation d’internet, freins…) Si oui comment ? L’idée étant d’avoir un « persona » du testeur.
Merci
Vous devez connaitre vos utilisateurs avant le test, au moment du recrutement dans la mesure possible pour avoir des utilisateurs « tests » qui correspondent aux utilisateurs finaux. Il est possible de compléter les informations par des questions avant ou après le test.