ipm:think_aloud

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

ipm:think_aloud [2012/06/02 20:28] (current)
gilles created
Line 1: Line 1:
 +====== Penser tout haut ("​think aloud"​) ======
 +
 +===== Principes et objectifs =====
 +
 +La méthode "​penser tout haut" permet aux chercheurs ou concepteurs de comprendre, au moins en partie, quel est le processus mental que suit un utilisateur lorsqu'​il utilise une interface (ou produit, un appareil, un manuel) pour effectuer une tâche. ​
 +
 +La méthode consiste à observer l'​utilisateur en train d'​accomplir une tâche, tout en lui demandant de décrire à haute voix ce à quoi il pense, quelles questions il se pose, comment il s'y prend pour réaliser la tâche, quelles sont les difficultés qu'il rencontre. ​
 +
 +Idéalement,​ l'​observateur ne parle pas, si ce n'est pour encourager l'​utilisateur de continuer à penser tout haut. 
 +
 +La méthode est particulièrement intéressante lorsque l'​utilisateur rencontre de difficultés. En temps normal il agit plus vite qu'il ne peut le décrire à haute voix; par contre lorsqu'​une difficulté surgit il ralentit son action et sa description devient plus en phase avec son action. ​ Du coup l'​observateur peu bien corréler l'​action et la pensé de l'​utilisateur.
 +
 +Ce type de méthode évalue l'​effectivité de l'​interface (peut-on faire la tâche?) mais pas son efficacité (en temps). Elle permet aussi d'​évaluer la satisfaction de l'​utilisateur.
 +
 +===== Protocole de test =====
 +
 +==== Avant le test ====
 +
 +Préparer la ou les tâches que l'​utilisateur devra effectuer. ​
 +
 +Préparation de l'​utilisateur
 +
 +  * s'​assurer que l'​utilisateur a bien compris que c'est l'​interface que l'on test et pas lui-même, que toute difficulté qu'il rencontrera sera de votre faute et pas de la sienne
 +  * lui décrire le but de la tâche mais pas les étapes pour y arriver et lui dire que c'est lui, et pas vous, qui déterminera quand la tâche est terminée
 +  * lui expliquer qu'il ne recevra qu'une aide minimale durant le test et qu'il devra autant que possible trouver lui-même le moyen de réaliser la tâche
 +  * faire un essai de familiarisation avec la procédure. Par exemple demander à l'​utilisateur de compter le nombre de fenêtres qu'il y a dans son appartement en pensant à haute voix.
 +
 +==== Pendant le test ====
 +
 +L'​idéal est d'​avoir deux observateurs,​ pas plus sinon l'​utilisateur sera mal à l'aise
 +
 +Noter tout ce que dit l'​utilisateur
 +
 +Si nécessaire inciter l'​utilisateur de continuer à parler
 +
 +À certains moments poser des questions à l'​utilisateur :
 +  * à quoi pensez-vous maintenant ?
 +  * pourquoi avez-vous fait cela ?
 +
 +Mais éviter d'​introduire un biais en l'​aidant ou en lui faisant des suggestions
 +
 +Si l'​utilisateur est bloqué
 +  * on peut décider des l'​aider ou non
 +  * si on l'aide il faut 1) lui demander ce qu'il aurait fait sans aide; 2) prendre note de ce qu'on a dit à l'​utilisateur et de ce qui s'est passé par la suite
 +
 +==== Fin du test ====
 +
 +  * lorsque l'​utilisateur estime avoir terminé la tâche, le remercier pour sa participation
 +  * lui demander s'il a des commentaires additionnels
 +  * le remercier à nouveau
 +  * préparer pour l'​utilisateur suivant : remettre le matériel dans l'​état initial; corriger d'​éventuelles erreurs de protocole
 +
 +===== Variantes =====
 +
 +On peut ne demander à l'​utilisateur de parler qu'à certains moments, lorsqu'​il effectue certaines sous-tâches déterminées à l'​avance.
 +
 +Si la tâche est complexe il peut être difficile de parler en même temps. Dans ce cas on demandera à l'​utilisateur des rapports périodiques,​ à intervalles de temps fixés, sur ce qu'il est en train d'​essayer de faire.
 +
 +===== Intérêt de la méthode =====
 +
 +Il s'agit d'une méthode simple à mettre en oeuvre (une fois que l'on dispose d'un prototype d'​interface de basse ou de moyenne fidélité) et qui fournit des résultats de haute qualité, en particulier sur les points posant problèmes.
 +
 +Les données primaires récoltées sont l'​observation des actions de l'​utilisateur et l'​écoute de ce qu'il dit au sujet de ses intentions, de ses actions, etc.
 +
 +En plus de la mise en évidence de problèmes, on peut en tirer une meilleure compréhension du modèle mental que se fait l'​utilisateur. La terminologie qu'il emploie est également révélatrice,​ en particulier si elle diverge de la terminologie de l'​interface.
  
  • ipm/think_aloud.txt
  • Last modified: 2012/06/02 20:28
  • by gilles