Tests utilisateurs : quelle est la bonne méthode??

Pourtant, nombre d’entreprises et d’auto-entrepreneurs sous-estiment encore le pouvoir de tester leurs produits dans cette course effrénée. Je vous propose de nous intéresser à la partie immergée de la conception : les tests utilisateurs. Dans un monde où tout s’accélère, comment pouvons-nous tester au mieux et le plus rapidement possible mon interface, sans pour autant biaiser mon étude ? 

Allons à l’essentiel, testons uniquement ce que l’on souhaite tester?  

Rappelez-vous de la théorie de Herbert Simon : l’Homme est constamment « asséné » de signaux qui viennent gêner sa capacité à traiter et à comprendre un message initial. Comme tout support de communication, l’interface Homme-Machine n’échappe pas à cette règle. Aussi, les couleurs, les images, les typographies et autres éléments interactifs peuvent distraire ou compromettre la lisibilité de l’interface et donc sa bonne compréhension. Dans le cas d’un test visant à évaluer l’architecture d’information, on constaterait que l’arborescence n’est pas perçue de la même manière. L’arborescence peut être rédigée en police capitale blanche avec serif taille 28 sur fond noir dans un méga menu déroulant ; ou encore en police minuscule de couleur gris foncé sans serif taille 14 dans un burger menu progressif sur fond blanc. Pour s’abstreindre de ce biais graphique, les tests d’arborescence sont ainsi réalisés via une interface minimaliste. On constate que 80% des enseignements sont tirés à partir de 20 % des éléments d’interface conçus (Loi de Pareto). C’est pourquoi la majorité des tests utilisateurs peuvent être réalisés sur la base de wireframes (écrans interactifs en basse définition). Les wireframes permettent d’exposer la structure de la page, les fonctionnalités et l’enchaînement entre les pages. C’est ainsi que peuvent être évalués la bonne compréhension, les comportements et les parcours utilisateurs sans pour autant avoir besoin de développer un service suffisamment abouti.  

Autre avantage : plus le test est réalisé tôt dans la conception, plus il est facile et économique de corriger, et plus le produit et le service pourra être mis sur le marché et être confronté à la réalité du marché.   

Les usages et les comportements sont différents dans la vraie vie 

La réalité du marché justement, parlons-en ! Tester en chambre c’est bien, mais tester dans le bon contexte c’est mieux. Dans cette seconde approche, si le biais d’un test peut naître du « bruit » existant autour de l’objet d’études, supprimer ce bruit est un biais encore plus important (car en dehors de la réalité).  Prenons l’exemple du test de l’utilisation d’une application mobile d’actualités économiques. Un test en chambre ne révélera pas de problème particulier d’usage ni de compréhension d’un article. L’utilisateur aura pris le temps de naviguer dans l’application, de lire un article, et de partager ce dernier sur les réseaux sociaux, bien assis dans un fauteuil de salle de test. Feu vert pour la mise en production. Toutefois, le test utilisateur aura-t-il vu les difficultés d’usage en conditions réelles telles que la consultation de l’application dans une rame de métro en mouvement, debout en équilibre, une main sur la barre du métro, et l’autre à supporter le poids d’un sac à main ? Les zones d’interactions (boutons) et la taille du texte auront-t-elles été pensées en conséquence ? Probablement pas.  De même, l’expérience utilisateur (UX) ne se résume pas à l’utilisabilité d’une interface. On doit être à même de tester son utilité et son agréabilité pour s’assurer que le produit rencontrera un certain succès une fois mis sur le marché.  

Les éléments graphiques ainsi que le contenu réel doivent ainsi faire partie intégrante de l’interface au moment du test. Les tests sont ainsi réalisés au pire sur des maquettes graphiques dynamisées ou un POOC (Proof of concept), au mieux sur un produit abouti pour tirer parti des enseignements du Lean Startup et du Test & Learn. Les enseignements seront ainsi réimpactés au gré de l’amélioration continue du produit.   

Finalement, tout dépend de ce que l’on souhaite tester? 

En réalité, les deux approches disent vraies ! L’important est de se questionner sur le pourquoi du test et l’objectif de ce que l’on souhaite tester. L’enjeu est-il fonctionnel (amélioration d’un service existant) ? Ou l’objectif est-il de faire connaître un nouveau produit (la partie graphique et la compréhension du fond seront alors très importants) ?  

Le protocole, en amont du test prend alors tout son sens, et orientera sur le fait que l’on s’arrête sur une arborescence ou des wireframes pour tester, ou que l’on pousse la conception jusqu’à la dynamisation de maquettes graphiques qui donneront l’impression d’être sur l’interface finale.  Enfin, afin de répondre à l’enjeu de conduire des tests en contexte réel, le protocole de test permettra de définir l’orientation vers du Rapid ou vers du Guerrilla Testing, à mi-chemin entre les deux approches. On pourra ainsi évaluer l’interface sur des points précis, en allant sonder «?à la volée?» des utilisateurs potentiels dans la rue (en situation de mobilité), en récoltant à chaud leur comportements et usages.