En une phrase : un bon design disparaît ; un mauvais design oblige l’utilisateur à demander « pourquoi ? ».
0. Résumé en cinq secondes
Dans un jeu de cartes compétitif, monter en rang et ne pas trouver d’adversaire un après-midi calme est compréhensible. Le problème change lorsque chaque échec oblige l’humain à appuyer sur Réessayer. Ce devrait être du PvP, mais le premier combat se déroule contre l’interface.
La règle : ne me faites pas combattre en dehors du match. Les humains prédisent ce qui devrait normalement suivre et quelle structure serait logique pour un objectif. Lorsque réalité et modèle divergent, apparaît le « hein ? », « pourquoi ? », « quelque chose cloche ».
Nous appelons cela, comme étiquette pratique, détection d’incohérence structurelle. Ce n’est pas un terme psychologique officiel ; il relie prediction error, expectancy disconfirmation, processing fluency, Person–Environment Fit, Expectancy Violations Theory et intuition experte.
Le malaise est une alarme, pas un verdict sur sa cause.
1. L’origine : le premier boss était Réessayer
Rang supérieur → peu de joueurs → matchmaking échoue → réessayer → encore → encore. L’UI ne fabrique pas de joueurs, mais elle peut poursuivre la recherche ou relancer automatiquement.
La plainte devient « pourquoi suis-je l’opérateur du matchmaking ? » Un jeu devrait demander de penser aux cartes, au tempo, au risque et à la victoire, pas offrir un deuxième emploi de Technicien de Relance Manuelle.
Ne transformez pas les humains en cron jobs. J’ai lancé un jeu, pas postulé à UI Operations.
2. Le principe : supprimer le PvE hors objectif
Ne transformez pas une friction étrangère à l’objectif en travail utilisateur. Acheter et combattre l’inscription, réserver et combattre l’interface, travailler et chercher l’approbateur, automatiser puis surveiller chaque jour l’automatisation, discuter et faire de la rétro-ingénierie sur des règles invisibles : tout cela est du PvE hors objectif.
Personne ne veut le succès « Formulaire de paiement vaincu ». Un bon service ne fabrique pas d’ennemis supplémentaires.
3. La grande qualité ressemble souvent à « rien de spécial »
La porte s’ouvre, le paiement passe, la recherche trouve, l’étape suivante est claire, on sait qui décide, la conversation avance. Fin. Avis : normal.
La recherche sur la processing fluency étudie comment la facilité de traitement se relie à l’agrément, la confiance et la familiarité. La recherche sur les services montre aussi l’importance de la relation entre attentes et expérience.
Un système mature devient transparent. Un système immature se présente bruyamment : cliquez ici, revenez, voyez un autre service. Le mauvais design se présente trop fort ; le bon design réduit sa propre présence.
4. « Quelque chose cloche » en langage de recherche
Prediction error : une méta-analyse de 264 études de neuro-imagerie a examiné l’erreur de prédiction dans la récompense, la punition, l’action, la cognition, la perception et l’inférence sociale. Version courante : « Ah, c’est ça qui arrive maintenant ? »
Expectancy disconfirmation : une méta-analyse de 2024 a réuni 150 enregistrements, 168 études indépendantes et 58 597 participants. La performance compte, mais l’écart entre attente et expérience aussi.
Processing fluency : facile à lire, trouver, comprendre et prévoir. N’utilisez pas le cerveau du client comme CPU auxiliaire gratuit.
Person–Environment Fit : un excellent environnement ne convient pas à tout le monde. Une chaussure chère fait mal si la taille est mauvaise.
Expectancy Violations Theory : un comportement qui rompt les attentes interpersonnelles attire l’attention ; une surprise positive peut aussi être une violation.
5. Cinq incohérences structurelles
- Objectif–moyen : vouloir aller vite et ajouter trois validations.
- Responsabilité–autorité : « décide » puis « pourquoi sans permission ? ». Champ de mines vendu comme autonomie.
- Paroles–comportement : « nous valorisons l’expérimentation » puis punir longtemps un échec. L’affiche et le terrain semblent appartenir à deux entreprises.
- Évaluation–résultat : vouloir la productivité mais récompenser les heures visibles ; vouloir la qualité mais pénaliser les signalements. Les gens optimisent la façon de marquer des points.
- Humain–système : clics répétés, double saisie, lancement manuel, surveillance de « rien ne s’est produit ». Ne transformez pas les humains en cron jobs.
6. Comment fonctionne le détecteur
Comprendre l’objectif → prévoir une structure raisonnable → observer la réalité → détecter l’écart → demander pourquoi → vérifier causes, critères et responsabilités → redessiner.
Voir la friction ne signifie pas être négatif. Mais une fois une étape inutile repérée, elle reste visible. Le petit caillou dans la chaussure devient le héros de toute la promenade. Le monde reste en UI Debug Mode.
7. Services : ne transformez pas l’UI en boss fight
Cherchez la ressaisie, les confirmations inutiles, la récupération manuelle d’échecs prévisibles, les formulaires qui effacent les données, les actions principales floues, les codes sans cause et les questions sur des informations déjà connues.
La micro-friction répétée peut dominer l’expérience. Un service mature ne demande pas seulement « que pouvons-nous ajouter ? », mais « qu’est-ce que l’utilisateur pourrait ne plus avoir à remarquer ? »
8. Environnements : ne réparez pas les institutions cassées avec la volonté humaine
On ignore qui décide → on demande au vétéran. Pas de définition de fini → on lit l’ambiance. Systèmes non intégrés → Excel sert de colle. Planning cassé → quelqu’un surveille chaque jour.
Que le travail soit terminé ne prouve pas que le système est sain. Les humains corrigent peut-être en temps réel un système défectueux. Plus l’équipe est compétente, plus un mauvais processus peut survivre. Entraide infernale.
9. Personnes : le malaise n’est pas de la télépathie
Contradictions répétées, règles mouvantes et responsabilité qui se déplace toujours dans le même sens méritent observation. Mais observer une incohérence ne prouve pas une mauvaise intention.
Séparez faits, prédiction, écart, explications alternatives et prochaine vérification. Le malaise est un détecteur de fumée, pas la photo de l’incendiaire.
10. Quand faire confiance à l’intuition experte
Kahneman et Klein ont souligné en 2009 l’importance de régularités apprenables et de beaucoup de pratique avec un feedback significatif. Si les règles changent tout le temps, si les résultats sont difficiles à vérifier ou si le hasard domine, l’expérience ne garantit pas une intuition juste.
Notez aussi les erreurs. Ne construisez pas un site d’avis de votre mémoire qui n’affiche que cinq étoiles.
11. Transformer le malaise en amélioration
Écrire l’objectif → décrire le processus actuel → trouver le combat hors objectif → demander pourquoi un humain le fait → vérifier technologie, sécurité, coût, politique et legacy → supprimer, automatiser, regrouper ou rendre visible → mesurer si les « pourquoi ? » diminuent.
12. Why Count
Comptez : pourquoi cliquer ?, pourquoi ressaisir ?, pourquoi demander à cette personne ?, pourquoi vérifier manuellement ?, pourquoi cette règle existe ?
0 : transparent. 1–2 : fluide. 3–5 : le système vole la vedette. 6+ : l’utilisateur vit de l’exploitation-maintenance, pas le produit. Ce n’est pas une échelle académique validée, mais elle révèle des frictions concrètes.
13. « Normal » est un produit de luxe
Les portes doivent s’ouvrir, l’électricité fonctionner, la recherche trouver, le paiement finir, les responsabilités être compréhensibles et les relations ne pas exiger une reconstruction permanente des règles.
Un excellent système reçoit donc parfois seulement « normal ». Derrière ce normal se cachent exceptions, tests, documentation et amélioration. Le meilleur design cache à quel point il a été difficile à construire. Un restaurant n’annonce pas « la cuisine n’a pas brûlé aujourd’hui » ; il sert le dîner.
14. Conclusion : le bon design disparaît
Le malaise ne prouve ni que le monde a tort ni que vous avez raison. Il indique d’abord que votre modèle interne et la réalité observée ne correspondent pas.
Détecter → séparer observation et interprétation → classer → tester la cause → enlever la friction → faire disparaître le « pourquoi ? ».
Ne me faites pas combattre en dehors du match. Ne me faites pas travailler en dehors du travail. Ne me faites pas assurer l’exploitation-maintenance juste pour vivre. Ne transformez pas l’utilisateur en débogueur gratuit de votre système.
