Les 4 âges de l’expérience utilisateur (deuxième partie) : l’A/B testing

Les 4 âges de l’expérience utilisateur (deuxième partie) : l’A/B testing

Cet article fait partie d’une série et vous révèlera comment monter en compétence sur l’UX en fonction de la maturité de votre entreprise. Retrouvez le premier article ici : Tests utilisateurs et Web Analytics.

Deuxième étape : intégrer les tests A/B

Montons d’un cran.
Vous suivez l’évolution de l’utilisabilité de votre site (ou application) à travers un tableau de bord simple et lisible. Vous conduisez des tests utilisateurs régulièrement (par petit groupe) afin d’approfondir en détail la connaissance de vos interfaces. Parfait !
Vous tirez régulièrement des enseignements de cet ensemble de données et commencez à rédiger des recommandations que vous transmettrez à votre agence interne ou externe, ainsi qu’à votre DSI. Pour l’heure, vos mises en prod sont lentes (1 fois tous les deux mois), ce qui ne permet pas de suivre la vitesse du marché. Mais, hey !, au moins vous évoluez, même si vous n’avez pas le temps ni les moyens de mesurer votre optimisation. Des progrès sont accomplis, mais, dans le même temps, le trafic augmente, le CA aussi, et vous sentez qu’il existe désormais de grosses opportunités à améliorer l’expérience utilisateur via l’ergonomie de votre site/app.

L’AB testing, la suite logique pour mesurer mieux et mettre en production plus vite

Votre prochain problème va être double :

1. Améliorer la lisibilité de vos interventions / prouvez qu’elles ont un véritable effet bénéfique sur la marche des affaires
2. Aller plus vite

Je me souviens quand sont apparus les premiers outils de tests A/B. C’était la fin des années 2000. Google avait initié la démarche avec un produit pas très pratique, puis quelques sociétés se sont mises à vendre des outils d’AB testing, qui étaient à la fois cher et lourds à utiliser. Mais ensuite, très rapidement sont apparus des solutions légères et efficaces. Ces solutions se sont répandues sur le marché et sont maintenant utilisées à plus ou moins grande échelle par de nombreuses entreprises.
Restons d’accord sur le fait que l’AB testing requiert une certaine dose de trafic pour pouvoir être pratiqué. Autrement, les temps d’enregistrements des données sont trop longs par rapport aux évolutions du marché. Obtenir un résultat au bout de 3 mois de tests suffit déjà à invalider ce résultat.
L’AB testing doit donc apparaître à partir du moment où il vous devient possible de pouvoir obtenir des résultats en 2 semaines et où vous pouvez également les appliquer à la même vitesse. Si votre DSI vous demande 6 mois pour mettre en prod un résultat que vous avez obtenu en 2 semaines, oubliez ! D’ici là, le comportement de vos utilisateurs aura déjà changé. Et tout le monde aura perdu son temps.

L’AB testing, c’est aussi une nouvelle organisation de vos équipes

De plus, et les choses se compliquent encore plus, l’AB testing implique à nouveau l’intégration de ressources humaines supplémentaires ou une nouvelle organisation de votre équipe digitale. J’en discutais l’autre jour avec une responsable de la société AB Tasty. Pour faire de l’AB testing, vous avez besoin, en plus de savoir configurer un outil d’AB testing (ce qui n’est pas compliqué), d’un web designer pour concevoir graphiquement les différentes versions d’un test, d’un intégrateur HTML/CSS pour développer les différentes versions d’un test et pour peu que vous alliez un peu au delà de simples changements comme la couleur d’un bouton, d’un web analyste (encore !) pour interpréter les résultats. Trois nouvelles personnes !
Alors bien sûr, vous les avez déjà parmi vos équipes, mais elles sont tellement occupées à suivre la roadmap que le UX manager va avoir du mal à les mobiliser sur la démarche de test, qui est encore trop vue, comme une cerise sur le gâteau, un luxe qu’on se permet, comme un petit digestif en fin de repas, quand la fête est finie.

Avantages

Pourtant, je ne le répéterai jamais assez, l’AB testing est la deuxième indispensable si vous voulez améliorer l’expérience utilisateur sur vos sites/apps. Et pour plusieurs raisons :

• L’AB testing permet de limiter les risques en mesurant en temps réel les résultats d’une évolution et en éliminant rapidement les solutions qui ne marchent pas
• L’AB testing permet de récupérer de nombreuses données qui permettent non seulement de valider des hypothèses, mais également d’apprendre de nouvelles choses sur le comportement de vos utilisateurs
• Et, cerise sur le gâteau, l’AB testing vous permet d’accélérer vos mises en productions sans passer par la DSI. Ce qui est un avantage non négligeable, n’est-ce pas ?

A partir du moment où l’on se lance dans une démarche d’optimisation par l’AB testing, je pense qu’il faut aussi songer à commencer à embaucher et à internaliser un minimum votre démarche UX globale. Il n’y a pas de solution parfaite, mais donner un peu de mou à l’UX manager en lui adjoignant un assistant qui prendra en charge une partie de de ses besoins apparait alors nécessaire. Notamment pour la programmation des tests, chose peu compliquée en soi, tant que l’on reste sur des sujets “abordables” (ne nécessitant pas de web design spécifique ou de programmation javascript ou de coordination avec le SI pour intégrer des fonctionnalités à des tests). Vous ne trouverez sûrement pas la perle rare, mais pensez déjà à la manière dont vous pourriez répartir les rôles au sein de l’équipe UX pour une évolution future en prévision de votre croissance.

Les deux niveaux de complexité des tests

Quand on parle d’UX et d’optimisation de l’UX, d’un point de vue technique, cela se traduit par 2 choses qu’il faut nettement séparer, parce qu’elles ont des implications différentes sur la marche des tests :

1. Améliorer l’UX en modifiant l’organisation des pages et l’apparence des choses : dans ce cas, on ne touche qu’au HTML/CSS des pages et, tout va presque bien, l’organisateur des tests peut rouler tout seul, sans recourir à la DSI. Il est autonome et peut aller vite. D’autant que lorsqu’il engrange des résultats, il peut facilement récupérer le code qu’il a créé et le donner à la DSI qui l’intégrera dans sa roadmap plus ou moins vite
2. Améliorer l’UX en ajoutant de nouvelles fonctionnalités ou en utilisant des données non présentes dans les pages webs (données clients, données externes tierces) : dans ce cas, l’appel à la DSI est parfois nécessaire et cela ralentit évidemment le rythme des tests. Je n’ai rien contre la DSI, mais le fait est que modifier un site ou une app demande du temps à un rythme souvent difficilement compatible avec celui du marketing et de l’expérience utilisateur. D’où les frictions, dommages, mais possibles à ce niveau.

Dans la pratique, et expérience faite, ce que j’ai constaté auprès de nos clients, et qui est un phénomène qui se répète comme un vieux tube de variété :

• Epaté, au début, par toutes les possibilités que leur offre l’outil de tests A/B, les équipes (“les”, façon de parler) se lancent dans des tests tout azimuts et essayent chaque fonctionnalité de leur nouveau jouet. Et, il est vrai, que sans toucher au code, grâce par exemple à un système de plugin, même le stagiaire pourra arriver à monter un test A/B,presque les yeux bandés.

Mais une fois cette phase de découverte passée et qu’il s’agit de passer aux choses sérieuses, il en va bien autrement.

La planification

On peut tout tester, encore faut-il savoir dans quel ordre et avec quel espoir de rentabilité. Je ne rentrerai pas dans le détail ici, mais établir une roadmap est beaucoup plus pernicieux qu’il n’y parait et demande un investissement en temps et en jus de cerveau que je ne qualifierai de pas nul.
De cette première phase s’ensuite une seconde qui est la programmation des tests même. Car, fort d’avoir utilisé l’éditeur visuel de votre solution favorite, vous vous rendrez compte rapidement qu’un minimum de connaissance HTML/CSS est nécessaire pour élaborer des tests qui vont au delà de simples ajustements de page. Sans compter la dimension technique d’un test qui nécessite de vérifier la compatibilité de votre affichage sur différentes terminaux, différents navigateurs et OS. Plus problématique encore, vous vous rendrez rapidement compte de la nécessité de pouvoir programmer du code en javascript, quelque chose dont on ne vous avait sans doute pas parlé au départ (je sais ce que sont les commerciaux d’une solution. J’en suis moi même un. Notre métier est toujours de vous faire voir le meilleur, pas de soulever le tapis et de vous montrer les petits cafards qui courent dessous).

Lire les résultats : tout un art !

Mais, Ô surprise, il reste encore une dernière phase (la troisième) lors de la réalisation d’un test. Celle de la lecture des résultats. Et là encore, vous n’êtes pas au bout de vos peines. Lors de vos premiers tests, simples, il vous était encore possible de vous fier à ce que vous donnait votre outil de test A/B, mais très rapidement encore, vous comprendrez que cela est loin d’être suffisant. A votre grand étonnement, vous découvrirez, par exemple, que les écarts de résultats entre vos différentes versions de test sont minimes, voire presque infructueuses. “Damned”, vous écrirez-vous ! “Tout ça pour ça ?” Tant d’efforts pour de si petits progrès ?
Ne vous découragez pas. Les tests A/B recèlent des trésors insoupçonnés. Il suffit de savoir aller les chercher. Et là, à nouveau, du temps vous sera nécessaire, beaucoup de temps. Car le succès d’un test ne peut se mesurer qu’à l’aune d’un ou deux kpi, mais la plupart du temps en regardant des données croisées, enfoncées profondément dans vos datas. Peut-être que votre taux de transformation n’a pas bougé sur vos 3 versions de tests… peut-être… mais avez-vous analysé les résultats sur tous vos segments de visiteurs ? Avez-vous regardé s’il n’y a pas des différences par heure ? Par région ? Par provenance ?
C’est à ce moment que nous entrons dans le monde merveilleux de la web analyse. Mais je suis sûr que ça non plus, vous ne l’aviez pas prévu. (Et c’est aussi d’ailleurs par la même occasion le moment de rentrer dans le non moins merveilleux monde de la personnalisation, mais ça, j’en parlerai un peu plus loin, au troisième stade de l’optimisation).

Conclusion et perspectives

Rapidement, vous découvrirez que tester et faire évoluer un site avec les tests A/B vous demandera non seulement de vous organiser différemment, mais aussi d’avoir des compétences spécialisées disponibles à plein temps pour réaliser et tirer entièrement parti de votre outil.
Faire évoluer un site, desktop ou mobile, ou une appli, entraîne automatiquement le besoin de faire grandir vos équipes dans les deux sens du terme :

• en quantité
• en compétences

C’est la deuxième étape. Celle de l’optimisation continue. Dans le long terme, elle vous fera économiser énormément d’argent en vous permettant de faire évoluer votre site sans coup férir, en évitant notamment les atroces phases de refonte où l’on casse tout et on recommence. Mais également en vous donnant une manière de travailler où les choses sont mesurées, soupesées et les décisions prises en se basant sur des données (mais pas que).
A la semaine prochaine pour la troisième partie de cette série !

---

• Première partie : Les 4 âges de l’expérience utilisateur : tests utilisateurs et web analytics
• Troisième partie : Les 4 âges de l’expérience utilisateur : l’âge de l’émotion
• Quatrième partie : Les 4 âges de l’expérience utilisateur : la personnalisation