Il y a un réflexe assez merveilleux quand quelqu'un utilise mal le produit qu'on a construit : lui expliquer immédiatement pourquoi c'est lui qui n'a pas compris.

« Attends, clique là. »

« Normalement tu arrives par cette page. »

« Là c'est parce que ce compte n'a pas renseigné son mail. »

En quelques secondes, tout remarche. On vient aussi de détruire une bonne partie du test.

Benjamin Code a fait l'inverse avec Small Player, une offre de MeetSponsors qui aide à trouver de petits créateurs puis à préparer une prise de contact. Il a installé Pauline Clavelou devant le produit pendant environ trente minutes et l'a regardée avancer sans la sauver à chaque hésitation.

C'est douloureux à regarder. Donc forcément assez instructif.

Quand le créateur se tait, l'interface doit parler toute seule

Au début de la vidéo, Benjamin décrit exactement ce qui le met mal à l'aise : voir quelqu'un chercher, hésiter ou prendre une mauvaise direction alors qu'il connaît la réponse et pourrait la donner en deux secondes.

Cette retenue change la nature du problème.

Tant qu'il intervient, une ambiguïté dans l'interface peut passer pour un détail. Dès qu'il se tait, la même ambiguïté prend vingt secondes, crée une hypothèse chez l'utilisatrice, puis l'envoie éventuellement vers une autre mauvaise décision.

Le bug n'est plus « ce texte pourrait être plus clair ». On voit sa trajectoire.

Pauline se demande par exemple à quel point les profils de créateurs proposés sont récents et actifs. Benjamin réfléchit ensuite à la manière dont les exemples d'onboarding pourraient favoriser des profils ayant suffisamment de données pour que la première expérience soit compréhensible.

Ce n'est pas une découverte scientifique sur tous les utilisateurs de Small Player. C'est une friction observée chez une personne. Mais c'est déjà beaucoup plus exploitable qu'un commentaire abstrait du type « il faudrait rassurer sur la qualité des recommandations ».

Puis le scénario parfait tombe sur le mauvais compte

La meilleure partie arrive quand la démonstration casse pour une raison assez bête.

Le produit aide Pauline à préparer un email pour contacter un créateur. Elle avance dans le flux, puis le mail généré devient difficile à retrouver. En plus, le profil utilisé pour la démonstration n'affiche pas l'adresse que le parcours attendait.

On peut presque sentir Benjamin chercher mentalement la petite explication qui ferait disparaître le problème.

Sauf que l'explication n'aide pas l'utilisatrice.

Pauline propose quelque chose de très simple : garder le mail quelque part, sous forme de brouillon ou de preview récupérable, plutôt que de le faire disparaître derrière l'étape suivante.

Ce détail est intéressant parce qu'il n'a rien d'exotique. Pas besoin de refaire l'architecture du SaaS ou d'ajouter un modèle plus gros. Le produit a simplement traité une étape intermédiaire comme jetable alors que l'utilisatrice, elle, la considérait déjà comme son travail.

C'est exactement le genre de différence de modèle mental qu'on voit mal quand on clique soi-même dans un parcours qu'on connaît par cœur.

Un test utile n'a pas besoin de ressembler à un laboratoire

Pour un petit produit, la méthode est presque vexante de simplicité.

Donner une tâche réelle. Ne pas expliquer le chemin. Regarder ce que la personne croit comprendre. Noter les endroits où elle s'arrête, revient en arrière ou invente une règle qui n'existe pas. Puis seulement après, discuter.

Ce n'est pas une formule magique. Une seule personne ne représente pas un marché, et une session ne donne pas une priorité statistique aux problèmes rencontrés. On peut très facilement surcorriger un produit pour un comportement isolé.

Mais le test répond à une autre question, plus modeste : est-ce que le parcours qu'on pense avoir construit existe aussi dans la tête de quelqu'un qui ne l'a pas construit ?

Pour une équipe de deux personnes, cette question vaut déjà beaucoup.

Et surtout, elle coûte peu. Le principal matériel nécessaire est un produit à moitié utilisable, une personne suffisamment proche de la cible et la capacité du fondateur à fermer sa bouche pendant trente minutes. Le troisième composant est probablement le plus rare.

Ne pas corriger pendant qu'on observe

L'autre piège serait de transformer la session en backlog en temps réel.

À chaque hésitation, on imagine immédiatement un tooltip, un bouton, une nouvelle étape. Puis dix observations plus tard, l'interface ressemble à une notice de chaudière écrite par quelqu'un qui avait peur qu'on lui pose une question.

La vidéo de Benjamin est plus intéressante quand elle montre le problème avant la solution : ce que Pauline cherchait, ce qu'elle pensait que le système faisait, puis ce qui l'a bloquée.

La solution peut ensuite être minuscule ou complètement différente de la première idée.

C'est peut-être ça que j'aime le plus dans cette méthode. Elle oblige le maker à quitter son rôle d'explicateur pendant quelques minutes. Le produit ne bénéficie plus du contexte qui vit uniquement dans la tête de celui qui l'a fabriqué.

Et soudain, les petits silences deviennent extrêmement bavards.