Écouter les utilisateurs : interviews et tests

La recherche UX n'a pas besoin d'être lourde pour être utile. Avec quelques bonnes pratiques, tu peux obtenir des insights concrets en quelques jours - et éviter de développer des features « logiques sur le papier » mais frustrantes dès qu'un vrai humain s'en sert. L'objectif, ce n'est pas de produire un rapport de 30 pages. C'est de passer de « j'ai des avis » à « j'ai des preuves ».

Découvrir, tester, itérer. Une boucle simple. Répétée souvent. C'est déjà beaucoup mieux qu'un atelier interne où tout le monde vote sur des post-its.

Ce que tu cherches vraiment

Une bonne recherche ne chasse pas les préférences (« tu préfères bleu ou rouge ? »). Elle cherche des comportements et des contraintes. Le contexte : où, quand, avec quel appareil, sous quelle pression. La tâche : ce que la personne essaie d'accomplir. Les obstacles : ce qui la bloque, la ralentit, la fait douter. Les stratégies : comment elle contourne le problème aujourd'hui.

Les gens sont mauvais pour prédire ce qu'ils feront demain. Ils sont excellents pour raconter ce qu'ils ont fait la semaine dernière - surtout si tu les laisses montrer, pas seulement parler. « La dernière fois que tu as demandé un devis… » ouvre plus de portes que « tu utiliserais notre outil ? ».

L'interview sans questions inutiles

Quelques règles simples. Parler du passé plutôt que du futur. Demander des exemples et des preuves. Éviter de « vendre » l'idée pendant l'échange - sinon tu obtiens de la politesse, pas de la vérité.

Une structure de trente à quarante-cinq minutes suffit souvent. Contexte et rôle. Dernière occurrence de la tâche. Frustrations et contournements. Critères de réussite pour la personne. Wrap-up et permission de recontacter. Tu n'as pas besoin d'un guide de 12 pages. Tu as besoin d'écouter, de relancer sur le flou, et de noter les verbatims qui font mal - ceux qui montrent un vrai écart entre ton modèle mental et le leur.

Le piège classique : interviewer uniquement des collègues ou des clients « fans ». Le biais de proximité te rassure. Il ne te protège pas.

Le test utilisateur : le format le plus rentable

Si tu dois choisir une seule méthode, teste un prototype. Tu donnes un scénario : « Tu veux demander un devis pour un site vitrine. Fais-le. » Puis tu observes. Où ça hésite. Où ça clique au hasard. Où ça abandonne. Tu ne demandes pas « tu aimes ? ». Tu regardes si la personne réussit, à quel prix, et où le parcours se fissure.

L'idée du « test de cinq utilisateurs » (Nielsen) tient toujours : avec des profils pertinents, tu détectes une grosse partie des problèmes majeurs. Pas tous. Mais assez pour prioriser une semaine de correctifs plutôt qu'un mois de débats.

Modéré (en visio), tu peux relancer et comprendre le raisonnement - idéal si le produit est complexe. Non modéré, c'est plus scalable, moins riche : bien pour vérifier un parcours simple ou comparer deux variantes. Dans les deux cas, un scénario clair et un prototype stable battent une maquette commentée à la va-vite.

Prendre des notes sans se noyer

Pendant un test, note le moment (où), le symptôme (quoi), l'impact (bloquant, ralentissant, irritant), et une hypothèse (pourquoi). Exemple : « Paiement > champs CB : hésitation quinze secondes, cherche le CVC, abandon » - problème probable de label et d'exemple visuel. Tu n'écris pas un roman. Tu captures des signaux actionnables.

Enregistre si tu as le consentement. Relis à froid. Les patterns apparaissent souvent après trois sessions, pas à la première.

Transformer en décisions produit

Après cinq à huit sessions, synthétise. Top frictions classées par impact. Top besoins - ce que les gens essaient vraiment de faire. Top incompréhensions - où le modèle mental diverge. Puis traduis en backlog : correction UI (label, feedback), changement de parcours (réordonner les étapes), décision produit (supprimer une étape, simplifier un formulaire).

Un insight n'est utile que s'il déclenche une action. Un beau slide « learnings » qui ne change rien au sprint suivant, c'est de la décoration.

Évite aussi de tout corriger d'un coup. Priorise les bloquants. Confondre « ils ont compris » et « ils ont réussi vite » est un autre classique : quelqu'un peut réussir en peinant, et tu appelleras ça une victoire. Mesure le coût cognitif, pas seulement le succès binaire.

Recruter sans se ruiner

Cinq utilisateurs pertinents valent mieux que vingt profils « à peu près ». Définis le critère : métier, fréquence d'usage, appareil, niveau d'aisance. Un artisan qui envoie des devis sur mobile n'est pas interchangeable avec un office manager sur desktop. Propose une compensation simple - chèque cadeau, crédit produit, réduction. Respecte le temps des gens.

Si tu n'as pas de budget, commence par des utilisateurs existants (support, clients récents, beta). Évite seulement le cercle trop proche : collègues, amis, famille. Ils te veulent du bien. Ils te mentent gentiment. Et si tu peines à recruter, réduis le scope du scénario plutôt que la qualité des profils : un test court avec la bonne personne bat une session longue avec le mauvais profil.

Petite boucle, gros effet

Quand la synthèse est prête, partage-la en une page : frictions, preuves (verbatims courts), décisions proposées. Pas un roman. Une page que le product owner peut coller dans le ticket. Puis ferme la boucle : corrige, reteste sur un ou deux points critiques. La recherche qui ne revient jamais sur le terrain devient une archive.

La recherche UX, c'est une assurance. Elle réduit le risque de construire la mauvaise chose - ou la bonne chose, dans le mauvais ordre. Commence petit : cinq utilisateurs pertinents, un scénario, un prototype, une synthèse actionnable. Découvrir, tester, itérer. Tu verras vite l'impact, et surtout tu arrêteras de prendre les opinions de la room pour des vérités terrain.