Calcul du temps de réponse des tâches avec des prototypes papier?
Je réalise des tests sur prototype papier et parviens à collecter des données sur les taux d'achèvement et les scores de satisfaction. Cependant, j'ai du mal à calculer les temps de tâche. Existe-t-il une autre mesure en dehors du temps de réponse que je peux éventuellement utiliser pour évaluer les prototypes de papier?
J'aime les réponses précédentes, mais en plus, je voudrais souligner que si les utilisateurs n'étaient pas conscients que le temps était un problème, vous aurez tellement de variabilité dans vos données qu'à moins que l'effet ne soit énorme, il ne sera pas significatif.
À l'avenir, vous pouvez utiliser des systèmes tels que Verify (verify.com) vous permettant de quantifier les taux d'achèvement et les temps de tâche sur des maquettes d'écran individuelles.
En ce qui concerne les quantifications supplémentaires, je ferais certainement une évaluation subjective, ce qui signifie que cela est important pour l'utilisateur. Vous pouvez le faire en termes absolus ou comparés à ce qu'ils utiliseraient autrement. Vous commencez par définir quels sont les attributs importants de l'expérience (vitesse, efficacité, confiance, plaisir, etc.) et demandez aux gens d'évaluer l'expérience pour ces 3-4 principaux attributs.
On dirait que vous essayez de recueillir des données quantitatives à partir de ce qui est essentiellement une méthode de recherche qualitative. Je n'ai jamais collecté d'informations sur la convivialité à partir de tests de convivialité. Je m'attendrais à ce que les prototypes low-fi fournissent des données quantitatives encore moins précises qu'un système fini.
Mais vous pouvez découvrir des données qualitatives très utiles avec des prototypes low-fi. Surtout, vous pouvez découvrir les zones problématiques et utiliser vos observations pour améliorer vos premières conceptions. Et, comme il s'agit d'un prototype papier, qui vous permet de créer facilement plusieurs versions, vous pouvez les tester les unes contre les autres.
Si vous êtes vraiment intéressé par les délais d'exécution, essayez un modèle KLM-GOMS , qui fournit exactement cela, avec une précision surprenante.
Je demanderais aux répondants d'estimer la facilité d'achèvement de la tâche (comme 1-très difficile -> 7-très facile) ou leur demander de cartographier à quel point ils penseraient qu'il serait facile de le faire dans une application réelle, si cela fait partie de ton but.
Peut-être que comme vous, j'ai trouvé trop de distracteurs potentiels avec des prototypes en papier pour rendre le chronomètre utile.
Vous pourriez compter:
- Nombre de fois où l'utilisateur doit demander des éclaircissements, groupé par tâche
- Nombre de fois où l'utilisateur doit demander des éclaircissements, groupé par élément
- Nombre de fois où l'utilisateur "appuie" ou interagit avec un élément, seulement pour se rendre compte qu'il ne fait pas ce qui était attendu
- Comptez le nombre de fois où les utilisateurs accomplissent la tâche X lors de la première tentative .
Demander aux utilisateurs leurs commentaires sur la dureté de quelque chose peut être utile, mais les utilisateurs ne sont pas particulièrement précis dans quoi ils disent, c'est pourquoi les données collectées en les observant peuvent être plus utiles. [1]
Sources:
[1] http://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/