Rester proche de ses utilisateurs sans les harceler

Je reste convaincu qu’un produit ne doit pas se cacher derrière une communication froide. Les utilisateurs veulent savoir qui les aide, comprendre les décisions et pouvoir signaler un problème.

La proximité ne se mesure toutefois pas au nombre de publications sur les réseaux sociaux. Elle se construit quand l’équipe écoute, agit et revient expliquer ce qui a changé.

Observer avant de demander des idées

Je commence par les traces déjà disponibles : demandes au support, recherches sans résultat, erreurs, abandons et questions répétées. Ces signaux montrent où le service crée de la confusion.

Je parle ensuite aux personnes concernées. Je ne leur demande pas simplement quelle fonctionnalité elles veulent. Je cherche à comprendre ce qu’elles essayaient de faire, comment elles s’y prennent aujourd’hui et ce qui les bloque.

Le guide de recherche utilisateur de GOV.UK rappelle une règle utile : une opinion qui ne vient pas d’un utilisateur reste une hypothèse à vérifier.

Garder une boucle courte

Une boucle de retour simple suffit :

1. choisir une question précise ;
2. parler à des utilisateurs concernés ;
3. observer leur parcours réel ;
4. rapprocher leurs propos des données du produit ;
5. décider ce qui doit changer ;
6. revenir vers eux avec le résultat.

Cette dernière étape est souvent oubliée. Une personne prend du temps pour expliquer un problème, puis ne sait jamais si son message a servi. Même lorsque je ne retiens pas sa demande, je peux expliquer la contrainte ou la décision.

Ne pas confondre demande et besoin

Une demande de fonctionnalité décrit souvent une solution imaginée par l’utilisateur. Mon travail consiste à retrouver le besoin derrière cette proposition.

Si cinq personnes demandent un bouton d’export différent, le problème peut venir du format actuel, d’un manque de filtre ou d’un rapport envoyé trop tard. Ajouter cinq boutons ne résout pas nécessairement le bon problème.

Je combine donc plusieurs sources :

• les entretiens pour comprendre le contexte ;
• les tests d’utilisation pour voir les hésitations ;
• le support pour repérer les problèmes répétés ;
• les données du produit pour mesurer le parcours ;
• les retours de l’équipe qui accompagne les utilisateurs.

Montrer les personnes derrière le produit

La première version de mon article conseillait de publier beaucoup de photos de l’équipe. Ce n’est pas une obligation. Chacun doit pouvoir choisir ce qui devient public.

Je préfère aujourd’hui des signes plus utiles : une page qui présente les responsables, des notes de version compréhensibles, une adresse de support claire et des réponses signées par une personne. Je montre aussi les limites du produit au lieu de prétendre que tout est possible.

Respecter le temps et le consentement

Un message de recherche n’est pas une permission pour envoyer ensuite des offres. Je sépare les invitations à participer, les messages de service et les communications commerciales. Je précise pourquoi je contacte la personne, ce qui sera conservé et comment ses remarques seront utilisées.

Rester proche ne signifie pas solliciter tout le monde en permanence. Il s’agit d’être disponible au bon moment, de poser de meilleures questions et de fermer la boucle après une décision.

La confiance vient de cette continuité. L’utilisateur voit que son problème a été entendu et que l’équipe assume la suite.