Vous devez comprendre la nature et les limites des tests utilisateurs et des tests en général avant de pouvoir les utiliser

Le test utilisateur, comme tous les tests suivent la même règle : pour pouvoir les utiliser, vous devez connaître leur nature, leur champ d’application et leurs limites. Qu’il s’agisse d’un test utilisateur, de tests d’aviation, de tests de poids ou bien de tests pharmaceutiques, vous ne pouvez pas les utiliser si vous ne connaissez pas leur cadre de référence.

Prenons un exemple : un médecin, lorsqu’il fait passer des radios comprend le fonctionnement de la radiologie mais aussi ses limites : il sait ce que sont les rayons X, il sait comment ils fonctionnent, il sait au moins de façon générale comment marche l’appareil de radiographie, il sait quelles parties du corps laisseront passer les ondes et quelles parties feront écran.

Le médecin sait également quels sont les risques si l’on expose le patient trop longuement aux rayons. Et au-delà de ça, il sait ce qu’il pourra attendre de ses clichés : ce qu’il verra bien sur les radios et ce qu’il ne pourra pas déceler convenablement et qui l’obligera à passer la main à l’IRM, par exemple, pour diagnostiquer le patient de façon plus précise.

Mais vous ? Savez-vous ce que c’est vraiment qu’un test utilisateur et quelles en sont les limites ?

Avez-vous bien compris ce qu’était en réalité le test utilisateur au-delà des clichés parfois vendus sur le web ?

Un grand nombre de blogs que j’ai pu parcourir, précisent que les tests utilisateurs auraient été « inventés » par Nielsen ou bien Norman.

C’est évidemment faux.

Nielsen précise juste qu’il faut en général 6 utilisateurs par tests, au minimum, pour commencer de diagnostiquer les plus gros problèmes d’ergonomie d’un produit.

Et Norman, qui n’a rien à voir dans tout cela, est simplement le promoteur dans le domaine du design d’une notion qui s’appelle l’affordance et qu’il a plus ou moins hérité d’un grand Psychologue de ses amis, spécialiste de la psychologie de la vision, James J. Gibson.

De même, le test utilisateur n’est pas l’apanage de la méthode agile ou bien du Design Thinking. Même si les tenants de ces écoles ont tendance à promouvoir les tests utilisateurs comme étant une partie structurelle de leur méthode, et c’est bien, les tests n’ont évidemment pas attendu le début des années 2000 pour faire leur apparition.

Lorsqu’on retrace l’histoire industrielle et, plus avant, l’histoire de la technique, le test utilisateur a toujours plus ou moins été monnaie courante.

Les anciens faisaient déjà des tests dans l’antiquité et les artisans et les bâtisseurs ont passé leur temps à en faire de l’antiquité jusqu’au XIXème siècle. Comment croyez-vous que Sainte-Sophie, par exemple, ait été construite si ce n’est par tests et par essais-erreurs (en plus évidemment des modèles mathématiques hérités de la Grèce et de l’ancienne Égypte).

Mais en Europe, ce sont un Psychologue et un médecin français qui vont donner à la notion de test ses lettres de noblesse.

Ombredane et Faverge, théoriciens français de l’ergonomie entre les années 30 et 60 définissent le test utilisateur en expliquant qu’il y a toujours un écart entre ce que le concepteur avait imaginé et ce que l’utilisateur souhaite faire.

Et Ombredane et Faverge de rajouter que, sans se confronter à la réalité (avec un test), le concepteur passe généralement à coté de sa cible et à coté de ce que les deux auteurs appellent « l’activité réelle » des usagers, c’est à dire « ce qui émerge » lorsque l’utilisateur commence de prendre en main son outil.

Un test utilisateur est donc un test d’écart entre ce que le concepteur avait prévu et ce que l’utilisateur souhaite faire. Il sert à diagnostiquer un écart, c’est à dire ce que vous appelez aujourd’hui un point de douleur.

Le test utilisateur est donc un test d’écart qui permet à celui ou celle qui l’utilise de corriger un fossé de vision et de perception entre le modèle mental du concepteur et le modèle mental de l’utilisateur.

Mais le test utilisateur ne peut pas être le seul test que vous utilisez pour comprendre vos usagers

En effet, les tests utilisateurs ont été conçus à l’origine pour tester et corriger un produit existant.

Ils permettent de comprendre ce qui ne va pas dans votre produit et en quoi il est en porte-à-faux avec ce que l’utilisateur attendait.

Mais savoir ce qui n’allait pas dans votre produit n’est qu’une vision partielle.

Cela ne vous apprend que ce qui n’allait pas avec votre produit. Souvent, cela ne permet pas d’avoir une vision complète de ce que l’utilisateur attendait. D’autre. De façon plus globale.

Là où les tenants de la méthode agile, des sprints design et du design thinking ont raison, c’est qu’il vaut mieux tester très rapidement son produit, au démarrage du projet, plutôt que de passer des mois à le rêver sur le papier de la planche à dessin.

Plus on teste rapidement son prototype, plus on se rend compte vite de ce que les usagers font sur le terrain et plus on élague les idées imbéciles ou les fonctions peu nécessaires.

Mais là où les tenants de la méthode agile on tort, c’est de croire que le test utilisateur permet de comprendre si votre produit est le bon. Si son positionnement fondamental est le bon.

Or, pas toujours. Comme nous l’expliquions dans un article précédent, le test utilisateur est une technique systématique. C’est de l’essai-erreur : il vous aide à savoir ce qui ne marche pas mais il ne vous aide pas forcément à comprendre pourquoi ça marche.

Pour faire simple, le test utilisateur vous met un peu dans la situation du pilote d’avion qui, pour arrêter l’avarie d’un moteur, a appuyé sur tous les boutons du tableau de bord et qui, quand l’incendie s’éteint, se dit que ce devait être la clim la responsable puisque c’est le dernier bouton sur lequel il a appuyé et que l’incendie s’est arrêté.

Mais sans jamais vraiment connaître le fin mot de l’histoire. Était-ce vraiment la clim la responsable ? Où est-ce une coïncidence ?

Peut-être l’avarie s’est-elle arrêtée juste au moment où il désactivait la clim mais pour une autre raison.

Peut-être l’effet de cause-conséquence qu’il a posé est faux.

Tester ne signifie pas toujours avoir la réponse.

C’est pour cela que chez Fast & Fresh, nous utilisons toute une palette de tests complémentaires aux tests utilisateurs et qui permettent de saisir bien mieux les besoins des usagers afin de l’aider à avancer dans les tâches qu’ils souhaitent accomplir.