Tous les articles
RECHERCHE UTILISATEUR
Comment analyser et synthétiser des retours utilisateurs
sans se noyer dans les données ?
On parle beaucoup de comment mener une interview utilisateur, comment préparer un test d'utilisabilité, comment formuler les bonnes questions dans un questionnaire. Mais ce qui vient après (les dizaines de pages de notes, les heures d'enregistrement, les centaines de réponses…) on en parle moins. C'est pourtant là que se joue l'essentiel : transformer une masse de données brutes en décisions de design concrètes.
Ce n'est pas un processus linéaire, et il n'existe pas de méthode universelle. Ce que j'ai appris, c'est qu'il faut adapter son niveau de rigueur au volume de données et ne jamais brûler les étapes, même quand on est pressé d'arriver aux solutions.
LES 4 ÉTAPES QUE JE MÈNE
1. collecter sans déjà interpréter
Pendant une session qu'il s'agisse d'une interview, d'un test d'utilisabilité ou d'un questionnaire, l'objectif est de capturer, pas encore de trier. Cette distinction est plus difficile à tenir qu'elle n'y paraît.
La tentation est grande de commencer à analyser en live : de se dire « ce qu'il veut dire, c'est que... » et de noter sa propre reformulation plutôt que les mots exacts de l'utilisateur. C'est une erreur fréquente. Reformuler trop tôt, c'est déjà projeter et on perd une nuance qui aurait pu devenir un insight décisif.
Mon approche varie selon le volume de données attendu. Sur un petit nombre d'entretiens, je prends des notes pendant la session et je regroupe juste après. Sur un volume plus important, je retranscris d'abord l'ensemble de commencer à trier. Dans tous les cas, je reste le plus proche possible des mots bruts de l'utilisateur jusqu'à la phase d'analyse.
Gardez les verbtims bruts
Un verbatim exact (« je ne comprends pas à quoi ça sert ici ») a une valeur que sa reformulation (« l'utilisateur ne comprend pas la fonctionnalité ») n'a pas. Le premier donne le ton, l'intensité, parfois même la piste de solution. Le second est déjà une interprétation.
2. Trier : l'affinity mapping sur papier
Une fois les données collectées, je passe à la phase de tri. Ma méthode de référence : l'affinity mapping sur post-its physiques. Je surligne d'abord les verbatims les plus significatifs par couleur thématique, une couleur par grand thème pressenti. Puis je regroupe les post-its par affinité, en laissant les patterns émerger plutôt qu'en les forçant.
Le papier a quelque chose que les outils numériques n'ont pas tout à fait : la manipulation physique oblige à lire, relire, et vraiment décider où chaque information se place. On ne "glisse" pas un post-it, on le pose quelque part après y avoir réfléchi.
À ce stade, je cherche deux choses distinctes :
-
Les patterns : ce qui revient plusieurs fois, dans des mots différents mais avec le même sens,
-
Les signaux forts : ce qui n'est apparu qu'une fois, mais avec une intensité ou une frustration particulièrement marquée.
Fréquence ≠ importance
Un problème mentionné par huit utilisateurs sur dix est évidemment significatif. Mais un problème exprimé avec une frustration très forte par un seul utilisateur mérite d'être noté et questionné. La fréquence est un indicateur parmi d'autres, pas le seul critère de priorisation.
3. Synthétiser : des thèmes aux frictions
Une fois les groupes formés, je nomme chaque thème de façon claire et actionnable. Puis, pour chaque thème, j'identifie les frictions concrètes : qu'est-ce qui bloque, ralentit, ou frustre réellement l'utilisateur ?
C'est à ce moment que la qualité de la formulation devient déterminante. Une friction bien nommée est déjà à moitié résolue.
La différence entre un constat et une friction :
-
Constat : « Les utilisateurs ont du mal avec le diagramme. »
-
Friction : « Les utilisateurs ne parviennent pas à lire le diagramme de façon autonome, même après les explications initiales, la représentation visuelle ne suffit pas à rendre le concept compréhensible d'un coup d'œil. »
Une fois les frictions formulées, je les priorise selon leur fréquence, leur impact sur l'expérience globale, et leur faisabilité à corriger. Toutes ne méritent pas la même urgence.
4. De la friction à la décision design
C'est l'étape la plus difficile et souvent la moins documentée. Comment passer d'une liste de frictions à des décisions de design concrètes, sans sauter directement aux solutions ?
Ma méthode : chaque friction devient une question de design à explorer, pas une solution
imposée.
On ne part pas de « il faut changer ce composant » mais de « comment pourrait-on rendre
cette information
lisible sans explication préalable ? ».
Cette nuance change complètement l'espace de solutions qu'on s'autorise à explorer.
Un exemple concret : Dans le cadre d'un projet sur la charge mentale subie par les femmes, nous avions observé lors des tests un problème récurrent : les utilisatrices ne parvenaient pas à lire un diagramme de façon autonome, malgré les explications données en début de session. La friction était claire, la représentation visuelle ne communiquait pas le concept par elle-même.
Plutôt que de simplement « simplifier le diagramme », nous nous sommes demandé : « comment représenter visuellement une notion de poids et de déséquilibre, sans avoir besoin de l'expliquer ? ». La réponse a été de transformer le diagramme en balance, une métaphore visuelle immédiatement lisible, qui montre le poids de chaque élément que la femme porte, sans qu'aucune explication ne soit nécessaire.
C'est ça, le passage de l'insight à la décision design : une question ouverte, puis une réponse ancrée dans ce que les utilisateurs ont exprimé.
Ne pas sauter à la solution
Aller directement des retours utilisateurs aux maquettes, c'est court-circuiter l'analyse. La friction d'abord, la question ensuite, la solution en dernier dans cet ordre, les décisions sont mieux justifiées, plus solides, et beaucoup plus faciles à défendre face à un client ou une équipe.
Je replace également les frictions dans la user journey ou les personas quand c'est pertinent : visualiser à quel moment du parcours les problèmes se concentrent aide à prioriser et à raconter les résultats de façon claire.
Une bonne synthèse de retours utilisateurs, ce n'est pas un rapport exhaustif qui liste tout ce qui a été dit. C'est un ensemble de décisions actionnables, ancrées dans ce que les utilisateurs ont réellement exprimé et formulées de façon à guider concrètement la suite de la conception.
Ce que ce processus m'a appris : l'essentiel n'est pas dans le volume de données qu'on collecte, mais dans la qualité des questions qu'on se pose au moment de les analyser.
