Dans un test d'utilisabilité utilisant des maquettes papier par exemple dans un système de blog où les utilisateurs peuvent insérer des articles, modifier des articles, insérer des administrateurs, modifier des administrateurs, etc. Si nous avons des cas d'utilisation pour les tests d'utilisabilité comme:
Nous devons écrire un contexte pour la tâche et donner ce contexte de texte à l'utilisateur avant la tâche, mais nous devons également écrire un contexte écrire les informations que l'utilisateur doit écrire dans les champs de saisie? Par exemple, dans une tâche où l'utilisateur doit créer un message, nous devons écrire, dire à l'utilisateur le titre qu'il doit taper dans le champ de titre, la catégorie qu'il doit sélectionner et toutes les autres informations nécessaires dont il a besoin pour présenter? Parce que si chaque utilisateur qui fait le test écrit des choses différentes dans les champs, le temps sera différent. Ou n'est-il pas nécessaire que l'utilisateur saisisse des informations dans le test d'utilisation?
L'objectif de ce test d'utilisabilité papier est de vérifier si l'utilisateur a atteint l'objectif proposé de la tâche, également le nombre d'actions qu'il a dû prendre pour atteindre l'objectif de la tâche et le temps qu'il a pris pour l'accomplir.
Cela dépend de votre test.
Dans ce cas, ne fournissez pas d'informations sur ce que les utilisateurs doivent faire à chaque point donné. Vous voulez savoir si les utilisateurs savent ce qu'ils doivent faire et s'ils peuvent terminer votre tâche. Vous ne pouvez pas fournir ces informations "dans le monde réel", alors ne le faites pas pendant votre test.
Toutefois...
Dans certains cas, vous devrez peut-être le faire. Par exemple, si vous avez déjà testé et que vous souhaitez tester à nouveau un certain aspect de votre produit, vous pouvez spécifier ce que vous voulez que votre utilisateur fasse.
Les tests d'utilisabilité doivent être totalement impartiaux et ne contenir aucun Questions directrices car cela ne sera pas un véritable exemple de la façon dont vos utilisateurs agiront dans le monde réel.
Par exemple, nous voulions tester une nouvelle fonctionnalité qui n'était accessible que via un nouveau bouton. Les utilisateurs que nous avons montrés ne voyaient même pas le bouton, ils ne sont donc jamais arrivés à notre nouvelle fonctionnalité.
La moitié d'entre nous a dit que c'était un test nul car la fonctionnalité n'a jamais été testée, mais l'autre moitié a déclaré que cela prouve maintenant que pour que la fonctionnalité soit même utilisée, nous devons améliorer le bouton qui fait techniquement partie de la nouvelle fonctionnalité.
Si l'utilisateur ne parvient pas à effectuer une tâche principale dans votre test, c'est quelque chose que vous pouvez supprimer, corriger puis retester.