Cadre de test utilisateur et questions pour les tests comparatifs
Je prévois d'effectuer un certain nombre de tests de réflexion à haute voix basés sur des tâches pour un service que je conçois. Je répéterai le test avec la même configuration régulièrement tout au long de l'année et je recherche un cadre de questions que je peux utiliser pour comparer les résultats.
J'aimerais pouvoir suivre les modifications apportées par rapport à 5 paramètres différents, par ex. Facilité d'utilisation, langage, fonctionnalité, contenu, architecture de l'information après chaque test.
Quelqu'un peut-il proposer un cadre de questions simple et rapide que je peux utiliser pour mesurer ces paramètres après chaque test utilisateur. Je voudrais traduire les résultats en diagrammes radar sur ceux-ci afin de pouvoir communiquer les changements aux parties prenantes.
Un exemple d'un tel diagramme basé sur différents paramètres peut être vu ci-dessous, par ex. 
. Dans ce cas, le diagramme bleu est le résultat du premier test utilisateur, la cible est le résultat souhaité, tandis que le diagramme vert est le deuxième test utilisateur
J'ai déjà regardé SUS mais j'ai l'impression qu'il manque des questions concernant le contenu et la langue et que 10 questions sont beaucoup à poser par rapport à une seul paramètre qui est tilisabilité
Les dix questions de SUS ne sont pas "beaucoup à poser" si vous ne faites passer le questionnaire SUS qu'une seule fois à la fin de toutes les tâches (c'est ainsi que c'est La chose avec le SUS est que bien qu'il y ait 10 questions, elles correspondent toutes au même format de base ("voici une déclaration et une échelle de 5 points fortement- d'accord à fortement en désaccord "), et donc la charge cognitive assez légère. (J'ai récemment mené une série de sessions de tests d'utilisabilité - le SUS a pris peut-être 2 min chacun, comparé à une heure pour toute la session)
Pour Facilité d'utilisation , vous devriez envisager d'utiliser la SEQ - Single Ease Question , et de le demander après chaque tâche.
Jeff Sauro a également quelques suggestions pour mesure de la trouvabilité .
Cependant , vous essayez peut-être de mesurer trop de choses différentes au cours d'une même session de test, et essayez de mesurer certaines choses avec une méthode loin d'être idéale. Par exemple, pour tester l'architecture de l'information vous feriez mieux de faire des tris de cartes ou de faire test d'arbre .