Atomic Research (AR): Table Ronde #2
Introduction
Après une première Table Ronde sur l’Atomic Research riche en enseignements, nous nous sommes aperçus qu’un grand nombre de sujets restaient à aborder.
Pour y répondre, nous avons réussi à constituer une seconde Table Ronde composée de 6 expert.e.s.
Voici les thèmes abordés lors de cette deuxième Table Ronde :
- La différence entre l’Atomic Research et un Repository ;
- La taille de l’entreprise et le déploiement de l’Atomic Research ;
- La gestion de la gouvernance du Repository ;
- La gestion de l’obsolescence des données présentes dans le Repository ;
- Les utilisateurs du Repository et l’utilisation des données ;
Pour celles et ceux qui n’ont pas encore pris connaissance de la première Table Ronde, afin de comprendre ce qu’est l’Atomic Research et de découvrir comment nos expert.e.s l’ont intégré dans leur entreprise, voici le lien de son résumé dans lequel vous pourrez accéder à la vidéo YouTube.
Nous espérons que cette deuxième Table Ronde vous plaira. Très bonne lecture à toutes et à tous 🙌
Les expert.e.s
Vidéo conférence de la Table Ronde
Synthèse de la Table Ronde
Première question posée aux expert.e.s : Quelle est la différence entre l’Atomic Research et un Repository ?
1- L’Atomic Research, une méthode de recherche
L’Atomic Research est une méthode de recherche qui va permettre de collecter et analyser de la donnée issue de la Recherche Utilisateur. L’idée étant de partir d’une étude pour collecter des Faits permettant de générer dans un premier temps des Insights et dans un second des Recommandations. Un des intérêts de l’Atomic Research est de pouvoir remonter des Recommandations jusqu’aux Faits afin de s’en servir de preuves pour appuyer les décisions prises.
2- Le Repository, un lieu de stockage
Le Repository est un lieu de stockage de la donnée issue de la recherche utilisateur. Ce lieu unique permet de centraliser, organiser, exploiter, analyser, et partager la connaissance utilisateur acquise lors des études réalisées. Centraliser la connaissance utilisateur permet d’éviter de la perdre, notamment quand celle-ci est dispersée sur des Drives, Notion, fichiers Word, Miro etc.
L’Atomic Research est une méthode de recherche, le Repository est un lieu de stockage de la donnée.
Domitille Aulagnier-Collin
3- L’Atomic Research et le Repository, un duo de choc
Indépendamment du fait que l’Atomic Research soit une méthode et que le Repository soit un lieu de stockage, ils peuvent fonctionner ensemble. Quand la finalité de l’Atomic Research se trouve dans un Repository, sa puissance est décuplée.
Il est possible, au sein du Repository, d’analyser les Faits récoltés lors d’une étude afin de générer des Insights et des Recommandation. Ainsi que remonter le fil d’une Recommandation dans le but de comprendre sa logique.
Deuxième question posée aux expert.e.s : À partir de quelle taille est-il utile d’adopter l’Atomic Research (la méthode) ?
1- Plus une histoire de configuration qu’une histoire de taille
Plutôt que de se baser sur la taille de l’entreprise, on va plutôt se concentrer sur sa configuration. À partir du moment où il y a un problème de communication, qu’il y a une distance entre les métiers et que le niveau d’information de chacun devient trop hétérogène, il est intéressant de se poser la question de mettre en place l’Atomic Research.
2- Plus une histoire de volume de données qu’une histoire de taille
Mis à part la configuration de l’entreprise, il est intéressant de se baser sur le volume de données. À partir du moment où les études sont régulières et que les données récoltées sont conséquentes, l’utilisation d’un Repository ou une approche d’Atomic Research peut être justifiée.
La question est plutôt “quel volume de données vous avez qui justifierait l’utilisation d’une base de connaissance ou une approche Atomic Research”
Romain Dechamps
3- Plus une histoire de maturité qu’une histoire de taille
Avant d’aborder une démarche d’Atomic Research et par extension vouloir déployer un Repository, il faut prendre en compte l’environnement dans lequel on se situe et en jauger sa maturité.
Il peut être intéressant de se poser certaines questions :
- Est-ce que l’organisation est prête à accueillir ce découpage et par extension le Repository ?
- Comment la donnée va être traitée ?
- Est-ce que la donnée sert seulement à avoir des feedbacks ponctuels qui seront traités immédiatement et qui deviendront rapidement obsolètes ?
- Est-ce que sa mise en place permettrait une meilleure collaboration en interne ?
- Est-ce que sa mise en place permettrait de désiloter les équipes ?
Troisième question posée aux expert.e.s : Comment est gérée la gouvernance du Repository ?
1- Un Repository géré par les User Researcher afin de garder une cohérence des propriétés des données qui y sont présentes
Du côté de Guillaume Louvel, la gouvernance du Repository est entre les mains des User Researcher. C’est aussi les User Researcher qui s’occupent d’attribuer des propriétés aux études, de tagger les Insights et de tagger les livrables (test utilisateurs, interviews, Hotjar…). Ce qui permet de s’assurer de la cohérence des propriétés des données présentes dans le Repository.
Derrière chaque étude on récupère des insights et on garde la main sur leur taguage afin de s’assurer de la cohérence de nos données.
Guillaume Louvel
Des règles de syntaxe doivent être mises en place, notamment quand des documents externes sont récupérés puis ajoutés au Repository. Ce qui rentre dans le Repository va être utilisé par des personnes qui en sont extérieures, il faut donc homogénéiser l’écriture afin d’en faciliter l’utilisation.
2- Un.e seul.e administrateur.trice pouvant éditer des tags et des accès limités pour éditer la donnée
Aujourd’hui, voilà comment fonctionne le Repository de Mathilde Gautier chez Payfit :
Un.e seul.e administrateur.trice est en mesure d’éditer les tags et propriétés qui vont être utilisés par les utilisateur.trice.s du Repository. Ce premier filtre sert à s’assurer de ne pas impacter l’expérience des utilisateur.trice.s du Repository.
On essaye de limiter la casse en ayant un seul admin qui est en mesure d’éditer des tags et des propriétés qui vont être utilisés par tous les utilisateurs
Mathilde Gautier
Afin de ne pas diffuser de mauvaises données et perdre la confiance de ceux qui utilisent le Repository, le nombre de personnes pouvant éditer de la donnée est limité. Grâce au nombre limité de personne pouvant éditer la donnée, chaque personne peut être formée individuellement sur la manière dont doit être manipulée l’édition des données.
Demain, dans un monde idéal, voilà comment il pourrait fonctionner :
Comme pour le maintien d’un Design System, il faudrait que le Repository ait un owner clair et définit. Cet owner serait garant du système, il pourrait s’aligner avec les Product Ops pour savoir comment évolue leur classification afin de garder une cohérence d’ensemble. Des points récurrents avec les utilisateur.trice.s du Repository pourraient être mis en place afin de s’assurer qu’il soit à jour : supprimer des éléments jugés obsolètes, se concerter sur des évolutions, se mettre d’accord sur la définition de tags…
Attention, il faut néanmoins prendre en compte le temps que prend la mise en place et le maintien d’un Repository.
3- Un Repository à la main des User Researcher et des frontières poreuses avec d’autres outils
Chez OpenClassroom, représentée par Mathieu Klein, le Repository est à la main des User Researcher et les données qui y entrent sont aussi récupérées via des intégrations.
Une des problématiques est que le Repository rentre en concurrence avec d’autres outils comme Product Board du côté des Product Manager. Cela peut amener à une perte de temps car les données vont parfois être traitées deux fois, notamment lorsqu’on parle de tickets Zendesk ou de NPS.
Une forme de collaboration ou de frontière est en train de se créer et des questions se posent, notamment sur les différent.e.s owners, sur la manière dont la donnée est traitée et sur la manière dont on peut la mettre à disposition.
4- Un modèle cible qui privilégie les rôles plutôt que les postes
Pour Domitille, le modèle idéal, pensé avec Martin Dujol, comprend différents rôles :
Les Responsables Qualité sont les User Researchers et UX Designers qui ont un rôle central dans le Repository. Ils vont être à même de conduire et analyser des études et sont en quelque sorte responsables de la qualité des données présentes dans le Repository.
Les Reporters vont collecter de la donnée via différentes sources, que ce soit en ligne ou sur le terrain, ils alimentent le travail des Researcher et Designers.
Le/la Modérateur.trice ou Owner est la personne à qui il est possible de faire référence s’il se passe quoi que ce soit sur le Repository (faire sauter un champ, retrouver un tag…). C’est à la fois l’owner et l’administrateur d’accès. Ce rôle est capital pour assurer le bon fonctionnement du Repository.
Le Viewer va aller chercher des informations dans le Repository, il n’interagit pas avec et ne l’alimente pas.
5- Le Repository vu comme un produit et des accès donnés aux parties prenantes
Chez Mathilde Philippe, les personnes qui ont accès au Repository sont des personnes qui sont amenées à faire ou à participer à de la recherche utilisateurs. Ils vont avoir un rôle de garant de la donnée. L’aspect de formation à l’utilisation du Repository est important.
On n’est pas forcement nombreux mais en tous cas les personnes qui y ont accès sont des personnes qui sont amenées à faire ou participer à de la recherche
Mathilde Philippe
Le Repository est vu comme un produit qui va être amené à évoluer et à grossir. Il faut que chaque utilisateur.trice sache quoi faire s’il y a un problème et qu’il y ait un owner qui soit responsable de sa bonne évolution.
Quatrième question posée aux expert.e.s : Comment est gérée l’obsolescence des données présentes dans le Repository ?
Il y a un assez grand nombre de critères qui permettent de gérer l’obsolescence des données présentes dans le Repository. Ces critères vont être détaillés ci-dessous. Il est important de noter que ces critères ne sont pas forcément indépendants les uns des autres mais peuvent être associés afin de former un Quality Score permettant d’avoir un jugement plus juste.
1- L’ancienneté de la donnée est prise en compte
L’ancienneté de la donnée peut être un bon indicateur pour gérer l’obsolescence des données présentes dans le Repository. Plus la durée des Sources, des Faits et des Insights sont éloignés dans le temps, moins il y a de confiance.
Plus la durée des sources et des faits sont éloignés dans le temps moins la confiance est bonne.
Mathieu Klein
Pour gérer l’ancienneté de la donnée présente dans le Repository, il est possible de dater chaque donnée afin qu’un score lui soit attribué ou qu’une alerte soit déclenchée. Ce score ou cette alerte vont permettre au Researcher de se demander si l’Insight est toujours d’actualité et s’il faut ou non refaire une étude pour s’en assurer.
La datation des données permet aussi de pouvoir filtrer ou d’éliminer les plus anciennes lorsque les utilisateur.trice.s du Repository travaillent dedans.
2- La source des données est prise en compte
La source des données qui figure dans le Repository a son importance lorsqu’il s’agit de juger si les données sont obsolètes.
Il peut être intéressant de se demander
- Qui a observé la donnée ?
- Combien d’études et de Faits viennent alimenter un même Insight ?
Vous l’aurez compris, si la donnée vient d’un bruit de couloir et que peu d’études et de Faits convergent vers un Insight, il peut y avoir des chances que la donnée soit obsolète.
3- Le statut de l’Insight est pris en compte
Afin de savoir si la donnée est obsolète, il est possible de lui attribuer un statut, voici deux exemples de statuts :
- En cours
- Traité/fixé
À partir du moment où le statut est considéré comme Traité/Fixé, on peut penser que la donnée est obsolète ou à re-tester.
4- Deux catégories d’Insights et deux durées de vies différentes
On note deux types d’Insight qui ne vont pas devenir obsolètes en même temps.
Les Insight centrés produits/interface, qui proviennent généralement de Tests Utilisateurs et sur lesquels on peut agir rapidement vont avoir une durée de vie assez courte. En effet, si l’Insight est traité directement après des Tests Utilisateurs et que la modification est approuvée via de nouveaux Tests Utilisateurs, alors il peut être jugé obsolète.
Les Insight dits de “Discovery”, qui proviennent le plus souvent d’entretiens utilisateurs ou d’observations terrain ont généralement une durée de vie plus longue. En effet, ils ont un comportement stable dans le temps
Pour gagner du temps, il est possible de ne pas rentrer dans le Repository les données qui ont une durée de vie très courte pour se concentrer sur des données plus stables qui vont durer dans le temps.
5- Il n’y a pas que les données qui peuvent devenir obsolètes, le système en lui-même aussi peut le devenir
L’utilisation d’un Repository semble assez récente, ce qui veut dire qu’à force d’apprendre et itérer sur son fonctionnement, le setup mis en place initialement peut ne plus fonctionner.
Par exemple, la quantité de données présente dans le Repository, qui ne fait que croître, peut rendre l’outil ingérable. Tout comme l’évolution de la manière dont on veut traiter la donnée : si on décide un jour de vouloir transférer rapidement des données d’un outil à l’autre et que l’outil choisi ne le permet pas, le système peut alors devenir obsolète.
Cinquième question posée aux expert.e.s : Quelles sont les personnes qui vont consommer les données du Repository et comment s’assurer qu’elles soient correctement consommées ?
1- Définir qui va consommer les données du Repository
Afin de donner l’accès du Repository aux bonnes personnes, il est important de se demander à quoi et à qui peut servir ce Repository. Est-ce que c’est un endroit seulement destiné à l’analyse des données ? À l’analyse et à la collecte ? En l’état et dans un monde idéal, à qui peuvent servir ces données ?
2- Les User Researchers, Designer et de manière plus large les équipes produit
Les Users Reseachers et Designers vont consommer les données du Repository, c’est d’ailleurs eux qui vont rendre ces données consommables grâce à leur analyse des données brutes.
Les équipes produits vont aussi consommer les données du Repository et vont généralement se servir des données qui y sont présentes pour aider la prise de décision.
3- Onboarder les nouveaux arrivants
Le Repository est un bon moyen pour Onboarder les nouveaux arrivants. Quand quelqu’un arrive sur un sujet très spécifique, le plonger dans le Repository et le mettre face à des verbatims peut s’avérer plus puissant que de présenter le projet à l’oral ou de donner un doc Notion.
4- Dans un monde idéal, donner l’accès au plus grand nombre
Afin de diffuser la connaissance utilisateurs au plus grand nombre, notamment à ceux qui sont curieux, qui ont entendu parler d’un sujet qui les intéresse et qui se posent des questions, ne pas restreindre l’accès aux Researchers, Designer et équipes produits peut faire du Repository un outil extrêmement puissant.
Cela nécessite de donner les bons accès aux bons utilisateurs et de bien filtrer les données disponibles en fonction des types d’accès. Le niveau de proximité du Repository devra être variable et chaque utilisateur n’aura pas la même liberté d’action.
Par exemple, il est possible de donner accès au plus grand nombre, en “view only”, aux Insight en permettant un système de recherche et de filtre approprié. Ne proposer que les Insights et non les Facts permet de faciliter la consommation des données du Repository en réduisant son nombre.
Dans l’idée de faire de la “Research as a Service”, toute personne dans l’entreprise qui veut aller chercher de l’information sur un sujet peut le faire d’elle même.
5- Donner l’accès au plus grand nombre n’est pas sans difficultés
Faire en sorte que toute personne dans l’entreprise puisse faire des recherches dans le Repository et en ressortir en ayant trouvé les bonnes informations n’est pas une mince affaire. Il est difficile de structurer le Repository pour qu’il soit compréhensible par toutes et tous, tout comme accompagner les utilisateur.trice.s pour qu’ils arrivent à trouver exactement ce qu’ils cherchent et avec le bon niveau de granularité.
Q&A 1 : Est-ce qu’on peut en savoir un peu plus sur le Quality Score utilisé dans le Repository ?
Le Quality Score va dépendre des critères de qualité que les User Researchers vont mettre derrière leurs données.
Par exemple, voilà comment s’organise Romain Dechamps :
Son Quality Score va de 1 à 4. À partir de 3/4 il est possible d’avoir confiance en sa qualité. Quand le Quality Score est de 1 ou 2, la question de refaire une étude plus spécifique se pose.
Les critères pris en compte pour composer cette note sont les suivants :
- Si la donnée est internationale ou seulement nationale
- Le degré de confiance dans la source d’où provient la donnée
- Le nombre d’occurrence
“Maintenant grâce à cette table ronde je me dis que la date est aussi intéressante à renseigner”
Romain Dechamps
Q&A 2 : Où est-ce que la donnée est récupérée ?
Pour cette question, on peut identifier deux tendances assez opposées. Certains vont restreindre les canaux d’entrée de la donnée alors que d’autres essayent de brancher un maximum de tuyaux pour faire entrer un maximum de Facts dans le Repository.
1- Certains vont restreindre les canaux d’entrée
En raison d’une forte exigence d’homogénéité de la donnée qui entre dans le Repository, certains vont restreindre les canaux et les personnes qui peuvent alimenter le Repository.
Cette exigence n’est pas compatible avec le temps que prend le taguage des données qui entrent dans le Repository. En effet, il peut être difficile de demander à des métiers qui n’ont pas forcément les mêmes préoccupations que les Researchers de prendre ce temps pour homogénéiser la donnée.
Ça prend du temps et il y a plein d’équipes à qui on ne peut pas imposer une surcharge de travail
Mathilde Gautier
Ceux qui entrent la donnée dans le Repository y sont formés et si les données ne sont pas conformes aux attentes définies, les personnes garantes de cette homogénéité seront là pour leur expliquer que la donnée est importante et que son traitement est capital. Plus il y a de personnes qui peuvent entrer des données dans le Repository, plus cela est difficile à faire.
2- D’autres essayent de brancher un maximum de tuyaux pour faire entrer un maximum de Facts
Afin de récupérer le maximum de Facts, certains vont multiplier les canaux d’où provient la donnée, cela dans le but d’identifier un maximum d’occurrence, quitte à ne pas avoir un œil sur tout ce qui rentre.
Une fois que la donnée est entrée dans le Repository, afin de l’organiser et la structurer, notamment quand elle ne provient pas directement des Researchers, une phase de pré-taguage est faite. L’idée étant d’identifier des patterns de taguage qui vont permettre aux Researchers de retrouver la donnée. Ex : taguer au niveau de la source; taguer au niveau du contenu.
Q&A 3 : Est-ce que vous continuez à faire des rapports pour communiquer et synthétiser la connaissance du Respository ?
Aujourd’hui, ce qui ressort, c’est que les présentations classiques faites de slides sont toujours d’actualité. Néanmoins, certaines personnes vont d’elles-mêmes chercher des informations dans le Repository.
1- Des rapports encore réalisés à l’aide de slides
Les rapports d’étude se communiquent la plupart du temps via des présentations classiques faites de slides. Les données présentes dans le Repository peuvent être très verbeuses et non visuelles et certains trouvent qu’il est plus facile de communiquer via un support visuel.
2- Possibilité d’aller chercher de manière autonome des informations dans le Repository
Le Repository n’est pas fermé et l’idée est aussi de permettre aux parties prenantes d’aller chercher des informations de manière autonome dans le Repository. Les personnes qui vont aller chercher d’elles-mêmes ces informations auront généralement un rôle plus opérationnel comme les équipes produit.
Q&A 4 : Que faites-vous des Insights traités ?
1- Des Insights tagués et résolus qui servent de KPI
Les Insights obsolètes et tagués comme traités peuvent servir d’indicateur de performance de la User Research et de l’UX en général.
Mesurer les performances de la User Research et de l’UX en général peut permettre aux équipes d’appuyer certains points, notamment quand il s’agit d’accélérer la voilure ou de défendre la pratique.
Conclusion :
L’ Atomic Research est une démarche constituée de nombreux outils et principes. Le Repository est un outil de cette démarche. Néanmoins il peut être utilisé en dehors.
Construire un Repository rapidement et quelle que soit la taille de l’entreprise semble être une bonne idée afin de conserver la donnée issue de la Recherche Utilisateur.
Néanmoins, tant que ces données sont diffusées correctement dans l’entreprise, la mise en place de l’Atomic Research ne semble pas nécessaire.
En effet, l’Atomic Research semble être un processus coûteux (ressources, temps, argent) qui aura un effet lorsque vous sentirez que les décisions ne sont plus accompagnées par la Recherche Utilisateur.
La mise en place d’un tel processus peut mener à la gestion d’un véritable outil interne avec ses règles, ses équipes et ses mises à jour. De plus, la mise en place se fera de façon itérative et sa gestion devra être rythmée par des rituels afin de maintenir sa qualité dans le temps.
L’outil ne remplace pas le travail effectué aujourd’hui. Bien que la donnée soit disponible en ligne, cela reste illisible ou inaccessible pour beaucoup. Il faudra donc dépenser de l’énergie pour le présenter, l’évangéliser. Les présentations slide restent d’ailleurs nécessaires.
Il faut bénéficier de temps et de confiance de la part de son entreprise pour déployer correctement l’outil (le Repository) et l’ensemble de l’approche.
