Quand et comment mettre en place son Research Repository ?

Le développement de la Research dans une entreprise crée rapidement des problématiques d'organisation, de traitement et de partage de la donnée collectée. Quand on souhaite "scaler" la Research, le sujet du Research Repository arrive donc assez rapidement.

C'est un sujet auquel Clement Schoofs, Designer & Researcher chez Digilityx, est régulièrement confronté chez les clients qu'il accompagne.

Avec nous, il est revenu sur les conditions à réunir avant de mettre en place son repository, et ce qui constitue pour lui les piliers d'un repository efficace.
‍

Sur l’évolution de la fonction de Researcher

Tactix : Tu te définis comme UX Researcher et Designer. Pourquoi distinguer ces deux notions ?

Clément : En réalité, il s’agit plus d’une précision que d’une distinction tant ces jobs sont liés. Nous entrons dans une ère de la spécialisation de l’expérience utilisateur. Avant, la tech était reine, mais aujourd’hui le code de qualité est devenu beaucoup plus accessible : ce n’est plus un différenciant mais un pré-requis. Par conséquent la différence se fait beaucoup plus sur l’expérience proposée et donc la connaissance des utilisateurs.

Cette spécialisation de l’UX elle se fait sur trois volets : la Research, l’UX Design et l’UI Design, le dénominateur commun étant l’empathie que ces trois fonctions ont pour les utilisateurs finaux. Et qui dit point commun dit également dans une certaine mesure compétences communes : j’estime qu’un Designer se doit d’avoir des notions de Research et qu’à l’inverse un Researcher, même s’il n’a pas la main sur la conception, doit comprendre le métier du Designer.

Moi, j’ai un peu cette double casquette Design et Research, disons que je suis un UX Designer très porté sur la Research !

Beaucoup d’entreprises affichent la “User Centricity” dans leurs valeurs… alors qu’elles ne sont pas du tout User Centric.

Sur la Research en agence de Design

Quel rôle joue la Research chez Digilityx ?

La Research est présente à trois niveaux chez nous.

Tout d’abord, de manière assez classique, on fait de la Research dans le cadre de nos projets de Design chez nos clients : on ne commence pas une phase de conception sans voir une connaissance a minima basique des utilisateurs finaux, qu’il s’agisse de projets internes ou B2C.

Ensuite, la Research sert également les autres expertises de l’agence. Je pense particulièrement au Growth / Marketing qui met en place des campagnes et qui a des besoins en Recherche pour avoir des informations sur les audiences à cibler.

Et enfin, nous disposons en interne d’un Start-Up Studio qui nous sert de terrain d’expérimentation pour des nouvelles approches en Research que nous venons tester sur nos projets, qu’il s’agisse d’un nouvel outil, d’un nouveau format de guide d’entretien…

Ce côté “bac à sable” nous permet d’expérimenter de nouvelles méthodologies, comme le journal de bord que vous proposez chez Tactix.
‍

Rencontres-tu encore des difficultés à “convaincre” tes clients qu’il faut faire de la Research ?

Bien sûr, il nous arrive encore de rencontrer des réticences chez nos clients à faire de la Research, et j’estime d’ailleurs que c’est notre rôle en tant que consultants de les tirer vers le haut car nous disposons d’une certaine légitimité liée à notre expertise.

Tout est une question de pédagogie.

Cela m’est arrivé récemment, sur un sujet plutôt innovant en plus : les cryptoactifs. Mon interlocuteur souhaitait se lancer directement dans une phase de conception : je lui ai expliqué que c’était risqué de concevoir sans une base de connaissances partagées minimale sur ses utilisateurs finaux. Là, ce qui fait la différence c’est de ne pas juste pointer des problèmes mais également d’apporter des solutions : dans ce cas, pour répondre aux contraintes de timing et de budget, on est partis sur un format guérilla pour récolter le minimum d’infos et d’insights nécessaire pour pouvoir démarrer.

Je pense que tout est une question de posture. Il faut savoir adapter sa Research aux contraintes de temps et de budget, et être intelligent dans sa façon de procéder : typiquement, une bonne stratégie à suivre est de commencer “petit” et de convaincre par l’exemple grâce aux premiers résultats.

Ensuite, l’argument qui fait mouche et que j’utilise souvent, c’est de dire que la Research va permettre d’aider les équipes en interne à donner du sens à ce qu’elles font, en leur permettant de s’appuyer sur des données tangibles (qu’elles soient quanti ou quali).
‍

Notes-tu une évolution dans la façon dont est perçue la Research ?

On entend beaucoup plus parler d’UX Research aujourd’hui !

C’est une bonne chose, mais il y a quand même un revers de la médaille.

Par exemple, nos interlocuteurs nous expliquent souvent qu’ils disposent déjà de personas. En creusant un peu, on se rend compte que ce sont des personas qui ont été établis par le Marketing, sans réelles données derrière (NDLR : relire notre article sur le sujet). Nous, ces persona, on ne les jette pas à la poubelle quand on arrive mais on les considère comme des proto-persona, une base de travail que l’on va venir valider ou invalider avec de la Research supplémentaire. Il faut être pédagogues pour ne pas froisser les égos, mais je trouve qu’avec l’importance croissante de la centricité-utilisateur dans la stratégie des entreprises, il est de plus en plus facile de faire accepter ses projets de Research en les présentant sous ce prisme.

De plus en plus d’entreprises mettent carrément la User centricity dans leurs valeurs : cela facilite grandement notre discours !

En tant que consultant, je dis toujours à mes clients que le premier bon conseil que je peux leur donner c’est : ne partez pas sur de la conception sans avoir une base de connaissances minimale des utilisateurs finaux.

Sur la nécessité (ou non) de mettre en place un Research repository
‍

Après la Research, le repository est un sujet qui revient de plus en plus : quel regard portes-tu sur cette tendance ?

Là pour le coup je suis un peu plus critique.

Dans notre métier, il y a beaucoup de termes qui ont été récupérés et utilisés à mauvais escient tout simplement parce qu’ils deviennent “à la mode”. Ça a été le cas pour le Design Thinking, le Design Sprint, et aujourd’hui c’est le Research Repository ou le Design System.

Soyons clairs : je suis persuadé de la pertinence de ces approches ! Mais ce sont des termes “qui brillent” et qui sont donc souvent vendus en conseil comme une sorte de baguette magique qui va résoudre tous les problèmes des clients. Cela ne sert à rien de mettre en place un repository s’il ne répond pas à un réel besoin et si ce n’est pas le bon moment pour l’entreprise.

Mettre en place un repository trop tôt, au mauvais stade de maturité, c’est une grossière erreur.

Justement, mettre en place un Repository représente un investissement conséquent, aussi bien en termes financiers qu’en capital humain.

Comment savoir si c’est le bon moment ?

Plus qu’un bon moment, je dirais que c’est la réunion d’un certain nombre de conditions.

Déjà, je pense qu’il faut avoir un “owner” de la Research, un responsable qui sera par extension le responsable du repository.

Ensuite, il faut que repository corresponde comme je le disais à un réel besoin, et pour cela le bon indicateur c’est le fait d’avoir plusieurs personnes en collaboration sur les mêmes projets impliquant de la Research. Pour ces personnes, le repository servira à centraliser les données, qu’il s’agisse des conclusions d’un test utilisateur ou d’un entretien par exemple. Le stade ultime, c’est quand un produit est transverse à plusieurs pays, avec des équipes dédiées dans ces différents pays. Là pour le coup le Research repository devient non seulement utile mais carrément nécessaire pour la collaboration et le partage des insights.

Cependant, limiter le repository à un outil de fluidification de la collaboration entre les équipes Design ou Research reviendrait à négliger une importante poche de valeur. C’est également un formidable outil pour toute l’organisation dans son ensemble : je pense notamment à la Tech à qui il peut offrir des éléments de contexte, aux Sales pour pousser des arguments de vente basés sur de la donnée tangible, au Support pour prendre conscience des problèmes d’usabilité rencontrés par les utilisateurs…

Le Repository est un excellent moyen de transversaliser le partage de la donnée, jusqu’à devenir la pierre angulaire de la user centricity dans l’entreprise.

Une fois ces conditions réunies, comment le mettre en place ?

Là aussi, mon conseil c’est de “start small” : un outil simple que les équipes utilisent peut-être déjà, un petit périmètre produit pour commencer,…

Rien ne sert de viser la Lune à très court terme. Bien au contraire. La pire chose qui puisse arriver c’est de réaliser un investissement conséquent et mettre en place quelque chose de disproportionné par rapport au niveau de maturité des équipes. Les gens vont entendre parler du repository, découvrir quelque chose de déjà gros et complexe et ne vont pas se l’approprier car ils auront eu une mauvaise expérience.
‍

Quelle est la recette d’un Research repository efficace ?

Il y a 3 piliers : qu’il soit utile, qu’il soit alimenté, et enfin qu’il soit utilisable.

L’utilité c’est ce dont nous venons de discuter : il n’y a pas besoin de mettre en place un repository si cela ne correspond pas à un réel besoin des équipes en interne.

Ensuite, l’alimentation du repository est liée à la quantité de projets de Research. J’ai coutume de dire que si on fait un questionnaire NPS par quarter, il n’y a probablement pas besoin de repository. Il faut que les équipes mettent régulièrement en places des projets (quels qu’ils soient : NPS, Personas, Test Utilisateurs,…) et qu’elles aient surtout la discipline de les logger dans le repository selon les règles préalablement établies et partagées par tous (structure, taxonomie,…). Récemment, j’ai échangé avec le Lead UX d’un grand groupe d’assurances qui me disait que son rêve le plus fou était que tous ses test utilisateurs soient tout simplement au même format…

Ça me permet de faire le lien avec le dernier point : l’utilisabilité. Je pense que c’est un vrai risque car il faut non seulement respecter les règles d’alimentation du repository, mais surtout faire en sorte qu’il soit compréhensible et accessible à tous afin qu’il soit utilisé.

Cette année j’ai travaillé pour un laboratoire pharmaceutique qui a mis en place un repository pour ses équipes Design afin de centraliser les enseignements des différents projets exploratoires et évaluatifs menés sur certaines pathologies, aussi bien du côté patient que du côté des professionnels de santé. Finalement, l’entreprise a choisi de racheter une start-up existante plutôt que de développer son projet en propre. Sans notre repository clair et organisé, comment les équipes de la start-up partenaire auraient-elles pu bénéficier des données collectées ? Je pense qu’elles auraient été perdues ou mises sur des slides qui n’auraient jamais été utilisées…

Un Repository qui n’est utilisé que par des Designers perd 80% de sa valeur

Tu mentionnes les échanges que tu as avec des Designers que tu mets en place pour rester au courant des dernières méthodologies, des bonnes pratiques… Quelles sont tes sources d’inspiration ?

Un terrain de jeu que je trouve incroyable, c’est LinkedIn. Personnellement, si on m’ajoute, j’accepte systématiquement et je vais même envoyer un petit message pour savoir de quoi on peut discuter, comment on peut s’entraider. Très souvent je propose à la personne qu’on discute de ses sujets pour lui apporter un regard neuf, mais très souvent elle m’apporte aussi plein de choses que je ne savais pas.

Ceci dit, je comprends tout à fait qu’on ne soit pas à l’aise à l’idée de prendre la parole en public sur les réseaux sociaux ou même d’envoyer des messages privés. Pour cela, je pense que simplement “suivre” sans forcément ajouter des gens qui prennent la parole est un bon premier pas. Les pays anglo-saxons ont un temps d’avance sur notre discipline (Tech, Design et Research), ils bénéficient d’un mindset et d’un écosystème propice. Je pense notamment à Debbie Levitt,  Vy Alechnavicius, Stéphane Cruchon ou encore Stéphanie Walter. S’abonner à ses personnes fait remonter leurs sujets dans votre fil, c’est du contenu de qualité tous les jours !

Et si vous n’avez pas le temps de faire votre propre curation, vous pouvez recevoir toutes les deux semaines dans votre inbox une curation des meilleurs contenus UX via la newsletter UX Curation by Digilityx !