Aider les participants aux tests d'utilisabilité
Je viens de terminer une série de tests d'utilisabilité en laboratoire et de co-présentation dans le cadre d'un audit d'utilisation pour une application cartographique basée sur le Web. J'ai dix tâches pour les participants qui les obligent à effectuer des activités de carte typiques (zoomer sur cette zone; trouver cet emplacement, mesurer la distance entre x et y, etc.).
La première tâche consiste à zoomer (il y a une petite loupe dans la barre d'outils qui permet à l'utilisateur de le faire) sur la carte à l'emplacement de son choix.
Mais pour l'un des participants, ils ont simplement impossible de trouver l'outil de zoom. Ce sont de bonnes informations car nous pouvons prendre des mesures concrètes pour les rendre plus visibles. Cependant, beaucoup des tâches suivantes ont nécessité l'utilisation de cet outil de zoom; sans savoir comment zoomer le test n'a pas pu être terminé. J'ai donc indiqué au participant où se trouvait l'outil de zoom. Je me rends compte que c'est un gros non-non dans les tests d'utilisabilité mais j'ai senti que c'était nécessaire pour terminer le test.
Ma question est: aurais-je dû intervenir et aider l'utilisateur ou aurais-je dû terminer le test? À quel moment abandonnez-vous un test d'utilisabilité pour garder un contexte plus réaliste?
Il y a beaucoup de gens qui diront que votre test aurait dû se terminer à cette première étape - lorsque vous avez noté à juste titre que le participant ne pouvait pas passer la première étape - et vous devriez simplement enregistrer ce point de données et passer au participant suivant . Aucun problème avec ça.
Une fois que j'étais ce testeur qui ne pouvait pas trouver l'outil de zoom - sauf que c'était "trouver (une icône ésotérique représentant un) outil dans la barre d'outils Google ", il y a de nombreuses années, lorsque la barre d'outils Google était un module complémentaire de navigateur et que Google a amené beaucoup de personnes sur le campus pour des tests d'utilisabilité. C'était la première question de leur test. J'ai dit "vraiment, je ne peux pas le voir. J'imagine que ce serait ici ou ici ou ici". Ils me l'ont fait remarquer, un peu comme vous l'avez fait avec l'outil zoom, et nous avons poursuivi le test. Je ne sais pas comment ils ont utilisé les données, mais ils ont continué avec le même script.
Pour garantir des données sensées (par exemple, tous les utilisateurs effectuant tous les tests), je ne prendrais pas en compte les autres données de cet utilisateur (ou les miennes, dans la situation ci-dessus) lors du calcul des résultats, car à mon avis, elles seraient entachées/biaisées , MAIS il n'y a rien de mal à transformer le reste de votre temps avec l'utilisateur (ou l'utilisateur potentiel) en quelque chose à partir duquel vous pourriez obtenir des données bénéfiques supplémentaires. Peut-être que cela passe par le reste du test et obtenir des réponses/voir des actions et simplement rassembler les données sans les calculer ou les considérer de la même manière, mais peut-être que cela déplace l'heure du test vers un test différent .
Je considérerais votre situation similaire à celle posée dans Comment sauver un test d'utilisabilité dont le participant manque de confiance? , dans lequel les réponses incluaient des idées comme abandonner les tâches en conserve pour une tâche définie par soi-même, tourner le " tester "dans une" interview ", et ainsi de suite.
Oui, je réponds essentiellement "ça dépend". Bien que j'aurais probablement choisi de transformer le test en quelque chose d'autre, je pourrais aussi continuer le test mais ne pas peser autant les résultats - cela dépend du nombre de testeurs que j'avais dans la file d'attente et de l'endroit où j'étais dans le processus de test.
Vous ne terminez pas le test, mais vous ne signalez pas non plus l'outil.
Si quelqu'un est désespérément coincé, alors à des fins sommatives, vous marquez cette session comme "Impossible de terminer la tâche (sans aide)" et l'incluez dans la catégorie No Joy à des fins statistiques. Tant que vous avez des règles cohérentes pour juger lorsque l'utilisateur ne peut pas continuer seul, vos données quantitatives seront parfaitement valides, et vous pouvez continuer la session et collecter plus de données pour aider à éclairer la conception.
Ironiquement, la raison pour ne pas signaler l'outil est de collecter plus de données. Vous savez que l'utilisateur n'a pas pu trouver l'outil, mais vous ne savez probablement pas pourquoi. En général, une incapacité à trouver quelque chose sur une page peut être due à:
Les utilisateurs l'ont regardé, mais il n'a pas reconnu l'étiquette/l'icône.
Les utilisateurs l'ont regardé mais ne l'ont pas vu car il était perdu dans l'encombrement.
Les utilisateurs le cherchaient ailleurs que là où vous l'aviez mis.
Les utilisateurs recherchaient quelque chose de complètement différent de ce que vous avez utilisé.
Chacune de ces raisons a des réponses de conception très différentes. Les données oculaires peuvent aider à réduire les raisons possibles, mais les données d'entrevue sont également souvent nécessaires.
Ne montrez donc pas l'outil à l'utilisateur. Tout d'abord, posez des questions pour diagnostiquer le problème:
Qu'essayez-vous de faire? (J'ai besoin de zoomer)
Que recherchez-vous pour zoomer? (Un truc coulissant, comme dans Google maps).
D'accord, c'est une bonne façon de le faire, mais nous essayons une méthode différente. Quelle étiquette ou icône aurait Zoom? (Je ne sais pas. Habituellement, c'est une loupe)
(pause)
Où le cherchez-vous? (Ici en haut.)
Que voyez-vous là? (Une imprimante pour l'impression, l'icône Enregistrer, une punaise pour marquer un point.)
Oh. La punaise est censée être une loupe. Nous allons y travailler.
Là. Maintenant, vous connaissez deux façons d'améliorer la conception (utilisez un curseur si possible, retravaillez l'image de la loupe) et quatre façons pas pour l'améliorer (passer d'une loupe à un autre objet, rendre le contrôle plus grand ou plus audacieux, le déplacer ailleurs).
Il s'agit de la règle générale pour les tests d'utilisabilité. Pour chaque problème rencontré par l'utilisateur, évitez de donner la solution. Mais n'abandonnez pas. Au lieu de cela, posez des questions pour recueillir des données et, dans le processus, guide l'utilisateur se rapproche progressivement de la solution. Et puis continuez avec le test d'utilisabilité.
Bien sûr, vous devez aider l'utilisateur afin que vous puissiez obtenir autant d'informations que possible de la session d'utilisation. Vous avez trouvé un problème d'utilisation, mais il pourrait y en avoir d'autres et ces problèmes pourraient être assez indépendants (peuvent être traités individuellement sans reculer et repenser le tout).
Vous ne voulez pas vous engager dans N tests d'utilisabilité et N séries de correctifs pour résoudre N problèmes d'utilisabilité un par un.
C'est long et coûteux.
Un test d'utilisabilité n'est pas 100% scientifique. Si c'était le cas, vous le rendriez en double aveugle ou quelque chose; vous ne seriez même pas présent dans la salle pour ne pas pouvoir influencer les sujets de quelque manière que ce soit (langage corporel, etc.).
Vous n'essayez pas de publier quelque chose dans une revue scientifique ou d'obtenir une subvention gouvernementale pour la recherche, etc. (Et ces gens truquent beaucoup.)
Nous avons eu exactement le même problème. L'utilisateur avait reçu une tâche et ne pouvait pas comprendre comment le faire. J'ai patiemment attendu quelques minutes pour qu'ils essaient de le trouver. Finalement, j'ai fait ce que vous avez fait et je leur ai juste dit, afin qu'ils puissent continuer le reste du test.
Je pense que lorsque les gens disent "N'aidez pas la personne qui fait le test d'utilisabilité", ce qu'ils veulent vraiment dire, vous ne devez pas vous asseoir là et les tenir, et les guider pas à pas. Vous essayez de simuler ce qui se passera lorsque votre programme ou site Web sera utilisé à l'état sauvage.
Mais, s'ils se retrouvent dans une situation comme celle que vous décrivez, dans la nature, ils vont abandonner, allez sur un autre site, désinstallez le programme ou jetez votre produit d'une autre manière.
Comme vous le mentionnez, si cela se produit, vous devez noter ce problème, car c'est un gros problème. Surtout si cela arrive avec beaucoup d'utilisateurs.
Mais une fois arrivé à ce point, il n'y a rien de mal à réduire vos pertes, à leur dire juste assez pour recommencer et passer à autre chose pour faire des tests d'utilisabilité sur autre chose pendant que vous les avez là. Cela n'a aucun sens de jeter la possibilité d'apprendre des choses supplémentaires, simplement parce qu'elles sont perplexes sur une chose.
Notre protocole était très simple. Certains utilisateurs commencent à poser des questions avant même de regarder l'écran (triste mais vrai:) #). Ainsi, la première fois que l'utilisateur demande, vous répondez: "Veuillez essayer de trouver la solution vous-même en regardant l'écran" (après un certain temps, vous pouvez dire des choses comme ça de manière assez convaincante). Si l'utilisateur est toujours bloqué (gardez un œil silencieux sur votre chronomètre et accordez-lui une minute ou tout autre intervalle de temps que vous avez convenu avec le reste de votre équipe), puis indiquez-lui la fonctionnalité qu'il devrait utiliser avec une douceur mais sans condescendance. sourire. Mais avant de les laisser continuer, demandez-leur pourquoi ils ont eu un problème ici. Vos résultats de test utilisateur doivent inclure les informations selon lesquelles l'utilisateur a eu un problème [ici] et que la raison du problème est [ceci]. Ne vous fiez pas aux enregistrements vidéo ou audio, yada, ils prennent des heures à réviser et à coder (généralement 3 fois plus longtemps). Parlez simplement à l'utilisateur et notez-le dans votre presse-papiers.
À la fin de la session, demandez à votre utilisateur de faire une rétrospective pendant une minute et de vous dire où et pourquoi il a eu les plus gros problèmes, et où il a senti qu'il tirait vraiment dessus (rassemblement AKA `` incident critique ''). Ahem ... notez ces données: c'est votre mine d'or.
Bien sûr, cela ne vous donnera pas de bonnes données pour le "temps passé sur la tâche" ou toute autre mesure basée sur les performances, mais c'est un type d'évaluation différent.
Peut-être juste pour voir les résultats d'autres tests, l'intervention a été une bonne décision à ce moment-là, mais apprenez de cette information, car soit:
- Ce n'est peut-être pas bon que vos tests reposent tous sur une autre fonctionnalité;
- Si votre application ne s'appuie principalement sur cette fonctionnalité, il est certainement désastreux que tout partie de votre le groupe de test n'a pas pu trouver et/ou utiliser cette fonctionnalité.
En d'autres termes, vous devez soit rendre votre application plus utilisable lorsque cette fonctionnalité n'est pas utilisée (même si vous précisez où elle est accessible, il y aura peut-être toujours des gens qui ne pourront pas l'exploiter correctement/sans trop de difficultés), ou vous devriez faire ressortir davantage cette fonctionnalité dans l'interface utilisateur, en la faisant attirer l'attention (taille, couleur, mouvement, tout ce que vous trouvez approprié). Et puis assurez-vous que travailler avec lui est un jeu d'enfant.
L'intervention du facilitateur est quelque chose qui surgit parce que les gens sont imprévisibles! Et aussi, ceci est un exemple qui illustre l'aspect le plus précieux du test avec des personnes réelles - les hypothèses peuvent être effacées ...
L'intervention était nécessaire dans ce cas et non, vous n'auriez pas dû terminer le test - c'est irréaliste étant donné la logistique pour obtenir les participants. Mais au lieu de signaler l'emplacement de l'outil, vous pouvez les demander en demandant "Où pensez-vous trouver cela?" "Où chercheriez-vous normalement cela?" "Où est-ce situé sur l'application que vous utilisez habituellement?"
Cela les aide à localiser l'outil (ou une information, etc.) sans les faire se sentir "idiots" ou stressés de ne pas pouvoir le découvrir par eux-mêmes. N'oubliez pas, c'est assez stressant pour être observé en tant que participant!
J'ai participé une fois à une session où j'étais le participant et les animateurs ne sont pas intervenus car je me suis retrouvé coincé en essayant de terminer une tâche et ils n'ont rien retiré de la session, à l'exception de 20 minutes de moi de plus en plus frustré.