Préparer des tests d’expérience produit

Explications

Le plan de test est principalement utile avant le déroulement des tests.

Il sert d'aide mémoire et de support pour la collaboration (partager avec l'équipe ce qui est prévu).

Lorsqu'un rapport de test est produit, cette section peut être reprise dans ce rapport pour remettre les résultats du test en contexte.

Les points abordés ci-dessous sont le minimum à prendre en considération dans la préparation des tests.

Explications

Le déroulement dépend du temps dont on dispose avec le participant et des objectifs du test. Voici un exemple de déroulement standard pour des tests en présence modérés :

Accueil (5min)	Entretien (5min)	Manipulation (40min)	Questionnaire (10min)
Présentation de l'étude et des objectifs. Signature du formulaire de consentement et autres autorisations. Indemnisation. Etc.	Vérification de quelques caractéristiques sur le participant. Rapide entretien de recherche. Etc.	Lecture des consignes. Manipulation par le participant. Relances de l'évaluateur. Etc.	Retour sur l'expérience utilisateur vécue. Mesure déclarative via des questionnaires standards. Etc.

Explications

Cette partie du document est utile pendant les tests. Elle sert de structure sur le déroulement et permet au modérateur de procéder de manière comparable et systématique avec chaque participant.

Elle contient généralement les sections suivantes et y détaille le contenu et le temps prévu :

• Accueil du participant (formulaire de consentement)
• Entretien pré-test
• Manipulation
• Entretien post-test
• Clôture et remerciements

Exemples

Voici une liste (non exhaustive) des points régulièrement abordés dans l'introduction d'un test utilisateurs :

Quoi	Quand	Exemple
Rappeler quel est le produit étudié.	Toujours	« L'objet de cette étude est [un site Internet, une application mobile, etc.] »
Expliquer les limites du produit étudié.	Lorsque le dispositif testé n'est pas le produit fini.	« Il s'agit d'une maquette (ou d'un prototype), ce qui veut dire que tout ne fonctionne pas à 100% (certains boutons ne marchent pas, les contenus ne sont pas définitifs etc.). »
Donner les objectifs de l'étude.	Toujours	« Nous souhaitons voir dans quelle mesure [ce site, cette application, etc.] est simple et agréable à utiliser pour vous et comprendre à quel point elle répond à vos attentes. »
Rassurer le participant sur le fait que ce n'est pas lui que l'on teste.	Toujours	« Ce n'est pas vous que nous souhaitons tester mais c'est bien [le site, l'application mobile, etc.]. Il n'y a pas de bonne ou mauvaise manière de faire et vous ne pouvez pas vous tromper. »
Expliquer le protocole de pensée à voix haute (Think Aloud Protocol).	Lorsque vous décidez d'utiliser le protocole de pensée à voix haute	« Pendant que vous manipulerez [le site, l'application mobile, etc.], je vous demanderai de « penser à voix haute », afin de m'expliquer votre raisonnement (ce que vous pensez, ce que vous aimez, ce que vous n'aimez pas, ce que vous comprenez, ce que vous ne comprenez pas, etc.). »
Rassurer le participant sur le fait qu'il ne puisse pas vous vexer.	Toujours	« Ce n'est pas moi qui ait réalisé cette maquette ; j'interviens uniquement pour faire passer ces tests. Ne craignez pas de me vexer lorsque vous vous exprimerez. »
Rappelez ce qui est enregistré et pourquoi. Note : un formulaire de consentement doit être signé en complément.	Lorsque vous enregistrez	« Je vous rappelle que cet entretien est enregistré afin de nous permettre de garder une trace de l'échange et y revenir plus tard lors de l'analyse. Sachez toutefois que, cet enregistrement est anonyme, et que seuls vos prénom, âge et profession seront mentionnés. Rien de plus. »
Essayer de recréer une utilisation réelle.	Toujours	« Si en temps normal, chez vous, vous vous seriez arrêté, n'hésitez pas à me le dire. »
Informer sur la présence d’observateurs.	Lorsqu'il y a des observateurs	« Derrière le miroir, il peut y avoir des observateurs. »
Rappeler la durée du test.	Toujours	« Cet entretien durera 1h00. »
Permettre au participant de poser ses questions.	Toujours	« Avez-vous des questions avant de commencer ? »

Explications

Cette section du guide d'animation est la plus importante : les scénarios doivent être liés aux objectifs du test.

Faire le meilleur usage du temps

Le temps passé avec des utilisateurs est précieux ; le défi lors d'un test est d'utiliser le temps au mieux. Pour définir le déroulement, il convient de s'appuyer sur les objectifs du tests : que souhaite-t-on apprendre/valider/mesurer ?

Chaque consigne ou question de relance pendant un test doit servir ces objectifs.

La rédaction des consignes

Quel que soit le niveau de précision (fidélité) de la maquette, le temps dont vous disposez pour préparer et animer les tests, la qualité du recrutement que vous pouvez effectuer, etc., le principal point d'attention doit être sur la rédaction des consignes.

Les consignes doivent être :

• réalistes,
• compréhensibles (claires et synthétiques)⁷,
• non directives,
• cohérentes avec le produit.

Tout doit avoir du sens pour l'utilisateur

Si l'utilisateur est obligé de compléter lui-même la consigne dans sa tête pour qu'elle ait du sens pour lui, c'est probablement que la situation n'est pas réaliste (ou qu'elle manque d'éléments de contexte) ou que le but à atteindre n'est pas clair.

Exemple de consigne : "Pendant un trajet en train, vous discutez un(e) ami(e) via WhatsApp depuis votre téléphone. En même temps, vous feuilletez un magazine de décoration d'intérieur. Un objet vous plait et vous souhaitez avoir l'avis de votre amie sur celui-ci. Comment procédez-vous ?"

Utiliser le langage de l'utilisateur, pas celui du produit :

1. Inscrire la consigne dans une situation d'utilisation.
   • Elle peut être globale à tout le test (ex. "Nous allons imaginer que vous êtes en voyage dans une ville que vous ne connaissez pas.") ou elle peut évoluer au fil du test (ex. "Pour la suite du test, nous allons maintenant imaginez que vous êtes dans une ville que vous connaissez très bien.")
   • Cette description du contexte est utile pour permettre au participant à se projeter dans une situation (qui doit être réaliste pour lui) qui va donner du sens à sa manipulation : où est-il ? avec qui ? à quel moment de la journée ? quels objets sont à sa porté ? est-il pressé ? etc.
2. Donner un but à l'utilisateur, pas une liste d'actions.
   • Chaque consigne donne un objectif, un but à atteindre au participant. Ce but doit être un but d'usage humain (ex. "vous souhaitez informer vos amis de votre retard") et non un but fonctionnel du produit (ex. "vous souhaitez envoyer un message audio à vos amis pour les prévenir de votre retard").
3. Faire attention au "word matching".
   • Il faut également faire attention aux termes utilisés dans la consigne notamment pour éviter que les participants utilisent des fonctions du produit uniquement par reconnaissance du terme. Il est habituellement recommandé de ne pas utiliser les mots qui apparaissent sur l'interface dans la consigne.

L'ordre des tâches

• Où est-ce que l'utilisateur commence ?
  • Si les participants ciblés n'ont jamais utilisé le produit, prévoyez une mise en situation afin de leur expliquer comment ils ont découvert le produit en question.
  • Éventuellement, prévoir une tâche de découverte/exploration libre.
• L'influence d'une tâche sur une autre.
  • Faire attention à l'influence d'une tâche sur une autre tâche, par exemple pour comparer des interfaces/parcours⁸.

Sans modérateur

Lorsque les tests ne sont pas modérés, les consignes sont directement affichées sur le dispositif du testeur (ex. un petite fenêtre rajoutée sur l'interface d'un site web). Dans ce cas, l'utilisateur pourra auto-administrer le déroulement de son test.