Michael Baeyens : structurer (et prioriser) ses données grâce à l’Atomic Research

C'est le sujet en prime time pour beaucoup de Researchers : passer à une approche "Atomic Research".

L' Atomic Research permet de récolter, centraliser et exploiter tous les types de sources d'enseignements utilisateur, selon un concept de fractionnement de la connaissance.

Michael Baeyens en est un des pionniers en France. Quand il est arrivé chez France Télévisions il y a 10 ans, il a dû développer une culture de la centricité-utilisateur et structurer la Research. Et la question de l'organisation et du partage des enseignements s'est rapidement retrouvée au programme.

Comment stocker les enseignements et les rendre facilement accessibles aux équipes ? et surtout... comment les prioriser ?

Nous avons rencontré Michael pour échanger sur la genèse de cette réflexion, les difficultés rencontrées, et ses conseils pour mettre en place ce système.

‍

Tactix : Quand tu arrives chez France Télévisions il y a 10 ans, tu te fixes comme objectif de mettre en place une culture du Design et de la Research. Comment t’y es-tu pris ?

Michael : À la base, je n’ai aucun background en Research ! Je me suis formé sur le tas… j’ai d’abord été créatif en agence de communication, avant de rejoindre France Télévisions. Je suis rentré en tant que solo Designer, mais très rapidement je me suis entouré et aujourd’hui l’équipe compte 60 personnes réparties sur 10 produits différents. C’est avec cette croissance que le besoin de faire changer les mentalités s’est fait ressentir : mettre en place une culture du Design et de la Research, commencer par le problème et non par la solution, être plus collaboratifs dans nos façons de faire…

La première chose, c’est mettre dans la tête de chacun que l’utilisateur est notre préoccupation principale.

Dans notre cas c’est passé par un gros effort de tests utilisateurs. Nous nous sommes mis à systématiquement confronter tous nos prototypes à des utilisateurs finaux, et nous avons diffusé les résultats dans des showrooms à l’ensemble de nos collaborateurs. Cet effort de pédagogie, d’acculturation à la démarche utilisateur, est nécessaire avant de rentrer dans une complexité de personas ou de Jobs-To-Be-Done par exemple.

Et ce n’est pas forcément facile : dire que l’on va être “centré-utilisateur” c’est une chose, le faire ça en est une autre. Il y a beaucoup de considérations externes au Design et à la Research à prendre en compte dans une entreprise, en particulier dans les grands groupes. C’est ce que j’appelle des “contraintes de réalité” : des implications légales, des migrations technologiques, des obligations éditoriales,… Tout l’enjeu était donc de faire passer le message que malgré ces injonctions, il était nécessaire de libérer de la bande passante dédiée aux besoins des utilisateurs dans toute leur complexité.

Tout cela, nous l’avons réalisé dès 2017, nous étions donc vraiment des pionniers sur l’exercice !

Justement, tu te définis comme un pionnier de l'Atomic Research : comment en es-tu venu à réfléchir sur ce sujet ?

Nous cherchions à résoudre un problème fondamental pour nos équipes. Nous faisions énormément de Research, et nous avions constaté des redondances dans nos enseignements, sans que nous ne les documentions vraiment.

Je vais te donner un exemple concret : un jour un PO avec lequel je travaillais m’a expliqué que dans le cadre d’une refonte, il souhaitait retirer un élément graphique spécifique des fiches descriptives de nos contenus. Quand je lui ai demandé pourquoi, il m’a dit qu’il était persuadé que les utilisateurs n’accordaient pas d’importance à cet élément. Ce qui est fou, c’est que nous savions pertinemment que c’était faux car nous l’avions vu 1000 fois dans le cadre de projets de Research, mais nous n’avions aucune preuve…

Le principe de l’Atomic Research c’est justement que des observations qui ont été faites dans le cadre d’expérimentations diverses et variées reviennent régulièrement, et qu’elles viennent nourrir des insights qui sont universels à l’ensemble de ces expérimentations.

Cela change complètement la nature du dialogue avec le Produit !

D’une part, nous avons des convictions fortes du fait de l’historicité des enseignements, et du mix quali / quanti. Cela nous permet de dire avec confiance qu’un problème est vraiment structurant pour les utilisateurs. Et d’autre part, nous pouvons prioriser la prise en compte de ces enseignements directement dans le même outil et ainsi nourrir la roadmap Produit. Ce second point est important car il constitue une vraie innovation : cela ne fait pas partie de la théorie initiale de l’Atomic Research, c’est ce que nous avons appelé la Product Atomic Research.

Comment structures-tu la Product Atomic Research ?

Nous nous sommes inspirés de la théorie partagée par le génial Daniel Pidcock, que nous avons tordue pour qu’elle aille dans notre sens.

Pour faire simple nous scindons notre approche de la façon suivante :

• L’expérimentation. Une expérimentation est le contexte dans lequel nous avons pu observer des comportements utilisateurs. Elle peut être de plusieurs natures : quali ou quanti (test U, étude Ad Hoc, analyse de parcours, questionnaire, analyse de performance, commentaire store…). Une expérimentation contient généralement plusieurs observations et elle est datée.
  ‍
• L’observation. Une observation est l’affirmation d’un comportement utilisateur qui a pu être observé dans le cadre d’une expérimentation. Elle peut être recueillie sous plusieurs formes, de manière plus ou moins synthétique, sous forme d’observation de l’usage de l’utilisateur, de verbatim, de synthèse… Elle est toujours rattachée à l’expérimentation d’où elle a été recueillie pour en assurer la traçabilité.
  ‍
• L’insight. Un insight est un enseignement vérifié, une vérité constatée, basée sur les motivations ou les difficultés rencontrées par nos utilisateurs. Il constitue la zone de collision entre plusieurs faits observés (il les corrobore) issus d’une ou de plusieurs expérimentations. Il doit être clair, concis et doit pouvoir déclencher une action. Une équipe doit pouvoir l’utiliser pour prendre les meilleures décisions et nourrir la roadmap (il ouvre le champ des solutions).
  ‍
• La priorisation. C’est notre apport à la théorie de l’Atomic Research. Dans cette phase, nous mesurons l’impact potentiel côté Produit et les prochaines étapes.
  ‍

Les 3 premiers éléments sont communs à la théorie de l’Atomic Research, le dernier constitue notre contribution à cette méthodologie pour la rendre encore plus actionnable côté Produit. Il remplace les “recommandations” que nous trouvons dans la théorie initiale. Le problème de la recommandation c’est qu’elle laisse la place au “pick and choose”, au biais de confirmation. Nous, nous priorisons directement : la base de connaissance utilisateur est à la racine de la conception de la roadmap Produit, et pas l’inverse. Ensuite, une fois priorisé nous entrons dans des ateliers de co-conception. Nous ne faisons donc pas de “recommandations”.

Justement, comment se passe cette phase de priorisation des enseignements ?

Nous utilisons trois critères : le “reach”, l’impact et la confiance.

• Le Reach. C’est la proportion d’utilisateurs qui sont touchés par une une problématique.
  ‍
• L’impact. C’est l’alignement avec nos objectifs business, les OKRs que nous nous sommes fixés. Répondre à un besoin utilisateur c’est bien, si en plus cela va dans le sens de notre stratégie, c’est mieux.
  ‍
• Confiance. C’est à la fois le nombre d’expérimentations dont sont issues les observations qui nourrissent les insights, et leur équilibre entre quali et quanti.
  ‍

Suivre cette méthodologie permet de vraiment tirer le maximum de sa Research. Il n’y a plus de défiance envers les expertises : chaque enseignement est traçable et on est capables de donner précisément le nombre d’expérimentations où il est apparu, ainsi que les observations desquelles il est tiré. C’est extrêmement puissant car elle nous permet de prioriser en fonction de convictions profondes partagées par tous et vérifiables.

Au regard de ton expérience du sujet, par où commencer quand on veut mettre en place la Product Atomic Research ?

Mon conseil là dessus, c’est de commencer petit. Il n’y a pas besoin de le déployer à l’ensemble des produits dans un premier temps. Il faut donc commencer par choisir le bon produit, la bonne opportunité, et ensuite utiliser cette “preuve” de réussite pour déployer.

Mon second conseil, c’est de faire son POC avec des gens qui sont convaincus. Dans ce genre d’initiative, il y a toujours des promoteurs et des détracteurs. Dans notre cas, nous avions identifié des PM qui avaient une appétence pour le sujet, et qui étaient donc partants pour réaliser l’exercice avec nous.

J’insiste sur ce point car on a toujours tendance à sous-évaluer la difficulté à changer les mentalités, les façons de faire. Il faut bien comprendre que quand on a été habitué à travailler pendant des mois avec des instituts traditionnels, à faire des restitutions d’une certaine manière, (par exemple en partageant des PowerPoints auprès de la direction générale), on ne change pas du jour au lendemain. Notamment parce qu’on a mis du temps à se faire une place, à identifier une méthode qui fonctionne… et tout à coup quelqu’un vient vous dire qu’on va tout changer !

Passer en Atomic Research c’est changer radicalement sa façon de travailler : on descend à une maille beaucoup plus fine, ce qui est génial pour le Produit car on est beaucoup plus précis et donc beaucoup plus facilement intégrables à la roadmap.

Je dirais qu’il faut s’attendre à devoir faire un petit “extra mile” au début : se charger soi-même de récupérer les supports de restitution et les documenter dans le repository par exemple. Ensuite, il va falloir entretenir le repository pour qu’il soit tout le temps à jour, ce qui n’est pas négligeable.

J’aime bien travailler avec des externes : ils apportent un regard externe, des idées nouvelles, une autre façon de faire…. cela permet d’être inventif.

Est-ce qu’il y a des outils en particulier que tu conseilles d’utiliser ?

Je pense qu’il ne faut pas se mettre de contrainte particulière, au contraire. Il faut faire avec ce qui convient le plus aux stakeholders, pour éviter une mauvaise réaction initiale.

Théoriquement, tu peux faire ton POC d’Atomic Research sur Excel, même si c’est pénible !

Une fois que la preuve est faite, là ça vaut le coup de se professionnaliser, et les outils sont légion :  Coda, Notion, Dovetail, Airtable, enjoyHQ, Glean.ly… La seule contrainte c’est d’utiliser des outils qui autorisent de l’hérédité entre les données. Plus que l’outil en lui-même, je pense qu’il ne faut pas négliger l’aspect formation des parties prenantes, car il n’y a rien de pire qu’un repository mal ou non alimenté. De notre côté, nous avons lancé l’Atomic Academy où nous enseignons tous les concepts de l’Atomic Research tous les 6 mois à l’ensemble des parties prenantes de l’entreprise. Ce n’est pas anodin car l’Atomic Research c’est toute une philosophie, qui nécessite vraiment de faire évoluer les mentalités.

Enfin, je recommanderais de suivre de près certaines tendances, notamment l’IA et l’automatisation. Ce sont des innovations qui vont nous permettre de synthétiser beaucoup plus rapidement nos insights et nous faire gagner du temps : expédition de certaines tâches, génération de synthèses, simulations de personas…

Aujourd’hui, un repository d’Atomic Research permet de gagner en confiance mais représente un investissement en temps conséquent. Tout ce qui permettra de faire gagner du temps est donc à regarder de près.