25.10.2014 Mis à jour pour intégrer les questions dans les commentaires*
Tous les mois, on me demande : “J’aimerais faire un test utilisateur mais je ne peux pas !”.
Recement, 2 événements m’ont convaincu de t’écrire cet article :
- Une amie m’a demandé de l’aide pour convaincre un client particulièrement récalcitrant de réaliser des tests d’ergonomie.
- Jérémie m’a envoyé cet article You are not a designer (… if you don’t do usability tests(… if you don’t do usability tests.
Du coup, je te livre içi ma démarche pour convaincre n’importe qui de l’importance des tests d’ergonomie.
Cette démarche se déroule en 3 phases :
- Comment je réalise un test
- Qu’est ce que le client en retire
- Et je réponds à toutes les questions suivantes.
Rien de bien compliqué: Allez, c’est parti.
C’est quoi un test utilisateur ?
Je commence toujours par expliquer ce qu’est un test utilisateur, et en quoi il se distingue d’un test d’acceptance, test unitaire, focus group.
Un test utilisateur se résume assez simplement :
- On prends 5 utilisateurs potentiels de la plateforme, du service, du logiciel ou de l’app que l’on réalise.
- On leur fait utiliser l’application (ou les maquettes/prototypes qui montrent l’application)
- On leur demande d’effectuer des tâches réelles
- et on regarde (juste) comment ils s’en servent et on apprends de leur erreurs.
Les tests d’ergonomie, ce n’est pas demander à une personne s’il aime ou pas le produit, mais plutôt si une personne peut s’en servir ou non.
D’ailleurs, je complète souvent en précisant que si tu pense avoir déjà la réponse à cette question, je ne pense pas que tu sais de quoi tu parles.
Quel bénéfice pour le client
Ensuite j’explique ce qu’apporte les tests utilisateurs pour la personne que j’essaye de convaincre. J’essaye de clarifier les points suivantes : Qu’est ce que JE vais retirer des tests utilisateurs. et quel est le bénifice pour le client.
- Grâce au test on découvre si ce qu’on a déjà conçu fait sens ou pas. On valide toutes les hypothèses que l’on a pris lors de la conception. On va découvrir ce qui va ou pas.
- On a une vision sur le model mental des utilisateurs (comment ils parlent, comment ils visualisent les objets que l’on mets en face d’eux), ce qui permettra de concevoir mieux les fonctionnalités suivantes.
- On limite au mieux les risques que le produit qui sort ne convient pas!
- Si le test est bon, on pourra montrer par des chiffres que le produit est utilisable pour la population cible et qu’il est “bon”. Ca devrait rassurer toute la hierarchie avant de le sortir !
Oui mais …
A ce moment là de mon exposé, mon interlocuteur utilise toujours un ou plusieurs arguments décourageant. Voici celles que j’entends le plus souvent. Et la réponse que je trouve la plus appropriée.
L’application n’est pas complete … ce n’est qu’un prototype / des maquettes
- Ca donnera des idées où l’on doit mettre les efforts pour la suite.
- Ca permet de tester avant de développer.
- On est assez grand pour voir ce qui dépends de la maquette ou du concept que l’on propose.
On sait déjà ce que utilisateurs veulent
- on ne cherchent pas à savoir ce que les gens veulent, mais plutôt s’ils arrivent à se servir de ce qu’on leur offre.
- Même si on cherchait à savoir ce qu’ils veulent, leur demander est rarement la bonne option (utilisez les arguments de Ford ou de Steve jobs)
Les utilisateurs n’ont pas eu de formation - c’est un produit spécialisé
- Tout a fait. Ceci étant dit, on peut distinguer si le problème est dû à une méconnaissance du produit ou à des problèmes d’utilisation.
- Et voir ce qu’ils essayent d’abords nous donne une idée de ce qu’il pense.
On veut tester avec plus d’utilisateurs, 5 c’est pas suffisant
Toutes les études montrent que tester avec 5 utilisateurs va révéler 80% des problèmes de l’interface. Ca nous prendra 1journée et on aura suffisamment à manger.
Oui, mais on n’a pas assez de temps
Voyons, ca prends 4 jours à tout casser pour faire un test. Largement le temps. Et même, si vous participez avec moi aux tests, on peut descendre à 2 jours.
Et on n’auras jamais les moyens pour intégrer les retours.
C’est compliqué. la grande question c’est : et c’est que vous voulez une application qui a plein de features dont personne ne veut ni ne peut se servir, or un produit que les gens comprenent et peuvent utiliser.
Mais chaque personne est différente.
- Oui et non. Même si chaque personne a une éducation et une culture différente, chaque personne a des doigts qui font une certaine taille, et une mémoire grosso-modo équivalente.
- Pour une application à destination des entreprises, les gens ont souvent un vocabulaire commun et une façon de penser similaire. Arriver à concevoir sur ce qui est commun est tout l’enjeux.
Mais vous êtes un expert, vous devriez savoir ce qui va être utilisable ou non.
- L’ensemble de mon design est construit sur des hypotheses, sur ce qui sont les utilisateurs, ce qu’ils font, ce qu’ils savent. Comme toute hypothese, il faut le valider un moment ou un autre. Vous voulez les valider AVANT que le produit soit en vente, ou après ? A mon avis, le plus tot sera le mieux
- Vous faites bien des tests avant de sortir un produit pour vous assurer qu’il n’y a pas de bug ? Et bien les tests utilisateurs ce sont des tests pour valider qu’il n’y a pas d’écart entre les designs proposés et les attentes des utilisateurs.
Vous avez deja fait un audit expert, ça suffit non ?
- Ce sont des méthodes complémentaires (évidement). Rien ne peut remplacer le contact avec l’humain. Une fois le logiciel mis dans les mains d’un utilisateur, vous verrez des choses qu’aucun audit ne pourrais révéler.
- Si on prends le pendant technique : Il existe des revues de code et des tests unitaires pour valider le code. Mais cela ne remplacera jamais les tests fonctionnels et les démos. Et bien les tests d’ergonomies, c’est la même chose.
La suite ?
Voila, te voila muni de mon arme de choc. Ca ne convaincra peut-être pas forcement tout le monde, mais qu’importe. il faut bien commencer quelque part.
Et s’il est convaincu, et que maintenant tu dois te jeter à l’eau, prends une heure pour lirele fameux livre Rocket Surgery Made Easy par Steve Krug. Ce fabuleux livre te fourni une méthodologie clef en main pour faire tes premiers tests
Et toi, avez-tu essayé une autre approche pour convaincre ? As-tu rencontré d’autres “Oui, mais…” ?
Un grand merci à mes 2 relecteurs, Guillaume Berry et Thomas di Luccio