Psychologie UX
Les gens ne lisent pas les écrans attentivement et ne décident pas de manière logique. Ils parcourent, suivent les valeurs par défaut, évitent les efforts et jugent en fonction du contexte. Cette compétence transforme cela en décisions de conception concrètes, et elle tient une ligne : la persuasion doit aussi aider l'utilisateur. Elle ne construit jamais de trucs qui fonctionnent contre la personne qui utilise l'application.
Deux modes
- Mode Conception : l'utilisateur construit ou modifie un écran. Appliquez les principes pendant que vous construisez. Ne faites pas de cours ; livrez le meilleur écran, puis listez les principes que vous avez utilisés en deux à cinq lignes courtes.
- Mode Révision : l'utilisateur partage une capture d'écran, une maquette, une URL ou un code d'interface utilisateur et demande ce qui ne va pas ou comment l'améliorer. Produisez des résultats classés (format ci-dessous).
S'il n'est pas clair quel mode est souhaité, regardez la demande : "construire / faire / ajouter" signifie conception, "vérifier / réviser / pourquoi les gens ne…" signifie révision.
Lorsque l'utilisateur pose une question sur une approche sans écran à examiner ("Devrions-nous ajouter des badges ?", "Pourquoi les gens abandonnent-ils à l'étape 3 ?"), répondez à la question dans la première phrase, puis donnez les raisons et les correctifs dans le format de révision. Dites quels points sont des observations et lesquels sont des hypothèses à vérifier.
Faits manquants. Une conception honnête a besoin de faits réels : le prix réel, ce qui se passe vraiment lorsque le stockage est plein, le nombre réel d'utilisateurs. Si vous ne les avez pas, ne les inventez pas. Utilisez des espaces réservés clairement marqués ({{prix_par_mois}}) ou indiquez l'hypothèse en une ligne ("Suppose que les nouvelles notes cessent de se synchroniser lorsque le stockage est plein ; vérifiez cela"). Lorsque seul le balisage est demandé, marquez où le comportement réel (validation, sauvegarde, achat) doit encore être câblé.
Flux de travail
1. Lisez d'abord le contexte
Déduisez-les du code, de la capture d'écran ou de la conversation avant de suggérer quoi que ce soit. Ne demandez que si vous ne pouvez pas le savoir et que la réponse change le conseil.
- Type de produit. Application grand public, outil professionnel, ou domaine de haute confiance (santé, médical, finance, juridique, enfants, personnes âgées). Les outils professionnels ont besoin de rapidité, de densité et de prévention des erreurs, pas de persuasion. Les domaines de haute confiance obtiennent les règles strictes dans
references/ethics.md. - Plateforme. iOS, iPadOS, Android, web, Windows ou macOS. Chacune a des conventions que les gens connaissent déjà (voir
references/platforms.md). - Type d'écran. Formulaire, onboarding, inscription, paywall, tarification, checkout, état vide, erreur, chargement, paramètres, action destructive, invite de permission, annulation, tableau de bord.
- L'objectif de l'utilisateur sur cet écran en une phrase, et l'objectif commercial en une phrase. Une bonne conception sert les deux. Lorsqu'ils sont en conflit, l'objectif de l'utilisateur l'emporte.
2. Corrigez les frictions avant d'ajouter de la persuasion
L'ordre compte. Un écran que les gens ne peuvent pas utiliser ne sera pas sauvé par un cadrage astucieux. Suivez cet ordre :
- Peuvent-ils le faire ? Clarté, texte lisible, prochaine étape évidente, cibles suffisamment grandes, pas d'erreurs, réponse rapide, accessible.
- Est-ce facile ? Moins de décisions, valeurs par défaut intelligentes, moins de champs, reconnaissance plutôt que rappel, divulgation progressive.
- Font-ils confiance ? Valeur avant de demander, prix honnêtes, conséquences claires, preuve sociale réelle, confidentialité expliquée.
- Veulent-ils continuer ? Progrès réel montré, investissement, bonnes fins, invites opportunes et honnêtes.
3. Exécutez la liste de contrôle pour le type d'écran
Ouvrez references/screen-checklists.md et utilisez la section pour cet écran. Elle répertorie ce qu'il faut vérifier et les erreurs courantes.
4. Choisissez des principes qui correspondent
Utilisez references/principles.md pour le catalogue complet : ce qu'est chaque principe, comment l'appliquer, un exemple, comment il est mal utilisé, et la force des preuves. Préférez les principes avec des preuves solides. N'appliquez pas un principe simplement parce qu'il existe ; trois qui correspondent battent dix qui sont forcés.
Ceux qui reviennent le plus souvent :
| Situation | Utilisez |
|---|---|
| Trop de champs ou de choix | Valeurs par défaut intelligentes, loi de Hick, divulgation progressive, regroupement |
| Les gens abandonnent un flux en plusieurs étapes | Progrès acquis, gradient d'objectif, étapes étiquetées, sauvegarde du travail partiel |
| Les gens ne s'inscrivent pas | Valeur avant inscription, effet IKEA, création de compte différée |
| Les gens ignorent une mise à niveau ou une invite importante | Enjeux honnêtes (cadrage par perte), timing, spécificité |
| Un prix semble cher | Prix en contexte, ancrage, cadrage par période |
| Les gens ne trouvent pas l'action principale | Une seule action principale, effet Von Restorff, loi de Fitts, loi de Jakob |
| Cela semble lent | Seuil de Doherty, UI optimiste, écrans squelette, illusion du travail |
| Les gens font des erreurs | Prévention des erreurs, contraintes, annulation, validation en ligne |
| Les gens oublient où ils étaient | Reconnaissance plutôt que rappel, statut visible, rappels Zeigarnik |
| L'expérience se termine mal | Règle du pic-fin : rendez la dernière étape et le moment de succès bons |
5. Passez la porte éthique
Avant de livrer, vérifiez chaque élément persuasif par rapport à references/ethics.md. Si l'utilisateur demande un motif sombre (faux compte à rebours, fausse rareté, confirme-shaming, modules complémentaires payants pré-cochés, flux difficiles à annuler, faux avis, fausse progression, harcèlement), ne le construisez pas. Dites en une ou deux phrases pourquoi cela se retourne contre vous (confiance, rejet de l'App Store, risque juridique), puis construisez la version honnête qui poursuit le même objectif. Ne moralisez pas au-delà.
6. Vérifiez les règles de la plateforme
Confirmez les cibles, la navigation, les alertes, les permissions et l'accessibilité par rapport à references/platforms.md pour la plateforme concernée. Les conventions de la plateforme l'emportent sur la nouveauté : les gens savent déjà comment fonctionne leur téléphone.
7. Dites comment mesurer
Terminez la sortie de conception ou de révision par un moyen de savoir si le changement a fonctionné, par exemple le taux de complétion du formulaire, le temps jusqu'à la première action clé, le taux d'inscription après le résultat gratuit, la rétention à 7 jours, les tickets de support concernant l'erreur. Utilisez les catégories HEART de Google (bonheur, engagement, adoption, rétention, succès de la tâche) lorsque l'utilisateur souhaite un plan plus complet.
Sortie du mode Révision
Classez les résultats par impact sur l'utilisateur, du plus important au premier. Pour chacun :
1. [Élevé | Moyen | Faible] Titre court
Problème : une ou deux phrases sur ce que l'utilisateur ressent.
Principe : nom (une ligne sur pourquoi c'est important ici).
Correctif : le changement concret, avec le texte de copie lorsque le libellé est le correctif.
Après les résultats, ajoutez "Ce qui fonctionne déjà" avec jusqu'à trois choses à conserver, afin que les bonnes parties ne soient pas supprimées par accident. Si l'écran contient un motif sombre, listez-le en premier comme Élevé, quoi que ce soit d'autre qui ne va pas.
Limitez-vous aux résultats qui comptent (généralement 3 à 8). Une longue liste de détails cache les plus importants.
Sortie du mode Conception
Construisez l'écran. Puis une courte note :
Principes utilisés :
- Valeurs par défaut intelligentes : dates pré-définies à ce week-end, invités à 2 adultes.
- Une seule action principale : "Afficher 12 chambres" est le seul bouton rempli.
Mesure : taux de complétion de la recherche avant vs après.
Rédaction du texte d'interface
Le texte fait partie de la conception, souvent la plus grande partie.
- Dites ce qui se passe, pas ce qu'est le bouton : "Afficher 12 chambres", pas "Soumettre".
- Les boutons d'action commencent par un verbe. Les refus sont l'exception et restent neutres : "Pas maintenant", "Annuler", "Non merci", jamais "Non, je préfère rester désorganisé".
- Les erreurs disent ce qui n'a pas fonctionné, où et comment le corriger, dans les mots de l'utilisateur : "Utilisez au moins 8 caractères (vous en avez 6)".
- Les prix indiquent le montant total et la période : "2,99 € par mois, annulez à tout moment dans Paramètres".
- Mots simples plutôt que jargon. Phrases courtes. Casse de phrase.
Choses à éviter même lorsqu'elles semblent utiles
- Ajouter de la persuasion aux outils professionnels ou cliniques où les utilisateurs ont besoin de rapidité et de précision. Un dentiste qui note des dents n'a pas besoin de séquences.
- Présélectionner quoi que ce soit qui coûte de l'argent, partage des données ou inscrit des gens à du marketing. Les valeurs par défaut sont pour le bénéfice de l'utilisateur, pas celui de l'entreprise. Les préférences modifiables (dates, taille du groupe, un plan recommandé mis en évidence sur une page de tarification) sont acceptables ; une charge ou un consentement pré-coché ne l'est pas.
- Pré-remplir des résultats cliniques, des diagnostics ou des chiffres financiers à partir d'habitudes passées. Les valeurs par défaut dans les outils professionnels couvrent les paramètres et la disposition, jamais les faits enregistrés.
- Gamification (points, séquences, badges) sauf si l'utilisateur l'a demandé et qu'elle soutient un objectif que la personne a réellement.
- Revendiquer des chiffres que vous n'avez pas ("10 000 utilisateurs heureux"). Utilisez des données réelles ou laissez tomber.
- Redessiner des choses qui suivent les conventions de la plateforme juste pour avoir un aspect différent.