Aujourd’hui, tout le monde ou presque est convaincu qu’un produit digital doit être centré sur les besoins des utilisateurs. User research, feedbacks clients, focus groups, NPS, persona, discovery : tout le monde en parle, mais dans les faits, que se passe-t-il ?
Très souvent, en vérité, on va demander leur avis aux utilisateurs une fois que le produit est déjà bien avancé : on va montrer des maquettes, un MVP, voire même, faire tester un produit fini.
Pourtant, là où la recherche utilisateur apporte le plus de valeur, ce n’est pas quand on leur montre une solution, mais quand on parle de leurs problèmes.
Mais comment s’y prendre ? Est-ce qu’il faut vraiment toujours écouter les utilisateurs ? À quel moment les intégrer dans la réflexion ? Comment arbitrer entre les attentes des clients et les besoins business ?
Dans cet article, je vous partage quelques bonnes pratiques, avec en fil rouge un exemple concret de projet sur lequel j’ai travaillé en tant que Lead Designer chez theTribe : le projet Needhelp.
Sommaire :
- Contexte : le cas Needhelp 📝
- La user research pendant la phase de vie du produit 🔄
- La recherche utilisateur pour faire émerger des compromis 🤝
Contexte : le cas Needhelp 📝
Tout d’abord, quelques mots de contexte pour comprendre ce projet.
Needhelp, c’est une marketplace qui permet de déléguer des travaux à un prestataire de confiance. Historiquement, Neehelp mettait en relation des particuliers ayant besoin d’un coup de main (pour installer une cuisine, monter un meuble, repeindre un mur…) et des “jobbers” proposant des prestations de service. Ces jobbers pouvaient être des artisans, des bricoleurs amateurs, des autoentrepreneurs…
Lorsque Needhelp nous a contactés, le business model était en train d’évoluer vers un modèle B2B2C. En effet, en plus des particuliers, l’offre de Needhelp se développait à destination des magasins de bricolage, en quête de professionnels pour répondre aux besoins de leurs clients.
Par ailleurs, Needhelp souhaitait se concentrer sur une population d’artisans professionnels, experts dans un domaine à forte valeur ajoutée, plutôt que permettre à quiconque de proposer ses services comme jobber.
Il fallait revoir le process d’inscription, créé 5 ans auparavant, qui ne correspondait plus à la cible, et qui ne facilitait pas l’activation du compte.
L’équipe interne était focalisée à ce moment-là sur la refonte technique de la plateforme : elle avait donc besoin d’aide pour aller vite sur ce chantier : c’est comme ça que nous sommes arrivés sur le projet.
Première phase de user research : la découverte 🔭
Lorsque nous avons commencé à travailler sur le projet, nous nous sommes d’abord posé la question : quel est le persona auquel on s’adresse ?
Nous aurions pu aller interroger des magasins, des clients. Mais notre objectif étant de faciliter l’inscription des artisans sur la plateforme, nous nous sommes concentrés sur ce persona, et avons cherché à mieux le connaître.
Nous avons donc organisé un focus group avec des artisans, pour les faire parler ouvertement : comment se passe leur travail ? À quels problèmes sont-ils confrontés ? Quel est le caillou dans leur chaussure ?
L’avantage du focus group, c’est qu’il encourage le débat : les échanges sont riches, chacun rebondit sur les parole de l’autre, et ainsi, on fait émerger les grandes problématiques, les points de douleur.
On peut aussi doubler avec des échanges individuels, au cours desquels les personnes se livreront plus facilement, sans le regard des autres.
Mais, l’essentiel à ce moment-là, c’est d’être vraiment dans l’écoute : on n’est pas là pour parler de son produit, proposer des solutions, encore moins pour présenter des maquettes : c’est le rôle de la première phase de user research.
Deuxième phase de user research : Le Design Sprint 🏃
Une fois que l’on a rencontré les utilisateurs, on passe à la deuxième étape : le design sprint.
Cette étape nous a permis de partager avec l’équipe de Needhelp les résultats de la phase de user research, et à partir de là de créer un prototype pour le nouveau parcours d’inscription. Et très vite, on est repartis sur une phase de user research : on a pris 45 minutes pour partager le prototype avec nos personas.
À ce stade, on va avoir plusieurs types de retours : de l’ordre du ressenti (j’aime / j’aime pas), mais aussi de l’ordre du besoin (ça m’est utile / ça ne m’est pas utile).
L’objectif n’est bien sûr pas de prendre au mot les retours de chacun, mais d’invalider les hypothèses inutiles. Cela permet de confronter ce que l’équipe pense être une bonne idée, avec ce qui est réellement utile pour les utilisateurs.
Le but final, c’est d’obtenir un maximum d’apprentissage, très vite, pour savoir ce qui est vraiment important et de prioriser pour la suite.
C’est ce qui permet d’obtenir un chemin critique pour aboutir à un premier produit : le MVP.
Troisième phase de user research : Test du MVP ⚙️
C’est à cette étape que l’on va mettre le MVP, la première version du produit, dans les mains des utilisateurs.
Cette phase va avoir plusieurs utilités :
- Les utilisateurs vont remonter des problèmes d’utilisation, des bugs que l’on va devoir résoudre.
- Les utilisateurs vont remonter des frustrations positives, des choses qu’ils auraient aimé pouvoir faire avec le produit : cela nous donne des idées de potentielles évolutions futures.
- Enfin, certains utilisateurs vont témoigner de l’enthousiasme face au produit : on va avoir des “J’adore ! “, “Je le veux !”, “C’est génial !”. Mais également des suggestions : “Je pense qu’il faudrait faire ceci, ou cela…”. C’est ainsi qu’on va identifier des utilisateurs qui ont envie de co-construire, de faire partie de la communauté, et que l’on va pouvoir solliciter par la suite.
La user research pendant la phase de vie du produit 🔄
S’appuyer sur la communauté… et sur l’équipe 🏋️
Après le MVP, on va pouvoir se lancer dans le développement du produit. Mais ce n’est pas fini ! Une fois la première version sortie, on a besoin de recueillir des retours, en continu.
Dans le cas de Needhelp, les premières phases avaient permis d’identifier des utilisateurs intéressés par le produit. On a donc pu leur partager un formulaire pour qu’ils nous transmettent leurs retours.
Il est également possible, dans le cas d’une application mobile, de partager un lien vers le formulaire via les stores. On peut encore créer une communauté en ligne, inciter les utilisateurs à partager leurs demandes, avec un système de votes.
Mais on ne peut bien entendu pas traiter toutes les demandes. Il faut les croiser avec les autres sources de contact : les demandes faites au support, les retours des customer success managers, des commerciaux…
Une fois le produit en production, on multiplie les sources de feedbacks, et ce n’est pas facile de prioriser. C’est pourquoi il faut bien choisir ce que l’on écoute, plutôt que tout écouter : se concentrer sur un persona, un problème à la fois.
Comment faire le tri entre les demandes des utilisateurs ? ♻️
Il peut être difficile, pendant la vie d’un produit, de faire le tri entre les différents feedbacks : ceux que l’on va chercher spécifiquement sur un sujet précis, ceux qui remontent spontanément du terrain, ceux de l’équipe…
Je l’ai dit, il est essentiel de rester concentré sur la résolution des problèmes d’un persona à la fois. Certains autres personas ne seront pas satisfaits, mais on réglera leur problème par la suite, dans un prochain sprint : c’est important de s’astreindre à cette discipline.
Il faut également savoir faire le tri entre les problèmes très opérationnelles (par exemple : “le paiement est trop lent”), et la problématique qui se cache derrière, qui est plus intéressante (“j’ai besoin d’être rassuré sur le fait que le paiement se soit bien réalisé”). Lorsque l’on interroge des utilisateurs qui sont habitués à utiliser un produit, leurs retours seront souvent très opérationnels. C’est pourquoi je conseille de continuer à faire appel régulièrement à des personnes qui ne sont pas encore utilisatrices du produit, ou alors à de nouveaux utilisateurs.
Si on reprend le cas Needhelp, lorsque l’on a lancé la phase de user research, la plateforme existait déjà : on aurait pu interroger des utilisateurs qui connaissaient le produit, mais on a choisi d’interroger des inconnus, et de faire comme si le produit n’existait pas. C’est ce qui permet de faire émerger ce qui est réellement nécessaire, au-delà de l’existant.
À quel moment interroger les utilisateurs ? 🕓
Un produit qui évolue en continu doit régulièrement être confronté à ses utilisateurs. Mais attention à ne pas faire de tests utilisateurs trop tôt, ni trop tard.
Si on recueille les feedbacks des utilisateurs trop tôt, alors que les développements ne sont pas encore assez avancés, on risque de désorganiser le travail de l’équipe, et d’obtenir des retours peu qualitatifs.
Mais si on s’y prend trop tard, on court le risque de décaler le planning, de devoir “tout casser”.
Les méthodes agiles recommandent de tester le produit à la fin de chaque sprint, mais dans les faits, c’est difficilement applicable, notamment dans le process de développement d’un nouveau produit.
Du coup, sur une série de 5 sprints, je recommande de déclencher des tests utilisateurs à partir du 3ème ou du 4ème sprint – en ayant bien en tête que leurs retours pourront modifier les priorités, et impacter le dernier sprint . Cela permet de garder l’agilité nécessaire, tout en permettant aux équipes de développement de rester concentrées sur leur travail.
La recherche utilisateur pour faire émerger des compromis 🤝
On s’imagine souvent que la recherche utilisateur n’est pas essentielle quand on connait son produit, son marché, ses clients.
D’ailleurs, rares sont les entreprises qui demandent explicitement à faire de la user research : et pourtant elle est essentielle pour valider ou invalider les intuitions.
Au sein d’une équipe, chacun joue son rôle : le rôle du designer, c’est de tout casser, de faire la révolution ! Mais il s’intègre dans une équipe, et le rôle de la user research, c’est d’aider à trouver un équilibre entre les forces conservatrices et révolutionnaires. Elle va nous aider à faire émerger des compromis.
Finalement, les retours utilisateurs, c’est un des éléments à prendre en compte pour donner la direction à un produit : comme la data, comme l’intuition, comme les retours business. La user research aide à rationaliser la prise de décision, mais ce n’est pas “la source de vérité” : c’est pour cela qu’un designer ne dit jamais “il faut”, ou “il ne faut pas” !
