Faire de la Research sans sacrifier son time-to-market : mission impossible ?

Tactix : Après plusieurs expériences en tant que Lead Research, tu es aujourd’hui Head of Design chez eXalt…
‍
En quoi cet historique impacte-t-il ton approche du Design aujourd'hui ?

Chloé : Je ne vais pas te mentir, mon parcours de Researcher influence énormément la façon dont je travaille aujourd’hui !

Je viens des sciences sociales : à la base, je suis socio-anthropologue et ergonome cognitif de formation. En arrivant dans le monde professionnel, je me suis dit que comprendre comment l’humain fonctionnait c’était bien, mais que comprendre comment transformer son environnement afin de lui proposer des solutions adaptées c’était mieux; avec toujours cette subtilité de comprendre ce qu’il veut, et non pas ce qu’il dit qu’il veut.

Ce que j’ai connu en tant que sociologue des usages et ergonome IHM dans l’industrie, c’est ce qu’on appelle aujourd’hui l’UX Research dans le monde des start-ups ou des SaaS par exemple.

La principale différence selon moi, c’est le “niveau de Recherche attendu” et le time-to-market. Quand j’ai débuté en tant que sociologue / ergonome, un test utilisateur durait entre 1 et 3 mois de traitement. Quand j’ai évolué vers la Research telle qu’on en parle aujourd’hui, on m’a dit : “Tu veux faire un test ? Pas de problème, on voudrait les résultats dans 10 jours” [rires].

Le paradigme a donc totalement changé : comment adapter les méthodologies de Research à ces nouvelles contraintes business? Comment passer d’une approche perfectionniste où chaque micro-interaction est analysée, à une approche plus orientée résultats ?

De mon point de vue, le marché s’est aujourd’hui polarisé entre ces deux façons de faire : d’un côté la Recherche approfondie, qu’on pourrait qualifier de traditionnelle, et de l’autre ce que j’appellerais la “Lean Research”, c’est à dire la Research adaptée aux entreprises ayant un fonctionnement agile.

Moi j’ai la chance d’avoir connu les deux et ça me permet de bien voir la complémentarité entre ces deux approches dans ce que je propose à mes clients : des Product Designers full stack ayant des compétences en Research et qui sont donc capables d’en faire de manière ponctuelle dans le cadre de leurs travaux, et de l’autre des “vrais” Researchers qui vont mener des travaux d’envergures, généralement plus en amont du processus de design.

Pour devenir un Designer full stack, regarder un tutoriel sur la Research ou avoir suivi un module sur les entretiens ne suffit pas : il faut avoir du recul, avoir conscience des biais que l’on peut créer soi-même sans s’en rendre compte.

Comment fais-tu pour t’assurer que les Designers que tu encadres font de la Research “dans les règles de l’art” ?

En tant que manager, j’ai la chance d’encadrer des Product Designers qui sont intéressés par la Research. Cependant il faut bien comprendre que ce n’est pas leur coeur de métier, toute l’interrogation réside donc dans le fait de leur donner suffisamment de bonnes pratiques pour répondre à leurs besoins et aux attendus côté client.

Attention, il ne s’agit pas ici de faire de la Research en mode “Quick & Dirty” car cela peut être plus dangereux qu’autre chose, mais plutôt en mode “Quick & Clean”.

Cela nécessite donc d’avoir l’expertise d’un “vrai” Researcher pour templatiser au maximum les phases de Recherche classiques (protocoles, questionnaires,…) : cela permet aux Designers d’aller piocher ce dont ils ont besoin dans le Research toolkit, de s’en inspirer, de l’adapter en fonction de leurs contraintes et in fine d’aller plus vite.

Pour ne pas faire de concessions sur la qualité, il faut aussi s’organiser et pour cela je m’inspire beaucoup de ce que font les développeurs dans leur fonctionnement en sprints. Je préconise de sanctuariser du temps pour la Research : par exemple si la roadmap est en six sprints, on va dédier un sprint à la Recherche; ou sur chaque sprint, bloquer un ou deux jours uniquement pour faire de la recherche. Les deux cumulés c’est encore mieux !

Le contenu de ces journées dédiées à la Research va varier : en début de projet on va être plutôt sur des études d’usage et du benchmark, ensuite des ateliers de co-création, puis du test de concepts, jusqu’aux tests U finaux.

Ce fonctionnement nous permet de faire de la Recherche en continu durant tous les sprints, et en termes de discours commercial le fait de garder un jour par semaine pour “rencontrer les utilisateurs” s’entend assez bien !

Faire de la Research en mode “Quick & Dirty” n’est bon pour personne : ni pour les Designers, ni pour nos clients, et encore moins pour la Research en elle-même !

Puisque nous parlons de discours, comment “vendre” de la Research à ses parties prenantes quand on est Designer ?

Comme toujours, cela va dépendre du niveau de connaissance de nos interlocuteurs, mais je dirais que la première chose c’est d’arriver à sortir de l’image que la Research va forcément faire déraper le time to market.

Pour cela le discours que j’ai avec mes clients est simple : plus nous connaitrons notre cible, plus nous serons capables d’en comprendre les besoins et de développer une solution qui soit vraiment adaptée. Donc oui, on va investir du temps et des ressources sur la partie Design & Research, mais derrière nos développeurs ne feront qu’un seul développement (NDLR : voir l'interview d'Emmanuelle Savarit sur le sujet).

Un autre argument qui marche bien en ce moment c’est de surfer sur la tendance de l’éco-conception. La première règle quand on veut faire de l’éco-conception, c’est de faire en sorte que son produit réponde à un besoin précis et ne devienne pas une usine à gaz. Pour pouvoir être frugal en termes de fonctionnalités il faut identifier les bonnes… et ça, ça passe par faire de la Research.

Être Designer aujourd’hui, c’est aussi être le commercial de la méthodologie : il faut être promoteur de l’approche Design et d’une Research qui soit la plus adaptée possible.

Au-delà du “fond”, il y a des mots en termes de forme qui fonctionnent plus que d’autres.

Les personae par exemple, cela fait plusieurs années qu’on en parle dans toutes les entreprises. En réalité quand on creuse un peu on constate souvent qu’il s’agit de “proto persona” (NDLR : voir notre article sur le sujet), mais au moins c’est de plus en plus intégré aux réflexions côté Produit. Ça c’est extrêmement important car cela nous permet d’avoir un pied dans la porte et de nous engouffrer dedans pour faire de vrais personae, en en proposant une mise à jour ou l’ajout d’un nouveau segment par exemple.

La réflexion est la même pour les tests utilisateurs : aujourd’hui peu de nos clients n’en voient pas la valeur. En revanche, le problème c’est qu’ils interviennent assez tard, très souvent en phase de delivery. Là le raisonnement est le même : on rentre par ce cas d’usage de la Research et on montre que l’intérêt est de tester le plus tôt possible (avec des wireframes ou des concepts par exemple) car cela va permettre à tout le monde de gagner du temps.

Le nouvel enjeu des Designers, c’est d’aller vendre de la Research : peu importe qu’elle soit camouflée ou au contraire bien mise en avant.

Une fois qu’on a ce pied dans la porte, c’est à nous de nous en servir pour aller récupérer les données dont nous avons besoin, notamment sur les autres projets de Research moins bankables !

C’est une réflexion que j’ai de plus en plus souvent en tant que Design Manager : maintenant que j’ai validé mon budget pour mon test U, comment vais-je faire pour utiliser cette phase de Research pour alimenter également des projets qui n’ont peut-être pas eu ce budget. Il faut que ça reste dans la limite du raisonnable, mais l’idée est vraiment là : optimiser un test U pour obtenir des indicateurs sur d’autres sujets.

Aujourd’hui, il faut savoir s’engouffrer par une porte qui résonne aujourd’hui chez les clients comme les personae ou les Tests U et après aller faire des sujets de Research plus poussés… À titre personnel j’aime beaucoup la “porte” persona, qui est en plus très utile à toutes les phases du Design !

Une fois qu’on réussi à dérouler son projet de Research, comment en présenter les résultats pour en maximiser l’impact ?

D’expérience, il faut quelque chose de visuel et de facilement digeste.

N’oublions pas qu’on a souvent en face de nous des stakeholders d’un certain niveau : il faut qu’en une slide, ils comprennent le problème identifié et qu’ils aient des idées de solutions (NDLR : voir notre template de restitution).

Bien sûr, beaucoup de gens vont également être intéressés par les détails, et il est donc important de trouver le juste équilibre entre une synthèse très efficace et ensuite un compte rendu beaucoup plus détaillé, accessible à tous. Mais s’il faut choisir, je dirais que la synthèse - la plus visuelle possible - est le plus important.

Un test U qui n’a pas de synthèse, ce n’est pas un bon test U.

En termes de livrables, il y a des choses qui fonctionnent particulièrement bien : un user journey ou une experience map par exemple. C’est tout simple et ça permet de vraiment bien scénariser l’expérience : on voit bien les difficultés, les solutions…  et c’est plus facile pour nos interlocuteurs de s’approprier le sujet.

Un dernier conseil que je pourrais donner porte sur les éléments statistiques. Je pense qu’en tant que Researcher on en a trop souvent peur car par pudeur, sur des batch de 20-30 participants, on n’ose pas avancer de chiffres. Bien sûr, nous ne sommes pas sur de l’analyse statistique poussée, mais si 90% des participants rencontrent le même problème on a quand même un début de tendance à aller vérifier. Et “90% des participants” c’est plus impactant que “18 utilisateurs sur 20 participants” !

Quel regard portes-tu sur les dernières innovations et tendances qui sont venues impacter le monde de la Research ?

Je suis très positive ! Je pense que ces innovations sont autant de “leviers” actionnables pour promouvoir la Research.

La principale pour moi c’est l’Atomic Research : c’est un endroit où on va enfin pouvoir donner un accès universel à la donnée que nous collectons. Trop souvent dans le Design ou la Research nous avons tendance à être renfermés sur nous-mêmes, et là on a enfin un outil de diffusion de notre connaissance et de notre savoir-faire dans l’entreprise. C’est un vrai outil de collaboration !

Le deuxième sujet, plus récent, c’est ChatGPT et l’intelligence artificielle de manière plus générale. Moi je trouve que c’est un outil qui peut s’avérer extrêmement puissant si on apprend à l’utiliser. En tant que Researcher, c’est à nous d’aller alimenter ces modèles d’intelligence artificielle avec la donnée que nous collectons, et de nous appuyer sur elle pour générer des insights (que nous n’aurions pas forcément vus au passage).

Utiliser l’intelligence de ChatGPT sur nos données collectées dans les règles de l’art, cela peut être un vrai différenciant.

En revanche, cela ne sert à rien de demander à ChatGPT si un protocole de test est bien ou lui poser directement des questions sur les usages de tel ou tel produit : c’est comme si nous lui demandions son avis personnel, c’est totalement inutile ! En plus on ne sait pas trop avec quelles données le modèle a été entraîné jusqu’à maintenant… il ne doit donc pas être utilisé à tort et à travers, sans cadre.

Je pense qu’en tant que Researchers nous ne devons pas voir ces outils comme étant des ennemis, mais plutôt comme une possibilité d’enrichissement de nos méthodes de travail, pour gagner du temps et gagner en visibilité auprès de nos parties prenantes.

ChatGPT et Midjourney ne sont pas que des petites révolutions, mais des moyens de donner encore plus d’impact à nos projets.

Après, en face de ces fantastiques leviers, nous nous devons d’être particulièrement précautionneux sur notre manière de récolter et traiter les données. À titre personnel, en tant que sociologue je connais bien les règles de la CNIL, les règles du RGPD s’appliquent aussi au monde de la Recherche, et nos procédés doivent respecter la Data et par extension l’utilisateur. Sensibilisez-vous !