Quand vous voulez augmenter le nombre de tests A/B pour faire plus d'expériences en même temps, il vous faut adapter vos processus et plateformes, et cela peut impacter votre culture. C'est ce qu'explique Ben Dressler, responsable des expérimentations chez Spotify. Réaliser de la recherche produit avec des expériences contrôlées aide à valider vos hypothèses sur l'utilisation que vos clients font réellement de votre produit, et permet de vérifier si vos idées ont vraiment un effet sur les comportements client.
La plupart du temps, il est intéressant que les utilisateurs participent à plusieurs tests A/B en même temps, les attributions aléatoires lissant les impacts sur vos différents groupes de test. Dressler explique que cela devient par contre un problème si vous générez des expériences conflictuelles pour quelques utilisateurs, par exemple en poussant du texte blanc dans un test, et des fonds blancs dans l'autre.
Dressler s'est exprimé sur la construction d'une culture de l'expérimentation chez Spotify durant GOTO Berlin 2016.
InfoQ a échangé avec Dressler après sa conférence sur le besoin d'expérimenter des entreprises, la manière de passer à l'échelle les tests A/B, et les options quand les personnes sont sceptiques sur l'A/B testing.
InfoQ : Pourquoi les entreprises doivent expérimenter ?
Ben Dressler : La plupart des entreprises et des organisations essayent d'avoir un impact sur certains résultats. Dans une organisation orientée produit comme Spotify, c'est souvent un ensemble de métriques métier qui s'appuient sur des actions utilisateur, comme acheter quelque chose ou continuer à utiliser le produit. Et souvent les employés ont beaucoup d'idées sur la manière d'y arriver. Rassembler des données quantitatives et qualitatives sur ces clients est une bonne manière d'approfondir votre compréhension de ce qui va appuyer ou dissuader ces comportements. Mais sans réaliser des expérimentations contrôlées, vous ne parviendrez pas à savoir si vos actions, par exemple une fonctionnalité, ont un réel impact sur les comportements à modifier - ou si c'est simplement une corrélation pour laquelle pousser plus de ressources dans la fonctionnalité n'aura pas d'effets.
L'A/B testing a la réputation de n'être qu'un outil pour optimiser les détails des sites web, mais c'est fondamentalement un outil pour confronter vos idées à la réalité et vérifier si elles ont bien l'effet auquel vous pensiez.
InfoQ : Comment déployer l'A/B testing à grande échelle ?
Dressler : Augmenter le nombre de tests en cours dépend de quelques aspects : à quelle vitesse vous pouvez faire demi-tour, quelle est la taille de votre population, et combien de tests vous pouvez réaliser par utilisateur. Etant donné que la taille de votre population est généralement fixée, vous voulez faire plus de tests par utilisateurs et les inverser plus vite. Les problèmes qui arrivent souvent à cette étape sont la charge pour les équipes, aussi bien techniquement que sur les aspects de processus, sauf à avoir rationalisé suffisamment ces derniers. Si vous avez une application et avez besoin de coder en dur tous les changements, vous serez étouffé par les cycles de versions, et les ingénieurs et designers auront besoin d'être à l'aise avec le lancement de tests non complètement finalisés. Une bonne idée est de choisir quelques équipes pour pousser ceci, puis de comprendre les besoins de changement requis sur la plateforme et les processus pour le déployer sur toutes les équipes.
Faire plus de tests par utilisateur signifie que les expériences peuvent potentiellement se heurter et créer une expérience utilisateur dysfonctionnelle. Si une équipe teste le changement de toutes les polices en blanc - et qu'une autre équipe change tous les fonds en blanc - les personnes subissant les deux tests à la fois ne pourront plus utiliser le produit. Il y a différentes solutions mais il est important de souligner que tout se passe bien pour les utilisateurs participant à plusieurs tests en même temps dans la majorité des cas. Comme vous positionnez les utilisateurs de manière aléatoire dans les groupes de test, il devrait y avoir un faible nombre de personnes impactées sur l'ensemble des groupes. Les tests A/B se concentrent seulement sur les différences entres vos groupes, si tout le monde est affecté de la même manière, cela ne faussera pas les résultats.
InfoQ : Pourriez-vous partager un exemple d'expérience ?
Dressler : Il y a quelques temps, nous avons vu des indices dans nos recherches faisant penser que nous pouvions manquer une opportunité autour de la navigation dans Spotify. Nous avons supposé qu'en simplifiant la navigation dans l'app, nous pourrions donner une meilleure idée aux nouveaux utilisateurs de ce qu'ils peuvent faire avec Spotify, et donc accroître la probabilité qu'ils restent sur la plateforme.
La croyance commune nous aurait poussé vers un design sprint, faire quelques tests utilisateur, et finalement essayer d'enlever ce que nous avions fait. Tandis que nos designers ont bien commencé avec une phase exploratoire, nous avons vite plongé dans un premier jet de tests A/B. Un des tests s'intéressa au changement de l'UI (et seulement cela), tandis qu'un autre modifia l'architecture de l'information (les titres et la structure des catégories). Ce n'était vraiment pas des expériences finalisées et l'intention n'a jamais été d'ouvrir à plus de monde. Ce que nous recherchions était un signe de notre capacité à infléchir le comportement client grâce à cela. Si une transformation ne modifie même pas le taux de poursuite, nous ne voulons sans doute pas investir davantage de ressources dans cette idée. Les résultats à l'inverse suggéraient que nous changions le comportement des utilisateurs vers notre cible dans certains groupes. En s'appuyant sur cela, nous avons continué à explorer différents prototypes sur de petits groupes d'utilisateurs pour arbitrer sur les variations et pour rassembler des observations situées très vite. C'est seulement à ce moment là que nous nous sommes servis des tests traditionnels d'optimisation A/B, pour atteindre une version finalisée déployable pour tous nos utilisateurs.
InfoQ : Que diriez-vous aux personnes qui sont sceptiques vis-à-vis des tests A/B ?
Dressler : Tout d'abord, je dirais qu'il est important de s'intéresser à l'expérimentation avec soin. Quand des sujets complexes d'ingénierie et de statistiques avancées se rencontrent, il devient facile de se tromper. Les faiblesses de votre processus de développement et de collecte de données seront soulignées en construisant des variations et des tests statistiques. L'A/B testing est un des outils à la puissance folle pour la recherche produit et requiert une expertise avancée et des changements potentiels dans votre culture. Il est fort probable que vous introduisiez des frictions.
Cela posé, les expériences sont aussi d'une puissance incroyable et ouvre des tonnes de potentialité autre que la simple suppression de quelques clics. Si vous vous équipez intelligemment et conduisez des expériences futées, vous pouvez éviter de brûler des tonnes de ressources sur une mauvaise idée, découvrir des informations vitales plus tôt sur la manière de limiter le risque des grands projets ou faciliter l'innovation du bas vers le haut en testant beaucoup de petites idées et promouvoir celles qui ont un impact. Quant à la vitesse, considérez ceci : allez à 200 à l'heure n'est pas si rapide si vous allez dans la mauvaise direction.
J'encouragerais tout le monde à au moins essayer cela et avec des siècles de gestion d'expérimentations faussées et de mesures imparfaites, les sciences nous proposent quelques bonnes techniques : refaire les tests et vérifier si les résultats sont reproductibles, accompagner l'émergence d'une communauté qui valide le travail de chacun et continuer à itérer sur les pratiques et les instruments sous-jacents. Et le plus important, être conscient que la certitude absolue n'existe pas. Prendre des décisions avec une information imparfaite sera toujours le travail d'un responsable de produit, et les expériences ne sont rien de plus qu'un outil plus ou moins puissant pour aider dans ce travail.