UX CALENDAR – 22 DÉCEMBRE – 5 questions à éviter en test utilisateur et que demander à la place

La construction des questions en test utilisateur est très importante pour collecter des insights fiables et utiles. Prenons en exemple quelques erreurs courantes : nous allons voir comment les éviter et améliorer nos protocoles de test.

1 – Comment utiliseriez-vous ce produit ?

Attention à toutes les questions qui demandent à l’utilisateur de se projeter dans un comportement futur. Il faut toujours prendre le « déclaratif » avec des pincettes, même quand l’utilisateur rapporte son souvenir d’une situation réelle, et il est particulièrement difficile de s’y fier quand l’utilisateur doit imaginer une situation fictionnelle : ce qu’on imaginerait faire ne va pas souvent correspondre avec ce que l’on va faire effectivement.

“Comment utilisez-vous / avez-vous utilisé ce produit?” 

Au lieu de lui demander d’imaginer le futur, on peut plutôt poser à l’utilisateur des questions sur le présent ou le passé : “comment utilisez-vous aujourd’hui des produits ou fonctionnalités similaires ?”, “Quelles sont vos expériences passées avec des produits ou fonctionnalités similaires ?”

On peut aussi constater son utilisation spontanée du produit durant le scénario du test. Pour cela, on essaiera de guider le moins possible l’utilisateur, quitte à revenir sur certains écrans pour poser les questions et tester les éléments qui n’auront pas été vus précédemment.

2 – Est-ce qu’on devrait ajouter cette fonctionnalité ?

Quand on demande à un utilisateur s’il souhaiterait qu’on ajoute un élément en plus : une information, une fonctionnalité, une page, etc. on demande encore une projection dans le futur. Ce ne sera pas assez concret pour l’utilisateur, qui va pratiquement toujours dire « oui » : il y a peu de raisons d’être contre un ajout. Ce sera difficile lors de l’analyse de calculer la part des « oui » convaincus pour évaluer vraiment l’appétence de la fonctionnalité. On ne pourra pas tirer de conclusion.

Observation du comportement 

Ici, plutôt qu’une question, on préférera observer le comportement lors du test. Le mieux pour évaluer l’appétence d’une fonctionnalité sera toujours d’observer son utilisation directement ou si elle n’existe pas encore d’observer le comportement autour de son absence : par exemple, on remonte un irritant que cette fonctionnalité pourrait corriger.

3 – Est-ce que vous comprenez cet élément ?

Demander à l’utilisateur d’auto-évaluer sa compréhension est risqué : au-delà du biais de désirabilité sociale dans le contexte de test, l’utilisateur n’est pas toujours bon juge de sa propre compréhension. Iel peut parfaitement comprendre un contenu ou une fonctionnalité et ressentir de la complexité, ou par manque de confiance en soi, ne pas croire qu’iel comprend, et parallèlement iel peut avoir l’impression d’avoir compris et passer à côté de tout ou partie du sens.

“Pouvez-vous m’expliquer cet élément ?” 

On demandera plutôt à l’utilisateur d’expliquer l’élément avec ses propres mots. Quand la réponse est incorrecte ou imprécise, on y ajoutera toujours des relances pour s’assurer qu’elles constituent bien une incompréhension de la part de l’utilisateur plutôt qu’une difficulté à s’exprimer ou expliquer un élément en fait compris. Dans un 2nd temps, on peut aussi demander s’ils ont trouvé ça clair ou facile à comprendre, on aura alors évalué deux choses : la compréhension mais aussi la complexité perçue par l’utilisateur.

4 – Comment pourrait-on améliorer cet élément ?

On évite généralement de recruter des participants qui travaillent dans le design digital pour ne pas obtenir une évaluation experte à la place d’un test utilisateur. Par conséquent, nos utilisateurs ne sont pas des designers et leur demander de se mettre dans ce rôle est complexe et risqué.

“Dans un monde idéal, comment fonctionnerait cet élément ?”

Pour savoir comment améliorer un élément, on va plutôt observer les difficultés de l’utilisateur et lui demander de nous les expliquer, de détailler ce qui ne fonctionne pas et pourquoi. Au designer de trouver la solution à ces difficultés : c’est un métier !

On peut en fait poser cette question, pas pour incorporer le design souhaité tel quel, mais en relance pour comprendre encore mieux ce qui bloque. On la formulera plutôt ainsi : « Dans un monde idéal, que pourriez-vous faire avec cet élément ? Comment fonctionnerait-il ? ».

5 – Est-ce que ce produit est esthétique ?

Les goûts et les couleurs sont très subjectifs et quand on demande aux utilisateurs d’évaluer l’esthétique d’un produit, d’un site, d’une page, on se retrouve avec des données contradictoires : la couleur va plaire à la moitié des répondants, et déplaire à l’autre moitié. L’exemple de la couleur est pertinent car c’est souvent cet élément qui frappe un participant non-designer en premier, et c’est aussi l’élément qu’on peut rarement modifier.

“Que vous évoque le design du site ?”

L’esthétique reste un axe important à évaluer, car il participe à la perception d’utilisabilité de l’interface. Les utilisateurs peuvent nous apprendre beaucoup sur leur perception du produit par leur opinion sur l’esthétique. On préférera demander « que vous évoque le design du site ? », « quels mots vous viennent en tête pour qualifier l’esthétique du site ? » et relancer les remarques spontanées « Vous dites qu’il y a trop de couleurs, pouvez-vous m’expliquer pourquoi ? Quelles sont les conséquences de ce ‘’trop de couleurs’’ ? Que ressentez-vous ? ».

 

 

Take away

Lors d’un test utilisateur, mettre en parallèle des comportements aux déclarations des participants est le meilleur moyen de collecter de la donnée pertinente.

Lorsqu’on challenge une question bancale dans notre protocole, il faut toujours revenir à sa question de recherche et se demander :

  • Pourquoi veut-on poser cette question à l’utilisateur ?
  • Que cherche-t-on à mesurer ?
  • Comment peut-on le mesurer ?

 

Marie EUZEN, UX Designer @UX-Republic


 


Nos prochaines formations