Pourquoi les tests d'hypothèses ne sont pas le bon point de départ
Dans mon poste récent sur la valeur de la recherche exploratoire en termes de gain de temps et d'argent, j'ai abordé la question de l'utilisation de la recherche exploratoire dans le domaine de la santé. tests d'utilisabilité laisser les équipes concevoir. J'ai pensé qu'il valait la peine d'approfondir ce point en ce qui concerne la manière dont il se manifeste dans les sessions proprement dites, mais aussi dans la préparation. Le mot "hypothèse" entre généralement dans la conversation assez rapidement.
Si vous n'êtes pas familier avec les tests de convivialité, il s'agit de demander à des participants recrutés parmi votre population cible d'effectuer des tâches avec votre interface, similaires à celles qu'ils effectueraient dans le monde réel. Grâce à l'observation et à la modération, nous identifions les problèmes et formulons des recommandations d'amélioration. Tout cela est très simple.
L'interface que nous testons peut être un site web réel, bien que ce soit généralement à des fins d'optimisation, ou, plus couramment, un prototype en cours de développement. Les prototypes sont très faciles à construire aujourd'hui par rapport aux schémas filaires qui étaient courants en 2000. Avec certains des outils disponibles et une équipe de concepteurs talentueux, il est possible de développer un prototype qui ressemble et se comporte comme le vrai site.
C'est dans l'origine du prototype que l'hypothèse entre en jeu. Parce qu'ils sont relativement faciles à construire, je vois arriver de plus en plus de prototypes pour des tests d'utilisabilité qui sont entièrement construits à partir des activités de brainstorming d'une équipe. Voici un bref résumé de ce processus :
- L'idée de la proposition est générée
- L'équipe réfléchit à une hypothèse sur la façon dont cette idée devrait être transformée en un modèle.
- Le prototype est construit
- Des tests de convivialité sont effectués
C'est en gros la façon dont équipes agiles L'approche agile consiste à développer un MVP (produit minimum viable), à le tester, à échouer rapidement et à recommencer. Mais si vous n'êtes pas organisé de manière agile, cette approche est défectueuse. Certes, les clients sont impliqués, mais trop tard dans le processus.
L'hypothèse doit être étudiée
Les prototypes doivent être testés. Les hypothèses doivent faire l'objet de recherches et non de tests. Si vous avez besoin d'être convaincu, regardez les Cadre double diamant des conseils en design. La première étape est celle de la "découverte", qu'ils définissent comme suit :
Le premier diamant aide les gens à comprendre, plutôt que de simplement supposer, la nature du problème. Il s'agit de parler et de passer du temps avec les personnes concernées par les problèmes.
On pourrait arguer que tester des hypothèses est une bonne chose car l'équipe peut faire preuve d'ouverture d'esprit quant au résultat et revenir en arrière si nécessaire. Mais même si c'est le cas, cela ne constitue-t-il pas une perte de temps et d'argent ?
J'ai également entendu des personnes dire qu'elles avaient besoin d'un prototype pour montrer au client ce que sont leurs idées. C'est passer à côté de l'objectif de la recherche exploratoire, qui est de définir l'espace de problèmes auquel les idées s'adressent. La définition de l'expérience vient plus tard.
Si vous voulez tirer le meilleur parti de votre budget et de votre temps, et créer des produits numériques différenciés qui offrent une excellente expérience à l'utilisateur, vous devez impliquer vos clients dès le début et tout au long du processus. Les impliquer tardivement pour tester votre hypothèse aboutira généralement à un produit/service médiocre ou à un processus plus long et plus coûteux.
Si vous souhaitez en savoir plus sur la recherche de vos idées, contactez-nous à l'adresse suivante +44(0)800 0246247 ou nous envoyer un courriel à l'adresse suivante hello@ux247.com.
