Mettre la Research à la Table du CODIR

En tant que Lead User Researcher chez Designshot, Lisa répartit son temps entre l’accompagnement de ses clients dans leurs projets, le recrutement de Researchers, et les formations qu’elle dispense.

En parallèle, elle gère également une des plus grosses communautés françaises de Researchers via son Discord, où sont partagés chaque jour des retours d’expérience en contexte d’entreprise, des conseils, bonnes pratiques, évènements, et offres d’emploi à destination des Researchers.

Avec nous, elle revient sur l’importance de l’intégration de la Research à l’équipe Produit et de la structuration des Research Ops pour maximiser l’impact de la Recherche en interne.

‍

Tactix : Tu t’investis beaucoup pour la communauté des Researchers en France.  
Comment fais-tu pour leur apporter de la valeur ?

Lisa : Contrairement à beaucoup de Researchers, je n’ai pas eu de formation en sciences cognitives ou en Design. J’ai fait une école de commerce puis un master en communication digitale où la Recherche n’était pas du tout abordée.

J’ai donc appris mon métier sur le terrain, d’abord chez Axance, qui était à l’époque une agence pionnière en Recherche Utilisateur, puis chez IDEAN et enfin Designshot.

Mon constat, c'est que nous rencontrons aujourd’hui en tant que Researchers des problématiques de plus en plus stratégiques et organisationnelles, et qu’il n’y a pas pour autant de partage de retours d’expérience ou de bonnes pratiques entre nous. C’est comme ça que l’idée de rassembler des Researchers sur un Discord commun est née, avec pour objectif de traiter de tous les sujets liés à nos projets de Recherche : quels outils utiliser, quelles compétences développer, quels process mettre en place en fonction de la taille de l’organisation…

Aujourd’hui en France, notre communauté est de 500 Designers (UXR, Designer Produit, Head of Design,…) et j’anime en parallèle un club regroupant une vingtaine de Head of Research / UXR seniors. Ceci nous permet d’échanger sur des sujets parfois très concrets comme l’utilisation d’un outil ou le nombre de participants à convier à un test, mais aussi des sujets plus stratégiques comme des bonnes pratiques d’intégration de la Research à l’équipe Produit ou la structuration des Research Ops par exemple.

‍

La collaboration avec l’équipe Produit est une problématique récurrente.
Comment traites-tu ce sujet chez tes clients ?

Je pense qu’il ne faut pas “s’enfermer” dans la Research, et pour ça la clé c’est de mettre en place des rituels, des ateliers de partage et de co-construction réguliers avec l’équipe Produit. Cela vient peut-être de mon parcours en tant que chef de projet polyvalent avant de me spécialiser dans la Research, mais ma vision est qu’on ne peut pas avoir une approche vraiment user-centric tout au long du processus de Design en faisant de la Research de manière silotée.

Pour ça, il faut être capable de comprendre et de travailler avec ses contreparties, qu’elles viennent du Design, du Produit ou du Marketing. À titre personnel, je ne maîtrise pas les outils et logiciels de Design par exemple, mais je suis capable en tant que Researcher de challenger des Designers sur les parcours produit, de les accompagner dans leurs réflexions,…

Cet état d’esprit est très important car c’est ce qui nous permet de ne pas être juste considérés comme une source d’informations, mais comme un “cerveau en plus” totalement intégré au processus de Design. Après tout, c’est ça le Design Thinking : nous sommes une équipe pluridisciplinaire et chacun est là pour apporter son expertise.

Notre enjeu à nous en tant que Researchers c’est donc de nous intéresser au quotidien des Designers afin de transformer des enseignements que nous identifions en éléments actionnables de leur côté.

Cependant, pour que cela fonctionne, il faut que ça soit une relation qui aille dans les deux sens : c’est aussi le rôle du Produit d’associer la Research à ses rituels propres, d’expliquer quels sont les projets prioritaires à venir pour eux. Avec ces informations, un Researcher est capable de voir comment il peut les aider au mieux, et optimiser ses ressources pour traiter un maximum de sujets. Au début c’est forcément un petit peu politique : cela va dépendre de ce que pensent le Head of Design et le CPO de la Recherche, et des moyens qu’ils vont lui donner pour avancer. Mais dès que l’on donne l’opportunité à un Researcher de travailler main dans la main avec la Data et le Design, on a très vite des premiers résultats qui vont permettre à la Recherche de faire ses preuves et d’accompagner la prise de décision sur le service / produit.

Il ne faut pas "s'enfermer" dans la Research [...]. On ne peut pas avoir une approche vraiment user-centric tout au long du processus de Design en faisant de la Research de manière silotée.

‍

Qu’est ce qui manque à la Recherche aujourd’hui pour avoir cette collaboration fructueuse ?

Aujourd’hui, je pense que la Research est trop quali, et moi la première !

Ce qui manque vraiment selon moi, c’est le lien avec la Data pour avoir une vraie articulation quanti/quali. Pour ça je pense que la clé c’est d’avoir une équipe “transverse” Research & Data - et peut être même Design - pour pouvoir faire de la Recherche en continu.

Le deuxième élément sur lequel il y a encore des choses à améliorer selon moi c’est le point de rupture qui existe encore au niveau du partage des insights : que vont en faire les équipes Produit après ?

En plus de récolter de la matière, il faut être capable de la transformer et accompagner le Design et le Produit pour faire de ces insights des solutions pour eux.

Nous ne pouvons pas nous contenter d’avoir un repository en interne pour “diffuser la Recherche”, en espérant que les équipes viendront y piocher ce dont elles ont besoin. Ce serait comme mettre à la disposition de l’entreprise une grande bibliothèque avec énormément de ressources potentiellement intéressantes : s’il n’y a pas de bibliothécaire pour être dirigé, conseillé et orienté… c’est inefficace.

Pour moi, dans une organisation réellement user-centric, il doit y avoir autour de la table du CODIR le Produit, la Tech, le Design et la Recherche.

‍

Que se passe-t-il une fois qu’on a franchi cette première étape ?

Très rapidement, on se rend compte que la Recherche c’est non seulement un réel besoin pour les entreprises, mais c’est surtout un vrai métier, une vraie expertise : ce n’est pas juste parce que j’interroge des utilisateurs que je vais en tirer et utiliser des résultats correctement.

Il y a une limite à l’approche “tant qu’on fait de la Recherche c’est bien”, qui est très vite atteinte. À partir de ce point, on passe à une approche du type “faisons de la Recherche correctement pour être efficaces” ce qui nous force à mettre la Recherche au même niveau stratégique que le Design commence à avoir et que le Produit a depuis toujours.

Pour moi, dans une organisation réellement user-centric, il doit y avoir autour de la table du CODIR le Produit, la Tech, le Design et la Recherche.

Au cours de cette dernière décennie, c’est le Design qui a eu du mal à se faire entendre, qui a dû faire ses preuves et montrer son impact ainsi que son savoir-faire méthodologique pour être accepté au même niveau que le Produit et la Tech. Maintenant, c’est à nous en tant que Researchers de nous faire entendre pour arriver à ce niveau stratégique.

‍

Tu mentionnes le partage de la Recherche en interne, sujet qui devient rapidement clé quand une entreprise commencer à s’organiser en Research. Comment bien structurer les Research Ops ?

Il faut repartir des objectifs organisationnels des Research Ops : identifier toutes les sources de connaissance utilisateur au sein de l’entreprise et donner accès à tout le monde à cette connaissance. Ensuite, il faut voir comment cela se décline dans une entreprise en particulier.

La structuration des ReOps va donc fortement dépendre de l’organisation et de la maturité de l’entreprise : qui gère la Research ? A-t-on des researchers à proprement parler ? Ou est-ce le Design qui s’en occupe ?

Une fois que l’on a “l’owner” du sujet, il faut identifier tous les points d’adhérence de la Research avec les autres départements, et les rencontrer pour comprendre comment on peut travailler ensemble. C’est là que l'on se rend vite compte que la Research va impliquer beaucoup de personnes en interne : le recrutement des participants va passer par le Marketing, le stockage des données va concerner le CDO, les récompenses seront à gérer avec les Achats…

Et bien sûr surtout aller voir les équipes Produit, Design et Data pour comprendre ce dont elles ont besoin, à quelle moment elles souhaitent faire de la Recherche et identifier la meilleure manière de s’y intégrer.

Cette phase d’état des lieux est extrêmement importante car c’est là qu’on se rend compte des différences d’opinion sur la Research qu’il peut y avoir entre le CPO et le Head of Design, et la réalité des problèmes que leurs équipes rencontrent sur le terrain.

‍

À quoi faut-il faire particulièrement attention ?

Les Research Ops vont énormément dépendre de l’organisation de l’entreprise ! Aujourd’hui en fonction de l’organisation il va y avoir différents profils qui font de la Research : des Researchers purs, des Designers, des Product Managers…

Une premier point d’attention porte donc sur la porosité entre les Ops des différents départements, notamment entre les Design Ops, Product Ops et les Research Ops. La frontière est tellement fine entre les deux que pour bien faire des Research Ops il est capital de bien prendre en comptes les usages et les besoins des Designers.

Ensuite, un second point concerne le niveau de séniorité des Research Ops. Cela va bien sûr dépendre là encore de la taille de l’organisation, mais un Researcher Junior isolé ne va pas pouvoir cumuler ses activités de Recherche, participer à l’évangélisation de la Recherche en interne, et gérer les problématiques organisationnelles - qu’il ne maîtrise de toute façon pas.

Pour avoir un réel impact en Research Ops, il faut avoir avoir un niveau d’expérience minimum nécessaire pour pouvoir bien appréhender l’entreprise dans toute sa complexité, avoir une certaine connaissance du marché, et être capable de faire des arbitrages comme par exemple choisir entre recourir à des panelistes ou créer en interne une communauté de user testeurs.

‍

article initialement publié sur le blog de Tactix