Lors de l'évaluation de prototypes, comment puis-je m'assurer que l'utilisateur évalue des aspects spécifiques au lieu du produit / design dans son ensemble?
J'ai entendu parler de ce problème par différentes personnes et sources écrites. Lors de la construction de prototypes, on souhaiterait une évaluation des utilisateurs. Un type d'évaluation consiste, pour chaque fonctionnalité, à savoir si elle est réellement nécessaire ou appréciée et comment elle doit être construite.
Ce que j'entends, c'est que si un prototype complet, ou plutôt complet, est présenté, l'utilisateur commentera les choses non pertinentes et ne sera pas en mesure de donner des commentaires utiles sur les fonctionnalités. Pas même lorsqu'on lui a demandé de se concentrer sur des aspects spécifiques. Par exemple, l'utilisateur commentera l'esthétique graphique, peut-être même commentera les couleurs et le visage de la police.
Donc, ce que j'entends être recommandé, c'est qu'en quelque sorte je devrais présenter des prototypes qui se concentrent uniquement sur les aspects que je veux évaluer. S'il y a cinq fonctionnalités que j'ai besoin de tester, je pourrais faire cinq groupes de prototypes. Le premier groupe pourrait se concentrer sur la présentation des données historiques, fx un tracé avec quelques boutons pour zoomer et glisser. Je pourrais alors en faire trois versions différentes.
Je vois ensuite deux moyens de base pour que l'utilisateur se concentre sur cette fonctionnalité lors de son évaluation.
- Griser tous les autres aspects de l'interface graphique.
- N'affiche simplement pas le reste de l'interface graphique. Mais il doit également y avoir d'autres moyens.
Quelle est la meilleure façon d'y parvenir?
Les performances des utilisateurs et non les opinions des utilisateurs
La solution est de faire un test de convivialité approprié. Ne montrez pas aux utilisateurs un prototype et demandez-leur ce qu’ils en pensent. Cela leur demande d'imaginer ce que ce serait d'utiliser le produit, ce qui donne des données peu fiables. Au lieu de cela, demandez-leur d'utiliser le prototype pour qu'ils (et vous par vos mesures) sachent ce que c'est que d'utiliser le produit. Pour que les utilisateurs et les données se concentrent sur une fonctionnalité spécifique, demandez aux utilisateurs d'utiliser le prototype pour une tâche que vous sélectionnez et qui devrait utiliser cette fonctionnalité.
La fonctionnalité est-elle nécessaire ou appréciée?
S'ils n'utilisent pas cette fonctionnalité, les utilisateurs estiment peut-être que ce n'est pas nécessaire. Ou peut-être qu'ils ne savaient pas que c'était là, ce qui est un problème distinct à résoudre. Interroger les utilisateurs après le test permettra de déterminer de quoi il s'agit. Si les utilisateurs n'utilisent pas la fonctionnalité, signalez-le-leur et demandez-leur de refaire la tâche avec la fonctionnalité. Une fois qu'ils ont terminé, réinterrogez-les en leur demandant de comparer l'exécution de la tâche avec et sans la fonctionnalité. Combinez ces données subjectives avec des données objectives sur la facilité et la réussite de la tâche (en tenant compte du fait que toute tâche est plus facile la deuxième fois). Gardez à l'esprit que les utilisateurs ne peuvent pas facilement séparer la conception de l'utilité inhérente. Certains utilisateurs peuvent ignorer une fonctionnalité qu'ils ont essayée non pas parce que c'est une mauvaise idée, mais parce qu'elle était trop difficile à utiliser comme prévu.
Comment la fonctionnalité devrait-elle être conçue?
Dans tous les cas, une fois que vous avez des utilisateurs qui utilisent la fonctionnalité, vous pouvez maintenant observer dans quelle mesure l'interface utilisateur fonctionne pour les utilisateurs et donc comment elle doit être construite. Vous voyez ce qui est en fait et ce n'est pas un problème, plutôt qu'hypothétiquement ce que pense l'utilisateur serait et ne serait pas un problème. Un entretien par la suite vous aidera à cerner les causes possibles de tout problème.
tiliser un prototype à fidélité limitée?
Cela dit, un "prototype" n'est pas nécessairement une maquette complète du produit. Vous ne pouvez développer qu'un aspect du produit que vous souhaitez tester. Par exemple, si vous voulez simplement comparer la conception d'un menu circulaire à un menu contextuel ordinaire, il vous suffit de simuler les deux conceptions de menu. Il n'est même pas nécessaire qu'il s'agisse d'un ensemble réel d'éléments de menu pour le produit que vous concevez en fin de compte. Cependant, le but de faire de telles maquettes de faible fidélité est plus de vous faire économiser du travail (et de l'argent) en ne développant pas beaucoup de choses qui peuvent (devront) être modifiées en fonction des résultats des tests d'utilisabilité. Ce n'est pas nécessairement pour focaliser l'utilisateur. Si vous avez déjà un prototype haute fidélité, utilisez-le.
Test A/B. Créez deux prototypes dont l'un a les caractéristiques que vous cherchez à tester, l'autre non. Si le scénario est le même et que l'utilisateur est en mesure d'effectuer les tâches pour lesquelles ce produit est conçu, par défaut, ces fonctionnalités sont inutiles. Vous pouvez également créer des prototypes qui se concentrent uniquement sur les fonctionnalités à tester et non sur l'ensemble du flux utilisateur.