ux design

A/B Test et UX design : l’utilisateur préfère cette version ? Non !  

Par
publié le

Avant toute chose, il convient d’éclaircir un point très souvent source de confusion liée aux similitudes dans les outils, le vocabulaire, les méthodes : il s’agit de la question de la frontière entre le marketing et l’UX design. Si les méthodes se ressemblent (focus group, interview, ), elles ne sont pas nécessairement utilisées aux mêmes fins. Dans son livre Design d’Expérience Utilisateur, Sylvie Daumal relate les paroles d’un confrère UX designer (David Serrault) :

«Le marketing se concentre sur la promesse, l’UX design tente de la tenir ». 

L’A/B test fait partie de ces outils, utile au marketing autant qu’il l’est à la recherche utilisateur, la différence se situant dans l’usage qui en est faitC’est dans ce deuxième contexte que s’inscrit cet article.  

Outil de prédilection du marketing pour ajuster des stratégies de contenu, de mise en page, de promesse, l’A/B test est aussi un formidable outil pour les designers en ce qu’il permet d’en apprendre beaucoup sur le comportement d’un utilisateurMais utilisé à de mauvaises fins, il peut aussi se transformer en un redoutable piège. 

 

Rappel
Dans le monde digital, l’A/B testing consiste à proposer deux versions d’une page, d’un élément, d’un système ou d’un parcours, aux utilisateurs et de mesurer selon un indicateur clé (KPI) décidé à l’avance quelle version performe le mieux sur le KPI en question. L’A/B test permet de confronter ses hypothèses à la réalité du marché, à la masse des utilisateurs. Il se différencie donc des tests qualitatifs, qui permettent de recueillir des données plus subjectives. 

Piège n°1 : Ne tombez pas dans la facilité 

L’A/B test recèle ainsi un formidable potentiel de facilité. Celui de pouvoir trancher très rapidement un sujet qui fait débat, que l’hypothèse testée émane de l’équipe produit ou bien du commanditaire. 

Or, c’est une erreur facile. Un A/B test ne sert pas à déterminer qui a tort ou raison dans une équipe. Cet outil ne devrait jamais servir à remettre en cause une expertise métier. Le piège est de rapidement nous faire douter de nos expertises, et de celles des autres. Et de nous faire perdre beaucoup de temps.

Par exemple, les deux propositions ci-dessous ne méritent pas un test A/B au prétexte que nous doutons de la préférence de l’utilisateur pour une couleur ou une autre 

Peu importe la couleur que l’on préfèreDans ce cas précis, le designer est légitime pour affirmer : le bouton sur la version B est plus contrasté. Les éléments possédant le plus de contraste sont mieux vus. Il n’y a pas besoin d’A/B test. Cela relève de l’expertise métier.   

Piège n°2 : « L’utilisateur préfère cette version » 

A tester nos propres croyances on en arrive vite au raccourci de l’utilisateur préfère cette version. Une aubaine pour des designers !

La réalité c’est que vous trouverez toujours une version qui fonctionnera plus qu’une autre. Et vous pourrez tester toute la palette de couleurs possibles et imaginables sur un bouton, ça ne voudra jamais dire que celle qui génère le plus de clics est la bonne. En effet, un bouton mieux vu ne le rend pas forcément plus compréhensible 😉 Ce que l’on mesure, c’est la performance d’un élément et non pas le ressenti ni sa compréhensionDe la même façon, une version gagnante sur un élément isolé d’un parcours peut nuire à la cohérence globale de tout le parcours.  

Alors à quoi sert le test A/B ?!  

Pour des designers, le test A/B permet d’avoir des éléments de réponse aux questions que l’on se pose sur le comportement des utilisateurs et dont la réponse ne relève pas d’une expertise métier présente dans l’équipe.  

Exemple :  L’ajout d’un bouton "J’ai déjà un devis" sur la fiche produit de l’assurance habitation permet-t-il de simplifier le parcours utilisateur pour la souscription de ce contrat d’assurance ?  

  • Notre hypothèse : certains utilisateurs reviennent sur la fiche produit pour souscrire après avoir fait un devis au lieu de se connecter à l’espace personnel créé pour l’occasion. 
  • Ce que nous mesurons : la variation du nombre de reprises de devis après ajout du bouton 
  • Le résultat : 3 % des utilisateurs ayant été exposés à ce bouton ont cliqué dessus. Et nous constatons effectivement une augmentation du nombre de devis repris. La version de contrôle A nous permet de vérifier que ce n’est pas un report de clics mais bien un nombre de clics supplémentaires.

L’ajout d’un bouton “J’ai déjà un devis” permet de mieux orienter l’utilisateur vers la reprise de devis, lui évitant ainsi de remplir à nouveau le formulaire pour retrouver son tarif et ainsi finaliser la souscription plus rapidement s’il le souhaite.

Coupler le quanti avec le quali et tutti quanti

Ce que l’on ne sait pas en revanche, c’est la motivation profonde de l’utilisateur qui arrive sur cette page lorsqu’il a déjà un devis. Souhaite-t-il finaliser sa souscription ? Uniquement re-consulter son devis pour comparer ?

En effet, le test A/B nous donne une indication quantitative mais pas qualitative. Si ça ne fonctionne pas, il y a de grandes chances qu’on ne sache pas pourquoi et l’inverse est vrai aussi. Coupler les test A/B avec des tests utilisateurs ou des entretiens en amont ou en aval permet d’exploiter au mieux le potentiel de cet outil et permet aussi de générer des idées d’A/B testing ou d’en expliquer les résultats.

Exemple :

  • Je découvre un fait marquant pendant le test utilisateurs, je peux faire un test A/B pour le confronter au quantitatif et vérifier en cas de doute si c’est un cas isolé ou non.
  • Je fais un test A/B et je découvre que des utilisateurs visitant les pages produits ont déjà un devis. Je peux creuser en test utilisateurs pour questionner ce qu’ils s’attendent à trouver derrière ce bouton.

En tant que designer, nous avons tendance à chérir le qualitatif. Mais les méthodes de confrontations d’une hypothèse à du quantitatif permettent de générer rapidement des questionnements à approfondir en tests utilisateurs ou inversement et permettent d’apporter des enseignements très solides à son équipe !