Lorsque je modère les tests utilisateurs, j'ai parfois du mal à amener les utilisateurs à verbaliser leurs processus de pensée - à penser à haute voix.
Les utilisateurs sont très bons pour me donner un commentaire continu sur d'autres choses - que ce soit s'ils aiment les couleurs, ce avec quoi ils pensent que d'autres utilisateurs pourraient avoir du mal ou comment ils pourraient reformuler les étiquettes. Ils seront lyriques sur la façon dont ils détestent le violet, ou sur la façon dont le bleu sarcelle rend une application "éducative", et traitent généralement toute la session comme un processus de "collecte d'opinions". Mais ils ne le font pas réellement pensez à haute voix.
Donc. Comment puis-je expliquer le processus de réflexion à voix haute dans un test utilisateur?
Utilisez un canard en caoutchouc.
Mettez un petit canard en caoutchouc près de l'utilisateur. Dites à l'utilisateur le nom du canard en caoutchouc - plus il ne convient pas, mieux c'est. Le mien s'appelle Frank The Duck.
Vous voyez, Frank The Duck est un peu stupide. Je dis à l'utilisateur que Frank ne sait pas comment utiliser le système et que je dois donc l'enseigner. Le problème, cependant, est que puisque je suis un technicien, je suis vraiment mal à expliquer les choses qui doivent être expliquées en termes pratiques et quotidiens - l'anglais ordinaire.
Donc, maintenant, l'utilisateur a une petite mission humoristique à accomplir avec moi. Je mets l'utilisateur en position de pouvoir, lui faisant enseigner à quelqu'un, lui donnant les rênes de l'expérience. Je dis à l'utilisateur que je suis incompétent, afin que l'utilisateur se sente plus en confiance en lui-même et en ce qui doit être fait. Et, eux, j'encourage l'utilisateur à expliquer des choses comme il enseignerait à quelqu'un.
L'enseignement est une expérience intéressante. Cela met votre cerveau sur un mode différent qui change beaucoup votre façon de penser et de parler, créant une sorte de pont direct entre vos idées et votre bouche. Si l'utilisateur a besoin d'expliquer, il sentira que ce qu'il doit faire est un peu inutile - vous savez déjà ce qu'il fait, pourquoi devrait-il s'embêter à faire quelque chose comme ça? Cependant, si l'utilisateur va guider quelqu'un dans l'utilisation du système, les choses changent. L'utilisateur est désormais aux commandes, il est le guide. Il est responsable de l'accomplissement de la tâche.
Vous pouvez acquérir une certaine expérience des chaînes Let's Play sur YouTube. Ces gens parlent rarement lorsqu'ils jouent seuls à la maison. Mais, quand ils ont un public - même silencieux - ils deviennent vraiment bavards, expliquant chaque petit peu de ce qu'ils font, le mélangeant avec quelques commentaires latéraux ici et là. Leur véritable public, cependant, n'est qu'un appareil photo, un appareil électronique sans vie à proximité. Avez-vous déjà eu un ami près de chez vous en jouant à des jeux vidéo, ou même un petit frère? L'effet est à peu près le même.
Ne leur demandez pas d'expliquer - demandez-leur d'enseigner. Pour vous guider. Pour vous montrer des trucs. Qu'ils soient responsables du voyage. La confiance supplémentaire vous donnera de très bons résultats.
Jakob Nielsen suggère faire et montrer aux participants une vidéo d'une minute d'une session de réflexion. En résumé, ses critères pour une telle vidéo sont:
Il inclut un exemple d'une telle vidéo dans l'article ci-dessus.
J'utilise des questions courantes comme:
Éloignez-les de "ce avec quoi les parents pourraient avoir un problème" - vous ne testez pas le produit avec leurs parents ou quelqu'un d'autre.
Je commence également par dire au candidat que la conception/construction n'est pas la mienne afin qu'il ne puisse pas m'offenser avec des commentaires négatifs (c'est parfois la source des commentaires "mes parents" comme ils le souhaitent) vous alerter d'un problème mais ne pas vous offenser personnellement).
Je leur dis également que nous testons le produit et non l'utilisateur, nous avons donc besoin qu'ils se comportent aussi normalement que possible - si quelque chose ne fonctionne pas bien ou tourne mal, ce n'est pas de leur faute; cela signifie que nous avons trouvé un bug dans le produit.
Enfin, essayez de les amorcer en leur disant le genre de choses que vous voulez entendre: leur réflexion sur la tâche qu'ils essaient d'accomplir, tous les problèmes qu'ils rencontrent, tous les moments d'indécision ou de confusion et leur raisonnement pour chaque action.
Le but de l'utilisation d'un protocole de réflexion à voix haute est d'entendre ce qui se passe dans la tête des utilisateurs lorsqu'ils utilisent (généralement) un système inconnu. Et oui, ce n'est pas une activité qui vient naturellement.
Semblable à @scottishwildcat, je montre habituellement moi-même la réflexion à haute voix, puis je donne au sujet une courte tâche pour qu'ils s'exercent. (J'aime cette démo vidéo.)
Semblable à @ Andrew-Martin, je pose des questions incitatives tout au long du silence des sujets. Surtout, "Que voyez-vous à l'écran?" "Que cherchez-vous?" "Qu'essayez-vous de faire?"
Définissez vos objectifs d'étude avant de poser des questions
Cadrer correctement les questions peut empêcher vos participants de dire "J'aime le violet"
Essayez de comprendre les objectifs de l'utilisateur (si possible) au préalable
Parfois, il est utile de demander aux participants quels sont leurs objectifs avant de commencer à effectuer une tâche, en particulier si vous ne faites pas de test standard (tâches prédéfinies). Cela peut vous donner un bon aperçu/comprendre pourquoi les gens cliquent/ce qu'ils recherchent.
Mettez les participants à l'aise - ce n'est pas un test
Les participants doivent se sentir à l'aise et percevoir les personnes qui effectuent les "tests" comme amicales. Définir les bonnes attentes avant le test pourrait aider les participants à être plus ouverts et à parler davantage. Le mot "test" peut effrayer les participants; ils peuvent penser "oh ils me testent, je pourrais faire quelque chose de mal". Donc, avant de commencer les tâches, vous pouvez expliquer aux participants que vous êtes ici pour écouter et apprendre d'eux et que ce n'est pas un test/évaluation de la personne. Dites-leur également qu'ils ne peuvent rien dire/faire de mal
Faites-leur réfléchir davantage à ce qu'ils font dans la vie réelle et à la façon dont cela se rapporte à eux
"En pensant aux choses habituelles que vous faites avec ce site, qu'en pensez-vous? Expliquez quelques scénarios. Que trouvez-vous moins/plus efficace pour votre travail/shopping/etc.?"
Donnez des exemples de parler à haute voix
Imaginez que vous êtes un participant et montrez-leur comment vous pouvez parler
Soyez un bon auditeur
Demander pourquoi?" les questions ne se précipitent pas dans la prochaine tâche
À quelques reprises, j'ai pensé que les participants ne voyaient pas de lien. Demander "pourquoi" ils n'ont pas cliqué sur le lien a expliqué qu'ils ont remarqué le lien mais l'ont trouvé sans rapport avec leur tâche qui est un problème différent à résoudre
Écoutez ce que les participants vous disent; il est parfois plus important de poser de nouvelles questions et de sauter quelque chose du script pour en savoir plus
Lorsque vous remettez au participant sa première tâche, dites: "Veuillez lire ceci à haute voix, puis allez-y et faites-le, et n'oubliez pas de penser à haute voix au cours de la session." Si le participant est calme et a évidemment oublié de penser à haute voix, rappelez-leur, en disant: "N'oubliez pas de penser à haute voix." Ne demandez pas, "À quoi pensez-vous? = ", ou d'autres variantes. Ils ne pensent peut-être rien du tout à ce stade, mais avant de dire quoi que ce soit, assurez-vous qu'ils ont vraiment oublié de penser à haute voix.
Vous ne voulez pas les déranger pendant qu'ils font attention à quelque chose à l'écran ou se concentrent sur un problème. Si le participant vous pose une question pendant l'étude, votre première réaction peut être d'y répondre, afin de l'aider. Cependant, avant de faire cela, essayez de les rediriger avec votre propre question, comme: "Que pensez-vous que vous devriez faire?", ou "Que feriez-vous normalement ici? = "Une fois que vous avez leur réponse, vous pouvez choisir de fournir des informations.
Je suis d'accord avec les questions sélectionnées d'Andrew Martin.
Sachez également que si vous demandez à l'utilisateur une sorte de justification de ses actes, la charge cognitive de la tâche globale est assez lourde (cela signifie que le temps nécessaire pour effectuer la tâche sera affecté et que la la capacité à faire face à de nouveaux problèmes peut également être affectée; vous ne pouvez pas évaluer l'efficacité des tâches dans ces conditions). Et vous devrez très souvent demander à l'utilisateur de vous expliquer.
Comme ce type de protocole de réflexion à haute voix n'est pas naturel, l'utilisateur a besoin de temps pour s'y habituer. Afin d'éviter des données de mauvaise qualité en début de session, et pour rendre l'utilisateur plus à l'aise, je vous propose une pré-session en formation, pendant au moins 15 minutes, sur une tâche de réflexion à voix haute simple et ludique. Ensuite, la réflexion à haute voix sera plus facile pour votre utilisateur pendant la session principale.
Je ne suis pas convaincu par une démonstration live ou vidéo, qui est passive, et qui ne fait pas pratiquer l'utilisateur seul. Alors qu'une session de formation facile permettrait à l'utilisateur de s'habituer au protocole de réflexion à voix haute.
En fait, il ne s'agit pas de faire comprendre à l'utilisateur ce qu'est le penser à haute voix, mais de le former à un protocole de forte charge cognitive
Je suis un preneur de notes habituel. Chaque fois que j'utilise une nouvelle interface ou un nouvel outil, je prends tellement de notes si souvent que je trouve nécessaire de garder un éditeur de texte ouvert en arrière-plan à tout moment.
Souvent, les notes sont faites pour mes propres considérations de conception et de réflexion, mais parfois je les structure sous forme de commentaires qui pourraient être utilisés pour signaler plus tard des bogues ou demander de nouvelles fonctionnalités.
Hélas pour vous que tous vos testeurs ne sont pas intéressés par u.i. design et similis, mais peut-être que si vous leur dites que s'ils voient quelque chose qu'ils n'aiment pas ou considèrent comme non intuitif, ils devraient formuler comment ils le remanieraient et expliquer pourquoi.
Du côté des pros, cela les encouragerait à égotiser leur approche des interfaces. Peut-être que leurs idées vous aident à élargir vos propres conceptions.
Inconvénients: la plupart des utilisateurs ne sauraient pas comment corréler leurs propres attentes avec les exigences fonctionnelles. Ils divergeraient et ne resteraient pas simples, et se concentreraient sur tout petit problème qu'ils auraient vu ou rencontré. De plus, vous auriez besoin de faire un traitement supplémentaire sur les notes si elles n'expliquaient pas complètement l'objet de leur plainte et se sont affinées sur le sujet de leurs améliorations.
S'il s'agit d'un test où vous accordez une attention complète et présente au testeur, vous pouvez toujours l'alerter lorsqu'il s'éloigne trop du sujet en question, ou sinon ne fournit pas d'informations utiles.
Il s'agit de "gérer la session"
S'ils se concentrent sur l'écran et effectuent la tâche, j'ai trouvé que les petites invites "Keep Talking" sont tout ce dont ils ont besoin. Vous ne voulez pas de silence sur l'enregistrement audio.
S'ils arrêtent de regarder l'écran et vous regardent pour parler de la session, alors vous devez être prêt à "arrêter" cette conversation si elle commence à ne pas être utile (parfois c'est le cas, parfois ce ne l'est pas), et les remettre sur la tâche en regardant l'écran.