Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

L’hallucination du bâtisseur et la malédiction de la connaissance

Les ingénieurs, les concepteurs et les chefs de produit souffrent tous d’une maladie mortelle : le biais du constructeur (également connu sous le nom de malédiction de la connaissance). Nous savons comment fonctionne la fonctionnalité parce que nous l’avons construite. Nous savons que l’icône “Enregistrer” est une disquette. Nous savons que vous devez cliquer sur « Modifier » avant de pouvoir saisir dans le champ. Nous savons que le menu à trois points contient l’option “Supprimer”. C’est une évidence pour nous. Pour l’utilisateur, c’est déroutant. Ils regardent l’écran et voient du bruit. Ils ont peur de cliquer sur le mauvais bouton. Ils ne savent pas ce que signifie « Menu Hamburger ». Le Test utilisateur consiste à regarder un étranger essayer d’utiliser votre produit sans votre aide. C’est souvent douloureux. Vous les verrez lutter pour trouver l’énorme bouton « S’inscrire » qui se trouve en plein centre de l’écran. Vous aurez envie de crier : “C’EST JUSTE LÀ !”. Mais vous ne pouvez pas. Vous devez vous asseoir sur vos mains et observer. Parce que s’ils ne le trouvent pas, ce n’est pas de leur faute. C’est ta faute. Les tests utilisateur comblent le fossé entre « l’utilisateur idéal » dans votre tête et le « utilisateur réel » dans la nature.

Pourquoi Maison Code discute des tests utilisateurs

Chez Maison Code, nous ne nous contentons pas d’écrire du code. Nous construisons des Produits. Nous avons vu des startups gaspiller 500 000 € pour créer un ensemble de fonctionnalités complexes que personne ne comprend. Ils se lancent. Grillons. « Pourquoi n’utilisent-ils pas le filtre avancé ? » Parce qu’ils ne savaient pas que ça existait. Avant d’écrire une seule ligne de code, ou immédiatement après le prototype MVP, nous préconisons les Tests d’utilisabilité. Nous facilitons ces séances de manière efficace. Nous apportons la « Voix du client » dans la salle d’ingénierie. Il est difficile de contester les données. “L’opinion générale est que le bleu est meilleur.” vs “5 utilisateurs sur 5 n’ont pas réussi à trouver le bouton de paiement.” La deuxième déclaration incite à l’action. Nous en parlons parce que la dette UX est aussi réelle que la dette technologique.

Qualitatif vs Quantitatif : vue d’ensemble

Vous avez besoin des deux flux de données pour prendre des décisions.

Données quantitatives (le « Quoi ») :

Outils : Google Analytics, Mixpanel, Amplitude.
Insights : “Le taux de rebond est de 60 % sur la page de tarification.” “Le taux de conversion a baissé de 2 % sur mobile.”
Angle mort : il ne vous dit pas pourquoi. Ont-ils rebondi parce que le prix est trop élevé ? Ou parce que la page ne s’est pas chargée ? Ou parce que la police était moche ?

Données qualitatives (le « Pourquoi ») :

Outils : entretiens avec les utilisateurs, tests d’utilisabilité, relecture de session.
Insights : “L’utilisateur n’a pas fait défiler la page vers le bas car l‘“image du héros” ressemblait à une page de destination en plein écran (l’illusion False Bottom).” “L’utilisateur ne faisait pas confiance au site parce que les photos d’archives semblaient fausses.”
Résultat : cela vous donne le correctif spécifique exploitable. “Réduisez la hauteur du héros à 80vh pour que la section suivante soit visible.”

La méthodologie : Le test maman

Nous suivons les principes de « The Mom Test » de Rob Fitzpatrick. Si vous demandez à votre maman : “Est-ce que tu aimes mon application ?”, elle vous répondra “Oui, chérie, elle est magnifique”. Elle ment pour protéger vos sentiments. La plupart des utilisateurs veulent être gentils. Règle n°1 : Ne demandez jamais d’avis (« Est-ce que ça vous plaît ? »). Demandez des comportements. Règle n°2 : Donnez-leur une tâche spécifique (le scénario). “Imaginez que vous prévoyez un voyage à Paris le week-end prochain. Essayez de réserver un hôtel à moins de 200 €.” Règle n°3 : Tais-toi. Ne les guidez pas. “Cliquez ici.” “Non, pas celui-là.” S’ils restent coincés, laissez-les lutter un peu. Le combat, ce sont les données. S’ils demandent « À quoi sert ce bouton ? », réfléchissez-y : « À votre avis, qu’est-ce qu’il fait ? »

Tests modérés et non modérés

Il existe deux manières principales d’exécuter cela.

1. Tests modérés (Zoom / En personne)

Vous êtes en communication avec l’utilisateur.

Protocole : « Pensez à haute voix ». Demandez à l’utilisateur de raconter ses pensées. “Je cherche le prix… je ne le trouve pas… je clique sur ce menu…”
Avantages : informations approfondies. Vous pouvez demander « Pourquoi avez-vous hésité ? ». Vous pouvez faire pivoter le test s’ils trouvent un nouveau bug. Construction de l’empathie.
Inconvénients : Cher. Prend beaucoup de temps (1 heure par utilisateur + planification). Risque de biaiser l’utilisateur (l‘“effet Hawthorne” - ils agissent plus intelligemment parce qu’ils sont surveillés).

2. Tests non modérés (UserTesting.com, Maze, Lookback)

Vous téléchargez un prototype (lien Figma) ou une URL en direct. Vous écrivez un script de tâches. Les utilisateurs enregistrent leur écran et leur voix tout en le faisant seuls dans leur chambre.

Avantages : Rapide. Vous pouvez lancer un test à 17h et avoir 10 vidéos avant 9h. Pas cher (euh).
Inconvénients : Aucun suivi possible. Les utilisateurs peuvent lui téléphoner (il suffit de cliquer rapidement pour être payé).
Stratégie : utilisez Modéré pour la « Découverte » (Que devrions-nous construire ?). Utilisez Non modéré pour la « Validation » (l’avons-nous bien construit ?).

Outils du métier

Prototypes Figma : Le code le moins cher est celui que vous n’écrivez pas. Construisez un « factice cliquable » dans Figma. Cela a l’air réel mais n’a pas de backend. Testez ceci. Si les utilisateurs échouent, vous modifiez le dessin. Cela prend 10 minutes. Si vous testez la version du Code, la modification prend 2 jours. échouer rapidement.
Plateformes de recrutement : UserTesting.com : la norme d’entreprise. Accès coûteux mais instantané à des données démographiques spécifiques (« Un dentiste de l’Ohio gagnant 100 000 € »). UsabilityHub / Ballpark : tests moins chers et plus courts. Utilisez votre propre liste : envoyez votre newsletter par e-mail. Offrez une carte-cadeau Amazon de 50 €. Ce sont vos vrais utilisateurs.
Tests passifs (Hotjar / Microsoft Clarity) : Installez un script sur votre site en direct. Il enregistre des sessions vidéo de vrais visiteurs (anonymisés). Regardez 10 séances en déjeunant. Heatmaps : affichez où les gens cliquent. Rage Clicks : clic rapide sur un élément. Indique « Cela ressemble à un bouton, mais ce n’est pas le cas ». -> Réparez ceci immédiatement.

La règle des 5 utilisateurs (Nielsen Norman Group)

Jakob Nielsen a prouvé mathématiquement que les tests avec 5 utilisateurs révèlent 85 % des problèmes d’utilisabilité. Vous n’avez pas besoin de 50 utilisateurs.

L’utilisateur 1 trouve les bloqueurs critiques (la connexion est interrompue).
L’utilisateur 2 les confirme.
L’utilisateur 3 les confirme.
L’utilisateur 6 ajoute très peu de nouvelles informations (rendements décroissants). Stratégie : exécutez souvent de petits tests. Testez avec 5 utilisateurs. Corrigez les bugs. Testez à nouveau avec 5 utilisateurs. Boucle itérative >> Étude massive.

Le point de vue du sceptique

“Nous n’avons pas le temps. Nous avons une date limite.” Contre-point : Si vous lancez un produit déroutant, vous passerez des mois à le réparer et à gérer les tickets d’assistance. “Comment réinitialiser mon mot de passe ?” -> Si 100 personnes demandent cela, vous avez un bug UX. Un test utilisateur d’une heure peut économiser 1 mois de retouche technique. Les tests utilisateur accélèrent le produit viable, même s’ils retardent d’un jour la première version. C’est une stratégie de réduction des risques.

##FAQ

Q : Qui devrions-nous recruter ? R : Des personnes qui correspondent à votre personnalité. Si vous vendez du SaaS pour les dentistes, ne testez pas avec les adolescents. Leur modèle mental est différent. Si vous vendez du dentifrice (consommateur), testez-le auprès de n’importe qui.

Q : Qu’est-ce que les tests A/B par rapport aux tests utilisateur ? Les tests A/B (Split Testing) sont quantitatifs. « Quelle couleur de bouton convertit le mieux ? Rouge ou vert ? » Les tests utilisateurs sont qualitatifs. « Pourquoi ont-ils cliqué sur Rouge ? » Utilisez les tests utilisateur pour générer des hypothèses. Utilisez les tests A/B pour les valider à grande échelle.

Conclusion

La gestion de produits sans tests utilisateurs est une hallucination. L’ingénierie sans tests utilisateur est une vanité. Vous construisez pour les gens. Parlez-leur. Regardez-les. Cela vous humiliera. Et cela rendra votre produit supérieur. Sortez du bâtiment.

Les utilisateurs sont confus ?

Si votre boîte de réception d’assistance est pleine de « Comment puis-je faire X ? » ou si votre taux de désabonnement est élevé, votre UX est cassée. Maison Code effectue des recherches UX professionnelles et des tests d’utilisabilité. Nous recrutons les bons utilisateurs, écrivons les scripts, facilitons les sessions et fournissons des « Highlight Reels » exploitables des moments exacts où les utilisateurs sont bloqués.

Engagez nos Architectes.