Testez votre maquette avant de développer

L'intégration des utilisateurs dans la conception de produit web est fondamentale. Plus ils sont interrogés tôt, plus leur retour est pris en compte, plus le produit sera performant. Obtenir des feedbacks, les analyser pour proposer de nouvelles choses, c’est ce qu’il y a de meilleur pour construire et améliorer son produit de manière continue.

‍

L'intégration des utilisateurs dans la conception de produit web est fondamentale. Plus ils sont interrogés tôt, plus leur retour est pris en compte, plus le produit sera performant. Obtenir des feedbacks, les analyser pour proposer de nouvelles choses, c’est ce qu’il y a de meilleur pour construire et améliorer son produit de manière continue.

‍

Or, un test utilisateur requiert du temps, une très grande exigence, de l'organisation et beaucoup de rigueur. Il faut le planifier, recruter des testeurs, l'animer et analyser les retours. Pour toutes ces raisons, ils sont souvent repoussés ou effectués tardivement. On se retrouve à pousser fort certaines fonctionnalités avant même d'avoir validé les basiques. Les conséquences peuvent être lourdes en termes de temps, d'énergie et financiers puisque l'on peut se retrouver à jeter des heures de travail par les fenêtres.

‍

Chez Drakkar, nous testons très tôt. Bien avant de poser la moindre ligne de code. Avec un peu de méthode, les bons outils et quelques maquettes, on peut tester rapidement beaucoup d'hypothèses : le userflow, l'ergonomie d'un écran, la disposition de l'information, la qualité du wording, le positionnement d'un call to action, etc.

‍

‍

1. Définir le cadre du test

‍

Quel est l'objectif du test ? Quels sont les résultats attendus ? Comment savoir si le test est concluant ?

Le test doit être rigoureusement structuré au risque de ne pas savoir comment interpréter les résultats, et de se retrouver bloqué au moment de lancer l'itération suivante. Pour éviter de se retrouver dans l'impasse, il convient d'être au clair sur : l'hypothèse à valider, les modalités du test, les métriques ainsi que les critères de validation.

‍

Admettons que nous sommes en 2008, dans la peau de Brian Chesky, en fondateur d'Airbnb.

Hypothèse à valider : Nous souhaitons valider le userflow côté voyageur de l'application. Nous pensons a priori que celui-ci s'articule de la manière suivante :

‍

*Pour le besoin de l'exercice, nous l'avons volontairement simplifié

Modalités du test : Pour vérifier l'hypothèse, nous allons construire le prototype de réservation et vérifier qu'il est possible de réserver un appartement en respectant ce processus. Nous allons demander à 10 personnes de réserver un appartement à 49€ la nuit, à Lisbonne du 16 au 18 novembre.

‍

Métriques :

- Taux de complétion : nombre de testeurs ayant qui a réussi à réserver l'appartement / le nombre total de testeurs ;

- Temps nécessaire pour réaliser cette tâche ;

- Note des utilisateurs sur 5 ;

- % de go back.

‍

Critères de réussite :

- 90% des testeurs parviennent à réserver ;

- Il faut moins de 4 minutes pour accomplir la réservation ;

- Note moyenne des utilisateurs est de 4 ;

- Avec moins de 10 % de go back.

‍

‍

2. Établir un panel de testeurs

‍

Qui pour tester ?

‍

Le panel des testeurs doit être représentatif de la cible visée.

‍

Chaque testeur doit avoir le profil d'un utilisateur potentiel, car ledit prototype est testé par une personne qui n'a pas vocation à utiliser un jour le produit et ses retours ne seront pas pertinents. Sans être de mauvaise foi, cette personne nous amènera dans la mauvaise direction. En effet, il se peut que l'utilisation du prototype nécessite des compétences particulières.

‍

Prenons Google Analytics, mon neveu (12 ans) dirait probablement qu'on n’y comprend rien, que l'interface est mal faite. Pour la satisfaire, le product manager de chez Google serait alors tenté de simplifier le wording et de revoir la disposition des informations. Or ce serait une très mauvaise décision puisque les feedbacks émanent d'une personne qui n'a pas vocation à utiliser un jour le produit puisqu'il est destiné à des professionnels du web.

‍

Il va de soi que les personnes ayant participé à l'élaboration du produit ne peuvent pas non plus faire partie du panel, car leurs feedbacks comportent aussi des biais.

Combien de personnes doit comporter le panel ?

‍

Si vous parlez à trop peu de personnes, vous prenez le risque de ne pas identifier les enjeux importants. De plus, il se peut que vous ayez un retour qui n'est pas vraiment représentatif et vous poussez dans une mauvaise direction. À l'autre bout du spectre, parler à trop de testeurs prend trop de temps et trop d'énergie. Il n'y a pas de règle, mais vous vous apercevrez qu'au bout de 5 à 10 tests, les feedbacks convergent. Autrement dit, plus on fait de tests, moins on a des chances de découvrir de nouveaux retours.

‍

Vous n’avez pas 5 testeurs sous la main ? Dites-vous qu’un testeur vaut toujours mieux que 0 ! 👍

‍

"The most striking truth of the curve is that zero users give zero insights. As soon as you collect data from a single test user, (…) you have already learned almost a third of all there is to know about the usability of the design. 💪 The difference between zero and even a little bit of data is astounding."

Jakob Nielsen, expert UX.

‍

Il est donc stratégique d'opérer 5 à 10 tests et dès que les retours se répètent, arrêtez les tests, analysez et mettez en œuvre des améliorations pour partir sur une autre itération. Il n'est donc pas efficace de faire des centaines de tests. Mieux vaut privilégier des itérations courtes.

‍

‍

3. Choisir le bon outil pour tester le prototype

‍

À ce stade, les maquettes du prototype sont faites à partir d'un logiciel type Adobe XD ou bien Figma.

‍

Pour tester le prototype, on peut utiliser Quant-UX qui a l'avantage d'être open source et gratuit. L'interface est un peu brute, mais permet de faire des tests très complets. Autre avantage, elle permet de simuler un remplissage de champs.

‍

Chez Drakkar, nous utilisons Usebery, une solution plus complète notamment au niveau des Analytics. Surtout, Useberry comporte l'avantage de pouvoir demander plusieurs missions au testeur et donc de vérifier plusieurs usages en une seule session de test.

‍

‍

4. Setup le test

‍

Reprenons notre exemple d'Airbnb, nous souhaitons faire valider la réservation d'un appartement.

Contexte :

‍

‍

Script :

‍

‍

Workflow :

‍

‍

Notation :

‍

Question complémentaire :

‍

‍

5. Partager le test

‍

Le setup fait, il reste à partager le test au panel de testeur. Pourquoi ne pas le faire via un mail ? Dans ce cas, voici un framework simple et efficace :

• Parler du contexte et des objectifs ;
  ‍
• Fixer une date de fin ;
  ‍
• Ne pas oublier de mettre le lien vers le test ;
  ‍
• Rappeler le RGPD : n’oubliez pas que le RGPD s’applique à toute information personnelle que vous collecterez et stockerez à propos de vos testeurs… Le recueil de leur consentement, préalablement au traitement de ces données, est donc indispensable ;
  ‍
• Penser à les remercier ;
  ‍
• Puis, relancer quelques jours plus tard.

‍

‍

6. Capturer et synthétiser les feedbacks / data et prendre des décisions

‍

À ce stade, nous avons récupéré la data et les feedbacks qui vont nous permettre de valider ou réfuter nos hypothèses. Il importe de dresser une cartographie de ces feedbacks pour ensuite prendre les bonnes décisions et suivre les progrès dans le temps. Il y a 3 types de feedbacks produits.

Les feedbacks sur les fonctionnalités

Ces feedbacks vont nous permettre de savoir si le MVP apporte les bénéfices attendus ou non. Peut-être qu'il manque une fonctionnalité clé, peut-être qu'on a mis une fonctionnalité qui n'est pas importante. Il faut toujours garder en tête sa proposition de valeur et faire le lien entre les besoins détectés et les bénéfices apportés par le "feature set". Si le feature set est validé, on peut passer aux deuxièmes types de feedbacks, les feedbacks sur l'UX.

Les feedbacks sur l'UX

On peut avoir un bon feature set qui offre les bénéfices pertinents, mais une UX très pauvre qui empêche les utilisateurs de profiter de ce même feature set.

Les feedbacks sur le messaging

On peut avoir le bon feature set, la bonne UX, mais la manière dont les features sont présentées, la façon dont on parle aux utilisateurs n'est pas claire ou bien ne raisonne pas chez les utilisateurs.

‍

• Regarder les réponses ;
• Regarder la heatmap ;
• Regarder le temps ;
• Regarder le flow ;
• Regarder les sessions enregistrées.

Où est-ce que ça coince ?

Prenez des décisions : Mettre le lien vers le proto Airbnb ?

‍

‍

7. Partager les résultats

‍

Partagez les résultats avec l'équipe. Puis, montrez à la communauté que vous prenez en compte ses retours, cela sera très engageant pour un futur client. Car prendre un produit est un investissement. Nulle n'a envie de payer un SAAS qui n'évolue plus et qui ne prend pas en compte les retours clients. 

‍

‍