Le bon, le mauvais et le laid des tests A / B
Sur D’une part, je pense que c’est un outil très puissant qui peut aider les concepteurs à surmonter les batailles d’opinion, à tester les hypothèses et à mettre rapidement les solutions les plus efficaces entre les mains des clients. Cependant, nous courons également le risque de retirer le jugement humain de l’équation, de prioriser les KPI de l’entreprise sur les besoins des clients et d’itérer vers les maxima locaux.
Les avantages des tests A / B sont assez évidents. Vous envisagez d’apporter quelques améliorations simples à la conception ou au produit, mais vous n’êtes pas sûr à 100% de ce qui donnera les meilleurs résultats. Une de vos équipes est très convaincue d’une direction, une de vos parties prenantes est fortement convaincue de l’autre, et le reste d’entre vous ne peut pas en être sûr.
Dans ce genre d’impasse, la politique vient invariablement à jouer. Qui a le plus d’influence dans l’organisation, qui est le mieux placé pour défendre leur cause et qui ne peut pas se permettre de faire chier? Si la personne en question est particulièrement douée pour plaider sa cause, pourrait-elle argumenter le contrepoint de manière tout aussi convaincante? Dans ce cas, existe-t-il vraiment une solution claire et évidente?
Dans ces situations, deux choses peuvent se produire. Soit une personne parvient à ses fins, laissant les autres frustrés que leurs opinions n’aient pas été entendues, ou pire, aucune décision n’est prise et cette conversation est prête à se répéter ad nauseam. Je suis sûr que nous avons tous été là.
Un bon exemple de ce type de décision est le widget humble ratings. Imaginez que vous faites partie d’une équipe de produits qui essaie de décider si une étoile ou un système numérique serait préférable. Si vous optez pour le système d’étoiles, devez-vous utiliser quatre, cinq ou six étoiles, et ne devez-vous autoriser que des parties d’une étoile à apparaître? Si vous choisissez un système numérique, devrait-il être une note de 5, 10 ou 100 points, et accepterez-vous les décimales?
Vous pouvez faire une recherche documentaire pour voir s’il existe un document de recherche sur le sujet, mais comment savez-vous que cela fonctionnera avec votre public particulier? Ou vous pouvez simplement copier ce que font vos concurrents. Après tout, ils sont plus gros que vous, alors vous avez sûrement dû faire des recherches?
C’est la situation dans laquelle Sim Wishlade d’OpenTable s’est récemment retrouvé, et il écrit avec éloquence sur les recherches qu’ils ont entreprises et les conclusions qu’ils ont faites dans un article Medium intitulé, Quand 3/5 n’est pas égal à 6/10. Comme vous pouvez l’imaginer, la solution évidente n’est pas toujours la meilleure.
En tant que concepteurs, nous nous considérons comme des décideurs expérimentés avec un sens aigu de ce qui fonctionne et de ce qui ne fonctionne pas. Des tests A / B répétés montrent que nous ne sommes pas aussi précis que nous aimerions le penser. Nous aimons expliquer que les clients sont de terribles juges des comportements futurs, sans se rendre compte que nous sommes la proie des mêmes biais. Il s’avère que nous sommes en fait des juges assez pauvres du comportement futur des utilisateurs.
Dans son parler de The Next Web en 2013, Dan Siroker explique certains des tests qu’il a effectués pour la campagne Obama. Il pose une question simple au public. Laquelle de ces vidéos, laquelle de ces images d’en-tête et lequel de ces appels à l’action se sont révélés les meilleurs. Comme vous pouvez l’imaginer, le public a obtenu la réponse de façon spectaculaire, tout comme leurs propres concepteurs.
Si même les meilleurs designers font ce genre d’erreurs, pourquoi n’en testons-nous pas plus? Je pense qu’il y a quelques réponses à cela.
La première réponse est un problème de processus et d’outillage. Bien qu’il soit relativement facile pour un concepteur individuel de lancer un test d’utilisabilité rapide de manière indépendante, le test A / B nécessite des outils et une coordination. Vous devez choisir une plate-forme de test A / B, vous avez besoin de vos partenaires de développement pour la mettre en œuvre, et vous devez avoir à la fois le temps et la capacité de faire quelque chose avec les résultats. Comme vous pouvez le voir, il y a beaucoup d’endroits où quelque chose comme ça peut tomber.
Pour commencer, choisir et mettre en œuvre des solutions de test A / B prend du temps et de l’argent. Alors, qui va être responsable de l’évaluation et de l’acquisition de ce système, qui va gérer et mettre en œuvre le système, et qui va payer pour cela? La plupart des équipes de produits éprouvent des difficultés à expédier leur carnet de commandes existant sans ajouter de travail supplémentaire.
Si vous parvenez à mettre en place un cadre de test, la mise en œuvre des tests nécessitera une coordination entre vos équipes de conception, d’ingénierie et d’analyse. Je suis sûr que le contrôle qualité aura également quelque chose à dire ici. Étant donné que la relation entre la conception et l’ingénierie peut être difficile dans le meilleur des cas, est-il étonnant que les concepteurs préfèrent s’en tenir à une approche de test plus qualitative qu’ils peuvent gérer en grande partie par eux-mêmes?
L’autre problème concerne le pouvoir et l’image de soi. Les concepteurs ont toujours été au bas de la hiérarchie en ce qui concerne les équipes de produits, car ils n’ont ni le muscle des équipes d’ingénierie (sous la forme d’effectifs), ni l’influence des chefs de produit. Les concepteurs sont donc très conscients de tout ce qui peut leur retirer davantage de pouvoir.
Admettre qu’ils ne connaissent pas les réponses à des questions, même élémentaires, telles que « devrions-nous utiliser des étoiles ou des nombres? » peut saper le peu de pouvoir et de statut dont ils disposent déjà. Transférer une partie de ce pouvoir à une équipe plus analytique peut être encore plus difficile, surtout si l’histoire récente se passe.
Non, nous ne parlons pas d’un nouveau E.L. Série James ici. Au lieu de cela, nous parlons d’un incident qui s’est produit chez Google il y a de nombreuses années, et qui est par la suite entré dans le folklore des créateurs. Au début de Google, le design n’avait pas encore de «place à la table» et les concepteurs avaient du mal à prospérer dans un environnement dominé par les tests. Chaque petite décision devait être testée et validée, y compris la valeur hexadécimale précise d’un bouton. Dans un article désormais célèbre, le designer Doug Bowman a expliqué comment leur culture de test l’avait chassé.
« Oui, il est vrai qu’une équipe de Google ne pouvait pas choisir entre deux bleus. Ils testent donc 41 nuances entre chaque bleu pour voir laquelle est la plus performante. J’ai récemment eu un débat sur l’opportunité d’une bordure de 3, 4 ou 5 pixels de large, et on m’a demandé de prouver mon cas. Je ne peux pas fonctionner dans un environnement comme ça. Je suis fatigué de débattre de décisions de conception aussi minuscules. Il y a des problèmes de conception plus passionnants à résoudre dans ce monde. »
Cet article a trouvé un écho chez de nombreux designers qui estimaient qu’ils devaient prouver chaque petite décision à partir des premiers principes, et leur agence en tant que designer diminuait en conséquence. Tandis que Google a ensuite justifié sa décision, Je peux comprendre ce point de vue. Il semble souvent que les décisions douteuses soient poussées à la production par d’autres départements avec peu ou pas de diligence raisonnable, mais lorsqu’un concepteur souhaite apporter un changement, même minime, il doit fournir des preuves irréfutables que c’est la bonne chose à faire.
L’essentiel est donc l’équilibre. Créer une culture où les tests A / B ne sont pas utilisés comme un bélier pour gagner des arguments et garantir que les bonnes choses sont testées.
Une entreprise comprend mieux les tests que la plupart des autres, et ce sont les gens de Booking.com. Dans son excellent discours sur Google Conversations, alors directeur du design Stuart Frisby, explique comment il a créé une culture d’expérimentation au sein de son équipe.
Alors que les concepteurs devraient faire beaucoup plus de tests A / B qu’ils ne le sont actuellement, il y a quelques pièges à connaître. L’idée que chaque solution qui fonctionne mieux est donc la bonne solution.
Il est facile de voir d’où vient cette attitude. Les équipes apprennent que c’est leur travail d’améliorer l’expérience client et que la façon de le faire est d’optimiser pour des KPI et OKR spécifiques; généralement liés à l’acquisition, la rétention et la satisfaction du client. Les équipes ont donc décidé de déplacer le cadran, sachant que si elles atteignaient leurs cibles, tout irait bien.
Vous pouvez voir un aperçu de cet état d’esprit dans ce excellente histoire d’Anna Blaylock sur Netflix. En rejoignant l’équipe Netflix, Anna s’est demandé pourquoi le produit ne permettait pas aux clients potentiels de voir tout le contenu proposé avant de s’inscrire. Du point de vue d’un concepteur, cela semble être une chose sensée à faire, et Anna s’est donc mise à concevoir un test.
Comme vous pouvez probablement l’imaginer, le test est revenu négatif. Il s’avère que plus de gens s’inscrivent à Netflix s’ils ne voient pas tout ce qui est proposé à l’avance. Anna compare cela à la différence entre lire un menu de restaurant et manger de la nourriture. L’expérience de l’utilisation de Netflix est bien plus que la simple liste de films et d’émissions de télévision proposés; tout le reste est une distraction. Si je travaillais chez Netflix, j’aurais probablement une opinion similaire. Je savais que le produit était incroyable, en partie parce que je l’ai construit, et donc tout ce que je devais faire était de supprimer autant de barrières que possible, pour laisser les autres tomber amoureux également.
Cependant, je pense qu’il pourrait y avoir une autre raison pour laquelle les inscriptions ont diminué. Et si certains utilisateurs voulaient prendre une décision éclairée sur le contenu et décidaient qu’il n’y avait pas assez de valeur pour eux? Peut-être qu’ils cherchaient à voir si leur émission préférée était sur cette plate-forme particulière, ou essayaient-ils de juger si Netflix avait plus de contenu qu’ils aimaient qu’Amazon? Donc, peut-être que montrer aux utilisateurs le catalogue avant de chanter était la «bonne» chose à faire, même au détriment des ventes.
Je pense que c’est l’un des défis des tests A / B. Il est facile de supposer que l’optimisation autour d’une métrique spécifique est intrinsèquement bonne, et faites tout ce qui est en votre pouvoir pour atteindre ces chiffres.
Maintenant, cet incident particulier est assez inoffensif, c’est pourquoi je l’ai choisi. Cependant, je crois que lorsque cette case n’est pas cochée, les tests A / B peuvent entraîner de graves problèmes.
Il est sûr de dire que les choses sont un peu folles en ce moment. Mis à part les pandémies mondiales, toutes sortes de croyances marginales semblent gagner du terrain ces derniers temps, des théoriciens de la Terre plate aux personnes incendiant des mâts 5G, et bien pire.
Alors que beaucoup de gens blâment « Les Algorithmes », ce dont ils parlent vraiment, c’est d’une forme extrême de test multivarié. Voir quel contenu est le plus efficace pour stimuler l’engagement et en fournir davantage. Les plates-formes modernes peuvent exécuter des dizaines, des centaines, voire des milliers de tests par jour. Beaucoup de ces tests sont automatisés, les décisions ne sont pas entièrement comprises et ne passent pas nécessairement par une sorte de lentille éthique. Tant que les métriques montent et à droite, tout le monde est content.
[I sometimes joke that while engagement metrics are going up and to the right, so is the tone of the conversation]
Je crains que dans leur quête d’efficacité, de nombreux grands acteurs aient trop instrumenté leurs processus de conception; éliminer la diligence raisonnable humaine et se cacher derrière leurs OKR dans leur conviction inébranlable que plus signifie mieux.
Je veux dire, je pense que nous pouvons tous nous mettre d’accord sur l’expérience transformationnelle du voyage (empreinte carbone mise à part). Mais qu’en est-il du stress supplémentaire que vous causez avec votre message intelligemment rédigé expliquant que c’est la « dernière chambre à ce prix » et que « 5 autres personnes regardent cette chambre en ce moment »? Ce n’est pas exactement un motif sombre (en supposant que les informations sont vraies) et je suis sûr que la formulation a bien été testée, mais est-ce la « bonne » chose à faire?
De même, je pense que nous pouvons tous convenir de l’utilité des recommandations sur les plateformes de streaming vidéo. Cependant, est-ce vraiment bénéfique pour l’utilisateur lorsqu’il a l’intention de regarder une vidéo, mais finit par en regarder trois? Le plus grand concurrent de ces plateformes de streaming est peut-être le sommeil, mais est-ce quelque chose à optimiser?
Maintenant, j’apprécie que les tests A / B – et son cousin, les recommandations programmatiques – ne sont pas uniquement à blâmer ici. Mais l’échelle à laquelle cela se produit au sein des entreprises est devenue difficile à contrer. Surtout en se cachant derrière l’argument selon lequel tout ce que nous faisons vraiment est d’optimiser pour le même ensemble de KPI que nous avons toujours fait; nous nous améliorons simplement.
Donc, même si je pense que les concepteurs devraient faire plus de tests qu’ils ne le sont actuellement, je pense également qu’il est important de savoir quand ne pas automatiser la prise de décision. Je vous encourage à commencer à jouer avec la technologie, et peut-être même à envisager de déménager dans une culture de test mature lors de votre prochain changement de poste.
Mais il peut également être utile de poser aux enquêteurs la question suivante:
«À quand remonte la dernière fois que vous avez décidé de ne pas envoyer un changement dont les tests A / B ont démontré qu’ils fonctionnaient mieux, et pourquoi?
De cette façon, vous pouvez au moins dire si le chien remue la queue ou si la queue remue le chien.