Lois de l'UX — conseils et revues strictes

Lois de l'UX — index et protocole

Ce fichier sélectionne le mode, choisit lesquelles des 30 lois s'appliquent, et définit comment elles sont utilisées ensemble et comment rendre compte. Chaque loi vit dans son propre fichier sous references/, nommé comme dans les tableaux ci-dessous (fitts-law → references/fitts-law.md). Ouvrez uniquement ceux que vous sélectionnez.

Si l'utilisateur nomme une loi ("examiner ce formulaire selon la loi de Postel"), ouvrez simplement cette référence et utilisez-la dans le mode demandé. Les révisions suivent toujours la section 5 ici.

0. Fichiers et environnement

Cette compétence fonctionne dans tout agent capable de lire des fichiers. Elle ne dépend pas d'outils particuliers.

• Les chemins dans chaque fichier de cette compétence, y compris les références, sont relatifs au répertoire qui contient ce SKILL.md. references/fitts-law.md signifie toujours <répertoire_compétence>/references/fitts-law.md, même lorsqu'il apparaît à l'intérieur d'un autre fichier de référence.
• Si vous ne pouvez pas ouvrir les fichiers de référence (par exemple si ce texte a été collé dans une invite sans son dossier), dites-le et demandez les fichiers de loi dont vous avez besoin. N'effectuez pas de vérifications de mémoire : les identifiants de vérification, les sévérités et les types de preuves ne sont définis que dans ces fichiers.
• Les preuves dépendent de ce que vous pouvez inspecter. Si vous ne pouvez pas voir les images, les captures d'écran et les maquettes ne comptent pas comme preuve statique pour vous ; examinez tout texte ou code que vous avez et mentionnez-le dans la ligne de périmètre. Si vous ne pouvez pas exécuter l'artefact, les interactif et exécution sont hors de portée, sauf si l'utilisateur fournit des enregistrements ou des mesures.

1. Choisir le mode

Mode	Quand l'utiliser	Ce que vous produisez
Conseiller	Seulement un objectif, un briefing, un énoncé de problème, un élément de feuille de route ou un concept précoce existe.	Un court briefing d'orientation : les lois qui comptent le plus ici, les risques qu'elles prédisent, les questions auxquelles l'équipe doit répondre, et les décisions à prendre maintenant.
Construire	Un design ou une implémentation est en cours et a besoin d'une référence.	Des conseils ciblés pour le composant ou l'écran concerné, tirés du Mode 2 des lois pertinentes, avec des valeurs concrètes lorsqu'elles existent.
Réviser	Un design fini, un prototype, un ensemble de captures d'écran, une URL ou un diff de code est sur le point d'être validé.	Un rapport de constats strict avec sévérités, preuves, corrections et un verdict.

Si la demande ne le précise pas, déduisez-le de l'entrée : un objectif → Conseiller ; un travail en cours → Construire ; un artefact fini → Réviser. Si encore flou, posez une question.

2. Sélectionner les lois

N'ouvrez pas les 30 pour chaque tâche. Sélectionnez en fonction de la situation, puis ajoutez toutes celles dont les déclencheurs correspondent à ce que vous voyez.

Référence pour toute revue UI (toujours exécuter) : fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias. Ajoutez doherty-threshold chaque fois que l'artefact est interactif.

Par situation :

Situation	Ouvrir
Formulaires, saisie de données, inscription	postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect
Navigation, menus, architecture de l'information	hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle
Tableaux de bord, outils denses en données et experts	cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle
Visualisation de données et diagrammes	law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect
Intégration, première utilisation, aide	paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model
Tarification, forfaits, catalogues, paiement	choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule
Notifications, alertes, statut	selective-attention, von-restorff-effect, flow, zeigarnik-effect
Mobile et tactile	fitts-law, law-of-proximity, serial-position-effect, doherty-threshold
Performance, chargement, travail asynchrone	doherty-threshold, goal-gradient-effect, peak-end-rule, flow
Refontes et migrations	jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect
Automatisation, IA et fonctionnalités intelligentes	teslers-law, mental-model, cognitive-bias, doherty-threshold
Périmètre, priorisation, feuille de route	pareto-principle, occams-razor, teslers-law, hicks-law
Conception visuelle et travail sur le système de design	aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect
Erreurs, échecs et fins	peak-end-rule, postels-law, selective-attention, mental-model

Suivez les Lois connexes de chaque loi ouverte uniquement lorsqu'un constat ou une question touche effectivement cette loi.

3. Protocole Conseiller

1. Reformulez l'objectif, les utilisateurs et le contexte en deux ou trois lignes. Si les utilisateurs ou le contexte sont inconnus, dites-le — c'est le premier risque.
2. Sélectionnez 3 à 6 lois dans le tableau. Plus de six dilue le conseil.
3. Pour chacune, donnez les un ou deux risques qu'elle prédit pour ce projet et la question à laquelle l'équipe doit répondre. Utilisez le Mode 1 de la loi comme source, mais rendez-la spécifique.
4. Listez les décisions à prendre maintenant (budgets, valeurs par défaut, conventions, règles d'accentuation, mesure) et qui devrait les posséder.
5. Signalez les tensions entre les lois qui nécessiteront un choix délibéré (voir section 6).

Tenez-vous-en à environ une page. Le but est d'orienter, pas de pré-concevoir.

4. Protocole Construire

1. Identifiez le composant, l'écran ou le flux en cours de travail.
2. Ouvrez les lois correspondantes et utilisez leurs listes Mode 2 comme référence, en citant des valeurs concrètes (tailles de cibles, temporisations, rapports de contraste, critères WCAG).
3. En cas de conflit entre les conseils, dites-le et recommandez une résolution pour ce cas.
4. N'effectuez pas la révision complète pendant la construction ; mentionnez un problème de niveau Révision seulement s'il s'agit probablement d'un Bloquant.

5. Protocole de révision (strict)

Les révisions existent pour arrêter les problèmes avant la validation. Règles de stricteur :

• Preuve ou ça n'a pas réussi. Une vérification réussit seulement sur une preuve positive dans l'artefact. Ne supposez jamais un état, une taille, un timing ou un comportement que vous ne pouvez pas voir.
• Non vérifiable signifie NON VÉRIFIÉ, pas réussi. Nommez ce dont vous auriez besoin (un état d'erreur, une mesure, des données réelles, un appareil, le code).
• Le périmètre est déclaré, jamais implicite. Un verdict couvre seulement la preuve qui vous a été donnée. Les vérifications qui nécessitent un type de preuve que vous n'avez pas reçu sont listées comme hors de portée, de sorte qu'une révision de capture d'écran ne peut pas être interprétée comme une réussite complète.
• N'adoucissez pas. Pas d'éloges superflus, pas de "globalement, ça a l'air super", pas de dégradation de la sévérité à cause des délais ou des efforts déjà dépensés.
• Soyez spécifique. Chaque constat nomme l'emplacement (écran, composant, élément, ou fichier:ligne), ce que vous avez observé, et une correction concrète.
• Un problème, un constat. Si plusieurs lois signalent le même problème, rapportez-le une fois, listez tous les identifiants de vérification, et utilisez la sévérité la plus élevée.
• Rapportez clairement les lois sans constat. Listez les lois qui ont été appliquées sans constat, afin que la couverture soit visible.

Étapes :

1. Inventoriez ce qui vous a été donné (écrans, états, points de rupture, code) et ce qui manque, et définissez le périmètre des preuves : lesquels des types de preuves ci-dessous vous avez.
2. Sélectionnez la base plus les lois situationnelles.
3. Exécutez chaque vérification dans le tableau Mode 3 de chaque loi sélectionnée. Classez chaque vérification dans l'une des catégories suivantes :
   • vérifié — réussi ou a produit un constat ;
   • non vérifié — son type de preuve est dans le périmètre, mais l'état, l'élément ou la mesure dont il a besoin manque (par exemple périmètre statique, mais pas d'écran d'état d'erreur) ;
   • hors de portée — aucun de ses types de preuves n'est dans le périmètre ;
   • non applicable — l'artefact n'a rien à quoi la vérification se rapporte (par exemple FIT-1 sur un outil de bureau uniquement souris). Donnez la raison en quelques mots.
4. Fusionnez les doublons, attribuez la sévérité, rédigez les corrections.
5. Donnez le verdict, avec son périmètre.

Types de preuves

Chaque vérification Mode 3 a une colonne Preuve nommant les types d'entrée qui peuvent la résoudre. Lorsqu'elle en liste plus d'un, n'importe lequel d'entre eux suffit.

Type	Ce que c'est	Entrées typiques
statique	Ce qui peut être vu dans des images fixes des écrans et états pertinents.	Captures d'écran, maquettes statiques, fichiers de design avec mesures, tableaux de flux
interactif	Ce qui se montre seulement quand on opère la chose : clavier, focus, transitions, timing tel qu'expérimenté, ce qui se passe après une action.	Un prototype cliquable, un build en cours, une URL, un enregistrement d'écran
code	Ce qui est dans la source ou le balisage : sémantique, ARIA, autocomplete, zones de clic, tokens, et comportement que la source fixe sans ambiguïté (ce qu'un gestionnaire fait en cas d'erreur, si l'entrée est conservée, où va le focus).	Un diff, source de composant, DOM rendu
exécution	Mesures sur du matériel, des réseaux et des données réalistes.	Traces de performance, chiffres RUM ou de laboratoire
contexte	Faits en dehors de l'artefact : données d'utilisation, recherche, enregistrements de décisions, règles métier.	Analytique, résultats de recherche, un PRD ou ADR, une déclaration de l'équipe

Considérez un type de preuve comme dans le périmètre seulement si vous l'avez réellement. Être informé que le code existe ne met pas code dans le périmètre.

Sévérité

Sévérité	Signification
Bloquant	Empêche ou induit en erreur dans une tâche fondamentale ; risque de perte de données, dommage financier, de sécurité ou de sûreté ; échoue à un critère WCAG 2.2 AA ; ou est un motif trompeur. Doit être corrigé avant validation.
Majeur	Frottement significatif, conception sujette aux erreurs, ou incohérence claire avec les conventions ou le système de design. Corriger avant validation, ou enregistrer une acceptation explicite par un propriétaire nommé avec un suivi.
Mineur	Polissage et cohérence. Corriger lorsque la zone sera retravaillée.

Verdict

Appliquez la première règle qui correspond :

1. Tout Bloquant → Ne pas valider.
2. Toute vérification Bloquante dans le périmètre est NON VÉRIFIÉE → Bloqué en attente de preuve. Nommez l'état ou la mesure manquant(e), que l'équipe aurait pu fournir avec les preuves déjà données.
3. Tout Majeur → Valider seulement avec chaque Majeur corrigé ou accepté par un propriétaire nommé.
4. Seulement Mineur ou aucun → Réussi.

Chaque verdict porte son périmètre, par exemple Réussi (périmètre statique). Si des vérifications Bloquantes sont hors de portée, listez-les sur la ligne du verdict avec le type de preuve dont chacune a besoin, par exemple hors de portée : JAK-1 (interactif), SA-2 (interactif), DOH-1 (interactif). Un verdict peut être non qualifié (juste "Réussi") seulement lorsqu'aucune vérification Bloquante des lois sélectionnées n'est hors de portée ou non vérifiée. Les vérifications hors de portée ne changent jamais le verdict. Elles disent à l'équipe ce qui n'a pas encore été révisé, et si cela nécessite un second passage avec plus de preuves avant la sortie.

Modèle de rapport

## Revue des lois UX — <nom de l'artefact>

Révisé : <ce qui a été révisé : écrans, états, points de rupture, fichiers>
Périmètre des preuves : <statique | interactif | code | exécution | contexte — ceux effectivement fournis>
Non fourni : <états ou preuves manquants>
Lois appliquées : <codes>
Verdict : <Ne pas valider | Bloqué en attente de preuve | Valider avec Majeurs acceptés | Réussi> (périmètre <périmètre>)
         hors de portée : <identifiants de vérification Bloquante avec le type de preuve dont chacun a besoin, ou "aucun">

### Bloquants
- [BLOQUANT] FIT-1, JAK-1 · <emplacement> — <observation> → <correction>

### Majeurs
- [MAJEUR] CL-2 · <emplacement> — <observation> → <correction>

### Mineurs
- [MINEUR] SIM-6 · <emplacement> — <observation> → <correction>

### Non vérifié (dans le périmètre, preuve manquante)
- POS-2 · <ce qui n'a pas pu être vérifié> — nécessite <l'état ou la mesure spécifique>

### Hors de portée
- interactif : JAK-1, SA-2, DOH-1, …
- code : CH-3, PKL-3, …

### Non applicable
- FIT-1 — <raison>

### Appliqué sans constat
<codes>

6. Tensions communes

Tension	Résolution par défaut
Hick / Occam (moins d'options) vs Pareto longue traîne et besoins experts	Gardez les fonctions critiques mais rares trouvables via une divulgation progressive ; ne les supprimez jamais sur la seule base de l'utilisation.
Occam (supprimer) vs Tesler (complexité irréductible)	Supprimez la complexité incidente ; déplacez la complexité inhérente vers le système, avec visibilité et annulation.
Jakob (convention) vs différenciation	Innovez sur le problème, pas sur les contrôles fondamentaux. Les écarts nécessitent un avantage énoncé et testé.
Von Restorff (accentuation) vs Similarité (cohérence)	Un élément accentué par vue ; tout le reste cohérent.
Fitts (cibles grandes et pratiques) vs activation accidentelle	Séparez les actions destructrices ; ajoutez une annulation ou une confirmation pour les actions conséquentes.
Flux (pas d'interruptions) vs confirmations de sécurité	Interrompre seulement pour des actions irréversibles et conséquentes.
Charge cognitive (montrer moins) vs Mémoire de travail (montrer le contexte)	Montrez le contexte nécessaire pour l'étape en cours ; cachez le reste.
Postel (accepter libéralement) vs exactitude	Libéral dans le format, strict dans le sens ; confirmez les valeurs ambiguës et conséquentes.
Gradient d'objectif, Zeigarnik, Position sérielle, Von Restorff comme leviers vs intérêt de l'utilisateur	Utilisez seulement vers des résultats que l'utilisateur souhaite ; voir cognitive-bias.

7. Toutes les lois

Perception et attention

Loi	Code	Utilisez-la pour
aesthetic-usability-effect	AUE	le polissage visuel, les premières impressions, l'expression de la marque, l'interprétation des tests d'utilisabilité, et l'écart entre l'apparence d'un produit et son fonctionnement
law-of-common-region	CR	cartes, panneaux, sections, bordures, fonds de remplissage, lignes de tableau, groupes de formulaires et tout conteneur utilisé pour signaler que des éléments vont ensemble
law-of-proximity	PRX	espacement, densité de mise en page, association étiquette-champ, regroupement de contrôles et de contenu, et échelles d'espacement
law-of-pragnanz	PRG	icônes, illustrations, visualisations de données, silhouettes de mise en page, logos et tout visuel qui doit être compris en un coup d'œil
selective-attention	SA	notifications, alertes, changements de statut, bannières, astuces d'intégration, messages système, et placement d'informations que les utilisateurs ne doivent pas manquer
law-of-similarity	SIM	cohérence visuelle, styles de liens et de boutons, variantes de composants, couleurs de statut, familles d'icônes et utilisation du système de design
law-of-uniform-connectedness	UC	graphiques de réseau, diagrammes de flux, cartes mentales, tableaux avec éléments connectés, et tout cas où la connexion visuelle explicite par des lignes importe plus que la proximité
von-restorff-effect	VRE	mettre en évidence des éléments clés dans une liste, promouvoir une offre, signaler un changement, et attirer l'attention sur une étape critique dans un flux

Cognition et charge mentale

Loi	Code	Utilisez-la pour
cognitive-load	CL	toute interface où l'utilisateur doit apprendre, comprendre ou se souvenir d'informations en travaillant
working-memory	WM	formulaires, assistants en plusieurs étapes, saisie de données, comparaison d'options, et toute tâche qui oblige l'utilisateur à retenir des informations entre les étapes
chunking	CH	regrouper des entrées, structurer des listes, hiérarchiser des informations, et diviser des tâches en sous-tâches significatives
hicks-law	HK	menus, navigation, listes de choix, paramètres, et toute sélection parmi plusieurs options qui affecte le temps de décision
mental-model	MM	migration vers une nouvelle interface, apprentissage de fonctionnalités complexes, et garantir que le comportement du système correspond aux attentes des utilisateurs
paradox-of-the-active-user	PAU	intégration, aide dans l'application, documentation, tutoriels, et fonctionnalités que les utilisateurs sont susceptibles d'utiliser rarement ou superficiellement
cognitive-bias	CB	présentation des options, choix par défaut, cadrage des messages, utilisation de preuves sociales, et conception éthique en général
choice-overload	CHO	catalogues, plans tarifaires, paramètres, listes de fonctionnalités, et tout contexte où trop d'options réduisent la prise de décision

Interaction et retour d'information

Loi	Code	Utilisez-la pour
fitts-law	FIT	cibles tactiles, éléments de menu, boutons, liens, poignées de redimensionnement, tout élément avec lequel l'utilisateur clique ou tape
doherty-threshold	DOH	temps de réponse, animation, retour d'information, téléchargements, exécution de recherche, et toute interaction où l'utilisateur attend le système
parkinsons-law	PKL	formulaires, saisie de données, importations en masse, exécution par lots, et toute tâche qui s'étend pour remplir le temps qui lui est alloué
goal-gradient-effect	GG	barres de progression, étapes d'intégration, programmes de fidélité, vérifications en plusieurs étapes, et tout flux vers un objectif
peak-end-rule	PE	flux d'erreurs, écrans de fin, expériences de paiement, intégration, et toute interaction dont on se souviendra comme d'un épisode
serial-position-effect	SPE	navigation, listes, menus, sélecteurs d'onglets, sélection dans une timeline, et tout ensemble ordonné d'éléments
zeigarnik-effect	ZE	intégration, création de profil, flux multi-tâches, listes de tâches, et tout processus qui peut être interrompu puis repris

Modèles de système et de conception

Loi	Code	Utilisez-la pour
jakobs-law	JAK	navigation, mise en page, conventions de composants, placement des contrôles, et tout modèle que les utilisateurs apportent d'autres sites et applications
teslers-law	TES	automatisation, paramètres avancés, paramètres par défaut, conception orientée IA, et toute fonctionnalité qui traite de la complexité
postels-law	POS	saisie de formulaire, analyse de texte libre, importation de fichiers, intégrations API, et tout point où le système reçoit une entrée non structurée ou au format libre
occams-razor	OCC	épuration des fonctionnalités, priorisation des fonctionnalités, simplification de l'écran, et toute décision sur ce qu'il faut supprimer
pareto-principle	PAR	priorisation des fonctionnalités, optimisation des performances, analyses, et toute décision sur ce sur quoi se concentrer étant donné des ressources limitées
flow	FLW	interfaces de création et de conception, saisie de données en continu, outils professionnels, et toute tâche où l'utilisateur doit rester concentré
aesthetic-usability-effect	AUE	déjà listé sous Perception et attention
law-of-common-region	CR	déjà listé sous Perception et attention
law-of-proximity	PRX	déjà listé sous Perception et attention
law-of-pragnanz	PRG	déjà listé sous Perception et attention
selective-attention	SA	déjà listé sous Perception et attention
law-of-similarity	SIM	déjà listé sous Perception et attention
law-of-uniform-connectedness	UC	déjà listé sous Perception et attention
von-restorff-effect	VRE	déjà listé sous Perception et attention