Vérification de la qualité UX

Que fait Vérification de la qualité UX ?

Vérifie les surfaces UI touchées par une modification par rapport aux règles dans references/rules.md. Chaque règle contient une raison, une vérification dans le code, une vérification dans le navigateur et une correction. Le tableau en haut de ce fichier indique à quels types de modification chaque règle s'applique.

1. Trouver la modification

1. Obtenez le diff nommé par la requête : une PR, une branche, un commit ou les modifications non commitées. Sans nom, utilisez les modifications non commitées. S'il n'y en a pas, utilisez la branche par rapport à sa base de fusion avec la branche par défaut (git diff $(git merge-base HEAD origin/HEAD)...HEAD). Si la branche est la branche par défaut, utilisez le dernier commit. Indiquez dans le rapport quel diff vous avez vérifié.
2. Listez les fichiers UI modifiés : composants, templates, styles, et les chaînes et props qu'ils rendent. Une modification d'un composant partagé ou d'un token est aussi une modification UI.
3. Si aucun fichier dans le diff ne rend d'UI (uniquement du code serveur, des tests, de la configuration ou de la documentation), dites-le en une ou deux phrases et arrêtez-vous. Ne rapportez aucun résultat.

2. Lire les propres règles UI du dépôt, et cartographier les surfaces

Les règles d'un dépôt ont priorité sur les valeurs par défaut du catalogue.

• Lisez la documentation agent du dépôt (AGENTS.md, CLAUDE.md, un README de design system) pour une section « Règles UI » ou similaire. Notez chaque contrôle, token ou composant qu'ils nomment pour une règle, comme une aide pour les dialogues, un bouton asynchrone, des tokens de type ou une marque IA. Une correction nomme ce composant.
• Cherchez les propres vérifications UX du dépôt : une cible make ux-check ou ux:check, un script de mise en page ou d'accessibilité, des règles de lint, ou des tests qui parcourent les sources pour des règles UI. Exécutez chacun de ceux qui couvrent la modification et utilisez leur sortie comme preuve.

Ensuite, cartographiez chaque fichier modifié vers les surfaces qu'un utilisateur voit : la route, la vue et le contrôle. Un composant partagé correspond à chaque surface qui l'utilise. Nommez une surface comme un utilisateur la trouve (« Page de révision, formulaire Ajouter un commentaire »). Pour chaque surface, notez :

• Types. Étiquetez la surface avec chaque type dans la légende de references/rules.md que le diff ajoute ou modifie : write, data, form, list, control, overlay, layout, route, copy, chart, style. Un nouveau style de survol est control et list. Un bouton d'enregistrement est write.
• États. Vide, chargement, en attente, erreur, survol, focus, sélectionné et désactivé. La plupart des résultats se trouvent dans un état que l'auteur n'a pas ouvert.

3. Exécuter les vérifications

Pour chaque surface, exécutez chaque règle dont le champ « S'applique à » partage un type avec la surface. Lisez la section de la règle avant de la vérifier. Notez chaque règle ignorée et la raison.

Lisez d'abord le code. La section « Vérification dans le code » de chaque règle indique quoi chercher. Cela attrape la plupart des défauts et ne nécessite pas de navigateur. Avant de signaler un état manquant, lisez les composants que le code appelle : un wrapper (un bouton asynchrone, un hook de formulaire, un parent qui passe pending) le gère souvent.

Ensuite, mesurez dans le navigateur, quand vous le pouvez. Une page HTML statique s'ouvre depuis le disque avec une URL file://. Pour une application, cherchez un serveur de développement en cours d'exécution, ou démarrez-en un avec la commande documentée du dépôt. Utilisez l'outil de navigateur que l'hôte vous donne : un panneau de navigateur intégré, un script Playwright ou Chrome sans tête. Si la page demande une connexion, demandez à l'utilisateur de se connecter dans ce navigateur. Ne tapez aucun identifiant vous-même.

Chargez scripts/measure.js dans la page. Il définit les aides nommées par la section « Vérification dans le navigateur » de chaque règle, et references/rules.md liste ce que chacune retourne. Collez-le à nouveau après chaque chargement de page. Vérifiez chaque thème et chaque schéma que l'application propose, et au moins une largeur de téléphone et une largeur de bureau.

Mesurez également chaque ligne, carte et contrôle modifié dans ses états d'interaction. Un état de survol, focus ou sélectionné ajoute souvent un remplissage, une bordure, une ombre ou un contrôle. Deux éléments encadrés se touchent alors, un élément grandit et déplace ses voisins, ou une action uniquement au survol pousse un compteur hors d'alignement. Pour chaque liste, groupe de cartes ou groupe de contrôles sur la surface :

1. Exécutez snapshot(sel, « rest ») et gaps(sel) avec les éléments au repos.
2. Survolez un élément avec l'outil navigateur, puis exécutez à nouveau snapshot(sel, « hover ») et gaps(sel). Faites de même avec le focus clavier (appuyez sur Tab), et avec l'élément sélectionné à côté d'un élément survolé.
3. Exécutez moved(« rest », « hover »). Un écart de 0px entre deux éléments encadrés, ou un élément qui a bougé quand un autre a été survolé, est un résultat.

Faites de même autour de chaque action qui ouvre un menu, un popover ou un panneau : prenez un instantané des blocs principaux, ouvrez-le, prenez un nouvel instantané, et comparez. Dans le code, lisez chaque règle :hover, :focus-visible et les règles de classe sélectionnée pour les propriétés qui ajoutent une boîte ou modifient la taille : background, border, box-shadow, padding, margin, width et display.

Sans navigateur, ou sans page à ouvrir, rapportez les résultats du code et listez les vérifications du navigateur qui n'ont pas été exécutées.

4. Vérifier chaque résultat

Avant de signaler un résultat, vérifiez-le une fois de plus :

• Résultat du code. Confirmez qu'un utilisateur peut atteindre l'état : la branche s'exécute, la prop est passée, et aucun wrapper ou parent ne le gère.
• Résultat du navigateur. Mesurez-le une deuxième fois, après un rechargement, dans l'état nommé par le résultat. Ignorez une valeur qui ne se répète pas.
• Dans la modification ou avant. Un défaut sur une ligne que le diff a ajoutée ou modifiée appartient à la modification. De même pour un état que le diff ajoute sans son pendant, même si la ligne manquante irait ailleurs : une nouvelle règle :hover sans règle :focus-visible, ou un nouvel élément d'écriture sans état en attente. Un défaut sur une ligne que le diff n'a pas touchée existait avant. Signalez-le sous « Défauts existants », séparément des résultats de la modification, et uniquement s'il se trouve sur une surface modifiée.

Ignorer un résultat qui échoue à sa vérification. Signalez un résultat que vous n'avez pas pu vérifier comme « Non confirmé », avec la raison.

5. Signaler les résultats

Commencez par une ligne qui nomme le diff vérifié et les surfaces. Ensuite, donnez un résultat par défaut, du plus grave au moins grave. Gravité :

• Élevée : l'utilisateur perd des données ou une saisie, envoie une écriture en double, ne peut pas atteindre un contrôle, ou ne peut pas lire le texte.
• Moyenne : le contrôle est trompeur (mauvaise icône, état uniquement coloré, marque IA manquante) ou la mise en page est visiblement cassée.
• Faible : incohérence avec le système du dépôt (valeurs de type brutes, contrôles de sélection mélangés, contenu de remplissage).

Chaque résultat comporte quatre parties :

Partie	Contenu
Surface	La vue et le contrôle, plus le fichier et la ligne (ReviewForm.tsx:42)
Règle	L'identifiant de la règle du catalogue, ou la règle du dépôt qu'elle enfreint
Preuve	Ce que vous avez lu ou mesuré : la ligne de code, les valeurs mesurées, l'état, le thème et la largeur
Correction	La modification, en une ou deux phrases, avec le composant ou token du dépôt s'il en nomme un

Exemple :

Surface : Barre latérale Stack, liste de filtres d'auteurs (AuthorList.tsx:58) Règle : no-cramped-controls Preuve : gaps(« .author-row ») à 1440px, avec la ligne 2 survolée : y: 0 entre la ligne 1 (sélectionnée) et la ligne 2. Au repos, l'écart est également 0, mais seule la ligne sélectionnée dessine une boîte. Correction : Ajoutez gap: 2px à la liste, ou insérez le remplissage de survol de 2px.

Ajoutez ensuite ces sections :

1. Défauts existants : les défauts de l'étape 4 que la modification n'a pas introduits, une ligne chacun.
2. Non vérifié : les règles ignorées et pourquoi, ainsi que les vérifications du navigateur qui n'ont pas été exécutées.

Lorsque l'utilisateur demande des corrections, faites-les, puis exécutez à nouveau les mêmes vérifications sur les mêmes surfaces.