Quelles sont les meilleures pratiques lors des tests pour comparer différentes idées de conception?
Il y a une caractéristique particulière de notre application (B2B) qui semble causer beaucoup de confusion. (Cela implique des listes d'URL, dont certaines peuvent être assez longues, et donner des statuts différents à différents. Sur le back-end, il y a un tas de mathématiques booléennes impliquées, mais évidemment, nous essayons de cacher cela aux utilisateurs. )
Une partie de la confusion est que le domaine est complexe. Nous avons proposé quatre modèles pour essayer de clarifier les choses, et je veux les tester. Des conseils sur la façon de gérer les tests? Quelques défis:
- nous n'avons pas suffisamment d'utilisateurs pour effectuer des tests A/B automatisés de toute nature
- c'est un modèle conceptuel quelque peu complexe, qui nécessite probablement au moins une petite expertise de domaine pour comprendre
- malgré ce qui précède, nos utilisateurs ne sont pas nécessairement très techniques
Il est possible de faire un test contrôlé (laboratoire) en utilisant une conception intra-sujets. Pour cela, chaque participant serait exposé à chaque condition (conception). Il peut y avoir des effets d'ordre (c.-à-d. Qu'ils apprennent au fur et à mesure) afin de contrebalancer l'ordre dans lequel les participants travaillent à travers chaque conception (donc le participant 1 obtient les conceptions 1,2,3,4; le participant 2 obtient 2,3,4,1 ; le participant 3 obtient le dessin 3,4,1,2; et ainsi de suite). Cela permet d'éviter les effets d'ordre.
Le plus difficile est de déterminer ce que vous voulez mesurer. Cela dépend des objectifs que le logiciel est censé atteindre.
Je suggère d'utiliser quelque chose comme Silverback (je ne sais pas si vous avez des Mac ou non, mais ce n'est qu'un exemple d'application qui fait ce à quoi je pense) pour définir réellement ceux qui veulent -être les utilisateurs finaux des tâches spécifiques dans les différentes conceptions et voir comment ils fonctionnent.
Cela vous permettra de voir s'ils peuvent déterminer les étapes requises dans leur domaine; vous pouvez voir où se trouvent les problèmes et peut-être ajuster vos conceptions en fonction de cela. De plus, cela vous donnera plus que de demander à l'utilisateur de faire un rapport. Ils peuvent ne pas rapporter avec précision leurs problèmes ou être en mesure de les articuler dans le même détail que vous pouvez obtenir en les regardant en action.
Je n'ai fait que des tests de guérilla superficiels dans le passé, mais c'est une idée simple et semble bien fonctionner lorsque vous avez des ressources limitées.