Comment savez-vous quand une conception échoue à un test d'utilisabilité?
Une technique pratique que j'ai apprise du mauvais travail ...
Il y a des années, j'ai passé une partie maladroite de ma carrière en tant que concepteur pédagogique en créant des cours pour l'apprentissage en ligne. C’était une mauvaise passe et j’ai évolué avec bonheur, mais une partie de ce travail a fait de moi un meilleur concepteur d’UX: des objectifs d’apprentissage.
Les objectifs d'apprentissage sont simplement ce que vous voulez que l'étudiant apprenne à la fin de la formation. S'il y a un test, les questions du test doivent être basées sur ces objectifs - sinon, quel est le but du test?
La même approche est utile pour déterminer si un test a réussi ou échoué à un test d'utilisabilité. Rappelez-vous simplement que c'est le design qui est testé, pas les participants.
Que doit faire ou dire le participant au test pour vous assurer que le design a réussi? Ont-ils besoin de suivre trois heures de temps pour un projet particulier? Générer une facture à un client en fonction de ce temps suivi? Envoyer la facture? C'est vos critères de test.
Bien sûr, les tests d'utilisabilité consistent à observer comment les utilisateurs accomplissent les tâches, mais que ferez-vous pour les faire, exactement? La beauté de ces critères est qu'ils vous éloignent des objectifs de test vagues, tels que «comprendre comment fonctionne le suivi du temps». Comment saurez-vous qu'ils l'ont compris? Vous les faites décrire. Et une fois qu'ils l'ont décrit avec précision, vous pouvez dire que cet aspect du design a été un succès.
Les critères de réussite vous aident à deux reprises: ils précisent si votre conception est vraiment réussie et facilitent le partage de ces résultats.
Les verbes sont magiques
Le livre qui m'a appris sur les objectifs d'apprentissage, George Piskurich's Conception pédagogique rapide , offre une liste pratique de comportements pour commencer vos critères de réussite.
Par exemple, les objectifs de compréhension pourraient être "décrire" ou "démontrer". Encore une fois, "comprendre" n'est pas bon - vous en avez besoin pour dire (c'est-à- dire décrire) ou faire (c'est-à-dire démontrer) quelque chose qui vous prouve qu'ils ont compris.
Et puis, à un degré plus élevé de difficulté, un participant pourrait «expliquer» ou «organiser»; à un niveau supérieur encore, ils pourraient "créer" ou "évaluer".
Quel que soit le verbe que vous choisissez pour commencer vos critères de réussite, le point est que vous pouvez observer si un utilisateur a réellement dit ou fait ce qui constitue le succès de la tâche.
"A la fin de cette session ..."
Ainsi, lorsque vous planifiez votre prochain test de convivialité et que vous travaillez sur des tâches, commencez par demander: "Que devrait faire un utilisateur avec (ou dire) cette conception?"
Ensuite, vous pourriez écrire quelque chose comme ceci:
À la fin de la session, le participant devrait être capable de:
- suivre trois heures de temps pour un projet particulier;
- générer une facture à un client en fonction de ce temps suivi;
- décrire la différence entre le temps de suivi et le temps de connexion.
Vous disposez maintenant de trois critères de réussite et, sur la base de ceux-ci, vous avez également une idée assez claire des tâches que vous devrez confier aux participants.
Une mise en garde: les critères de réussite ne sont pas tout à fait les mêmes que les tâches. Les tâches ont plus de contexte; elles sont écrites pour être lues au participant et peuvent inclure un contexte sur la tâche, en particulier si vous les dirigez pour trouver quelque chose dans votre prototype. Par exemple:
Critères de réussite: Générer une facture à un client en fonction de ce temps suivi
Tâche: "Maintenant que vous avez suivi trois heures sur le projet Atlas, montrez-moi comment vous factureriez les produits Acme pour votre temps."
Assez similaire, évidemment, mais les critères de réussite sont pour vous et votre équipe; la tâche est pour le participant dans le contexte de la session d'utilisabilité.
Et vous remarquerez que l'un des critères de réussite ci-dessus concerne la description de quelque chose, plutôt que d'effectuer une tâche. Cela pourrait être une question de suivi à une tâche. Celles-ci sont utiles pour vérifier si le modèle mental de votre conception est clair pour les utilisateurs. J'ai vu des utilisateurs trouver leur chemin dans une tâche, puis me décrire un modèle mental de l'application qui est en contradiction avec la façon dont il a été conçu. C'est un succès de tâche pour un participant, mais surtout, il y a un problème sous-jacent à la correspondance du modèle mental de ce participant.
Commencez donc avec vos critères de réussite, puis écrivez vos tâches et vos questions de suivi en fonction de vos critères.
Les parties prenantes aiment les critères de réussite
Les parties prenantes ne se soucient pas nécessairement de votre processus, mais elles se soucient vraiment des résultats. Et si votre présentation des résultats est vague, ils seront à juste titre irrités.
"L'utilisateur a réussi à suivre quelques heures, mais nous ne savions pas si elle avait compris que le suivi n'était pas la même chose que l'enregistrement contre un client ..." Pourquoi ne pas en être sûr? N'est-ce pas à vous de comprendre cela? Vous perdez votre temps, et ne leur donnez pas de directives claires sur la façon de résoudre les problèmes liés à l’explosion, ce qui est aussi votre travail, non?
Les critères de réussite vous aident à deux reprises: ils précisent si votre conception est vraiment réussie et facilitent le partage de ces résultats.
Nous avons réussi à suivre les critères de réussite dans un tableau simple et à coder les résultats par couleur. Ainsi:
Nous préparons un tableau de résultats avec code couleur (vert = succès, rouge = échec) sur notre wiki. Dans la rangée supérieure, nous listons les participants; dans la colonne de gauche, nous listons nos critères de réussite. C'est moche, mais rapide et utile.
Ceci est facile à numériser, montre clairement où sont les problèmes, et fonde les résultats sur les expériences des participants réels. Nous listons également un résumé des résultats et une liste des problèmes d’utilisation et des recommandations juste en dessous. Nous allons nous concentrer sur ces problèmes et les itérer jusqu’à ce que nous pensions qu’ils sont résolus. Votre processus peut être un peu différent - par exemple, vous êtes un consultant qui remet un rapport à un client, par exemple - mais les avantages sont les mêmes.