Checklist de revue d'UI IA : tester les interfaces générées avant le déploiement

Ne commencez pas par cliquer au hasard pour recueillir des impressions. Définissez d'abord ce que cette revue est censée prouver. Sans ce contrat, les relecteurs ont tendance à inventer des exigences, à traiter un goût personnel comme un défaut, ou à accepter un écran attrayant dont la tâche principale ne se termine jamais.

• Tâche utilisateur : Énoncez le résultat en termes d'utilisateur, tel que « inviter un coéquipier et voir la confirmation », plutôt que « examiner la page des paramètres ».
• Exigences produit : Listez les actions approuvées, les permissions, les données, les règles de validation, les confirmations, le comportement d'annulation et les parcours de récupération applicables.
• Autorité de design : Précisez le fichier DESIGN.md, l'ensemble de design tokens, le fichier de thème, le guide des composants, le kit de référence ou le design approuvé qui régit l'interface.
• Artéfacts de livraison : Enregistrez comment ces décisions parviennent au projet, par exemple via des variables CSS, des valeurs de thème Tailwind, des tokens DTCG, un élément de registre shadcn/ui ou des fichiers générés.
• Plateformes et viewports : Incluez uniquement les navigateurs, appareils, largeurs de conteneurs et modes de couleur supportés par le produit.
• Données de test : Préparez des exemples réalistes : courts, typiques, longs, vides, invalides et restreints, selon la pertinence.
• États requis : Nommez les états inactif, chargement, succès, vide, erreur, désactivé, focus, sélectionné, ouvert et les états de permission que la tâche peut réellement atteindre.
• Exclusions : Notez le travail qui est hors du périmètre de cette version afin que son absence ne soit pas confondue avec un défaut.

Une interface générée peut réussir un type de revue et échouer à un autre. Séparez les preuves afin qu'un résultat visuel fort ne puisse pas masquer une tâche défaillante, et qu'une tâche fonctionnelle ne puisse pas excuser une implémentation inaccessible ou fragile.

Partez du résultat utilisateur et parcourez chaque branche requise. Un test réussi décrit un comportement observable, pas une impression.

• L'action principale est visible ou découvrable au moment où l'utilisateur en a besoin.
• Les libellés décrivent l'action résultante plutôt qu'une intention vague.
• La navigation préserve le contexte de l'utilisateur lorsque l'exigence le stipule.
• La validation identifie le champ ou l'action concernée et propose à l'utilisateur une étape suivante possible.
• Le succès produit la confirmation requise ou le changement d'état attendu.
• L'annulation laisse les données et la navigation dans l'état attendu.
• Les restrictions de permission empêchent l'action et expliquent ce que l'utilisateur peut faire ensuite.
• Les parcours de chargement, d'état vide, d'échec, de tentative de reconnexion et de récupération fonctionnent lorsqu'ils sont concernés.
• L'interaction au clavier permet d'atteindre et d'actionner les commandes de la tâche lorsque l'utilisation du clavier est prise en charge.

Rédigez les critères d'acceptation sous forme d'observations. Par exemple : « L'envoi d'une invitation valide désactive l'envoi en double, affiche la progression, renvoie un message de succès contenant l'adresse invitée et ajoute le membre en attente à la liste. » Cela peut être vérifié. « Le flux d'invitation semble intuitif » ne peut pas l'être.

Rapprochez les décisions visibles de l'autorité déclarée. Vérifiez les couleurs sémantiques, les rôles typographiques, l'espacement, la mise en page, les motifs, le traitement des composants et le comportement des modes. Notez les valeurs inexpliquées, mais ne supposez pas que chaque différence est une erreur. Une exception locale peut être intentionnelle, obsolète ou absente du système.

• Rôles sémantiques : Les composants utilisent des rôles tels que background, foreground, primary, border, ring, success, warning et destructive pour exprimer les significations prévues.
• Typographie : Les rôles heading, body, label, data et mono utilisent les familles, graisses, tailles, hauteurs de ligne et règles de casse déclarées.
• Espacement : Les écarts répétés suivent l'échelle documentée, sauf exception approuvée.
• Mise en page : La largeur de page, la grille, l'alignement, la densité et les transitions responsives correspondent aux règles déclarées.
• Composants : Les boutons, champs de saisie, cartes, tableaux, navigation, superpositions et traitements de feedback utilisent les variantes et les états prévus.
• Modes : Les valeurs claire et sombre conservent la même signification sémantique, et les exceptions spécifiques aux modes sont documentées.
• Motifs : Les traitements décoratifs n'apparaissent que là où l'autorité les autorise et n'interfèrent pas avec la signification ou l'interaction.
• Valeurs codées en dur : Les couleurs uniques, les déclarations de police, les rayons, les ombres et les valeurs d'espacement ont une justification documentée ou sont signalés pour correction.

Remplacez le contenu fictif par des données de test qui mettent la mise en page réelle à l'épreuve. Examinez la même tâche sur les viewports et les états requis au lieu de juger des captures d'écran séparées comme des compositions isolées.

• Utilisez des noms, dates, prix, statuts, descriptions et densités de données réalistes.
• Testez des libellés longs et des textes dont la longueur varie selon la traduction, sans modifier le sens prévu.
• Vérifiez les mises en page étroites et larges aux tailles de conteneur ou de viewport prises en charge.
• Vérifiez le retour à la ligne, la troncature, le débordement, les régions collantes (sticky), les superpositions et le comportement du défilement.
• Augmentez le zoom ou l'espacement du texte utilisateur et notez tout écrêtage, chevauchement, perte de contenu ou blocage des commandes.
• Utilisez chaque mode de couleur déclaré et tout paramètre de couleurs forcées pris en charge.
• Inspectez les états de focus, de survol, actif, sélectionné, désactivé, ouvert, de chargement, vide, d'erreur et de succès accessibles lors de la tâche.
• Répétez la tâche avec des données lentes ou défaillantes lorsque le produit prend en charge ces conditions.

Le mode couleurs forcées mérite sa propre observation lorsqu'il est pris en charge. Les navigateurs peuvent remplacer les couleurs définies par une palette choisie par l'utilisateur ; ainsi, une signification reposant uniquement sur un remplissage, une bordure ou une ombre personnalisée peut disparaître. Notez ce qui reste perceptible plutôt que de supposer que le thème ordinaire prédit le résultat.

Utilisez cette revue pour identifier les points de vigilance et collecter des preuves, mais limitez vos affirmations. L'inspection visuelle, la conformité des tokens, les vérifications automatisées et la critique par IA peuvent chacune trouver des problèmes. Aucune d'entre elles ne certifie l'accessibilité à elle seule.

• Notez l'ordre de tabulation, la visibilité du focus, le fonctionnement des commandes et le comportement du focus autour des superpositions.
• Vérifiez que les noms des commandes, les libellés visibles, les instructions, les erreurs et les changements d'état sont compréhensibles dans leur contexte.
• Vérifiez que l'information n'est pas transmise uniquement par la couleur ou la position visuelle.
• Observez le comportement du reflow, du zoom et de l'espacement du texte utilisateur sur les surfaces requises.
• Testez le contenu et les commandes pertinents dans les paramètres de contraste élevé ou de couleurs forcées pris en charge.
• Envoyez le balisage sémantique, le comportement des technologies d'assistance, les mesures de contraste et les questions de conformité formelle vers le circuit de revue approprié basé sur des preuves.

Choisissez des surfaces du produit que vous examinez. Une page d'accueil peut nécessiter une navigation, un formulaire et un feedback. Une application peut également nécessiter des vues de données, des vues de détail, des superpositions et des états de permission. Omettez les surfaces que le produit n'utilise pas.

1. 1

   Sélectionnez une tâche utilisateur

   Définissez un résultat et la condition de départ exacte. Gardez la tâche suffisamment restreinte pour pouvoir être répétée.

2. 2

   Sélectionnez une surface et un état représentatifs

   Choisissez l'état de navigation, de formulaire, de vue de données, de vue détaillée, d'overlay ou de feedback qui présente la conséquence la plus élevée ou qui expose une règle système distincte.

3. 3

   Appliquez un fixture fixe

   Enregistrez le viewport, le mode, le contenu, l'état du compte ou des permissions, ainsi que la condition des données. Réutilisez ce fixture après les modifications.

4. 4

   Rédigez le résultat attendu avant l'inspection

   Citez l'exigence ou la règle de design et décrivez le résultat observable. Si aucune autorité n'existe, arrêtez-vous et signalez l'écart.

5. 5

   Capturez l'observation et la preuve

   Enregistrez ce qui s'est passé, où cela s'est passé, ainsi que la plus petite capture d'écran, l'enregistrement, l'observation du DOM, la sortie de la console ou le résultat de test nécessaire pour le reproduire.

6. 6

   Attribuez la sévérité, le responsable et la décision

   Choisissez : passer, réviser ou bloquer. Dirigez la cause vers la couche appropriée au lieu d'attribuer chaque problème à l'implémentation générée.

Review ID: UI-REVIEW-____
Build or revision: ____
Reviewer: ____
Date: ____

User task: ____
Start condition: ____
Required outcome: ____
Surface: ____
Required state: ____
Viewport or container: ____
Color mode: ____
Input and content fixture: ____
Permission or account fixture: ____

Requirement authority: ____
Design-system authority: ____
Delivery artifact: ____
Expected rule or behavior: ____
Observed result: ____
Evidence reference: ____

Evidence track:
  - task completeness: pass | fail | not tested
  - design-system conformance: pass | fail | not tested
  - resilience: pass | fail | not tested
  - accessibility: pass | concern | not tested

Finding route: requirement | design system | delivery mapping | implementation | fixture
Severity: low | medium | high | release blocking
Owner of next decision: ____
Known limitation: ____
Disposition: pass | revise | block
Retest required: yes | no
Retest result: ____

Un défaut visible est souvent en aval de l'endroit qui doit être modifié. Corriger la règle CSS la plus proche peut valider un écran tout en conservant la même erreur pour la génération suivante.

• Écart de spécification produit : Le comportement prévu, la permission, la règle de contenu, la confirmation, l'annulation ou le parcours de récupération est manquant ou contradictoire. Exemple : personne n'a décidé si la suppression d'un membre nécessite une confirmation. Prochain responsable : décideur produit.
• Écart de source du design system : L'exigence est claire, mais le système faisant autorité manque d'un rôle ou d'une règle nécessaire pour l'exprimer de manière cohérente. Exemple : les actions d'avertissement et destructives n'ont pas de traitement distinct documenté. Prochain responsable : propriétaire du design system.
• Écart de livraison ou de mapping : La source contient la décision correcte, mais le token exporté, le mapping du framework, l'élément du registre, le fichier de thème ou l'artéfact installé perd ou attribue mal cette décision. Exemple : la source définit un rôle de focus ring, mais le thème livré mappe le composant à un rôle de border. Prochain responsable : propriétaire de l'artéfact ou de l'intégration.
• Défaut d'implémentation générée : Les exigences et les règles livrées sont suffisantes, mais l'interface générée les ignore, les remplace ou les implémente incorrectement. Exemple : un bouton code en dur une couleur au lieu d'utiliser le rôle destructif livré. Prochain responsable : propriétaire de l'implémentation ou opérateur de l'agent de code.
• Fixture de revue invalide : L'attente utilise des données non supportées, une plateforme exclue, le mauvais état de compte, un build obsolète ou une surface en dehors du contrat de release. Exemple : un réviseur attend une action admin tout en testant un compte en lecture seule. Prochain responsable : réviseur ou propriétaire du test.

Si plusieurs couches ont contribué, désignez la défaillance faisant autorité la plus précoce comme cause principale et listez les défauts en aval séparément. Cela évite qu'un correctif local ne masque une décision manquante.

L'inspection permet de savoir si l'instantané actuel semble lié à son système. Un changement contrôlé teste si cette connexion fonctionne toujours. Modifiez une seule décision bornée dans l'autorité déclarée, propagez-la via le circuit de livraison normal, et vérifiez à la fois la mise à jour prévue et les valeurs non liées.

1. 1

   Choisissez une décision sémantique

   Utilisez un rôle réversible et au périmètre restreint, tel que le background d'avertissement, le focus ring, le poids du titre ou l'étape d'espacement compact. Ne combinez pas plusieurs modifications.

2. 2

   Enregistrez l'état initial

   Capturez la valeur faisant autorité, la valeur livrée, les consommateurs prévus, le fixture représentatif et quelques valeurs proches qui doivent rester inchangées.

3. 3

   Modifiez l'autorité déclarée

   Effectuez la modification là où l'équipe affirme que la décision appartient. Modifier directement le composant rendu ne permet pas de tester la propagation.

4. 4

   Exécutez le circuit de livraison normal

   Régénérez, exportez, installez ou appliquez l'artéfact de la même manière que le projet reçoit habituellement les décisions de design.

5. 5

   Vérifiez la chaîne

   Confirmez que l'autorité, l'artéfact de livraison et le consommateur d'interface prévu contiennent la nouvelle décision.

6. 6

   Vérifiez l'absence de dérive non liée

   Comparez les rôles voisins enregistrés et les surfaces représentatives. Tout changement inexpliqué fait échouer le test, même si la cible a été modifiée correctement.

7. 7

   Restaurez ou approuvez la valeur de test

   Traitez le changement comme un test, à moins que le responsable ne l'approuve comme la nouvelle décision de design. Enregistrez l'état final dans la revue.

• Passer : Chaque tâche requise et chaque état représentatif respecte ses critères observables ; les différences de conformité sont expliquées ; les tests de résilience requis ont des preuves ; les limitations d'accessibilité sont explicites ; aucun problème bloquant la release ne subsiste.
• Réviser : L'autorité est claire et le défaut est borné, reproductible, identifié et sûr à re-tester avant la release. Le compte rendu nomme le fixture en échec et le résultat attendu.
• Bloquant : une tâche requise échoue ; une action destructive ou irréversible présente un comportement ambigu ; les permissions sont incorrectes ; la récupération est indisponible alors qu'elle est requise ; l'exigence directrice ou l'autorité de design n'est pas tranchée ; une preuve manque pour un état critique pour la mise en production ; ou le test de changement contrôlé révèle une propagation défectueuse ou une dérive non liée.

La sévérité doit décrire la conséquence, et non la visibilité. Une erreur de permission subtile peut bloquer la mise en production. Un décalage d'espacement flagrant peut être de faible sévérité s'il n'entrave pas la tâche et que le responsable du design l'accepte.

Identity Forge peut fournir les entrées déclaratives pour ce processus : des design tokens sémantiques pour les modes clair et sombre, la typographie, des directives d'espacement et de mise en page, des motifs, des règles d'utilisation, le fichier DESIGN.md, ainsi que des formats de livraison tels que Tailwind, DTCG et des artefacts orientés shadcn/ui. Ces entrées réduisent l'ambiguïté lorsque vous devez vérifier si l'UI générée respecte le système choisi.

Ils ne fournissent pas les exigences produit, le comportement final des composants, un audit UI complet, ni la preuve qu'une interface est accessible ou prête pour la production. Ils ne décident pas non plus si une différence constitue une exception approuvée. Ce jugement incombe aux personnes responsables du produit, du design system, de l'implémentation et de la mise en production.

Si un projet ne dispose d'aucune autorité de design déclarée, établissez-en une avant de revendiquer la conformité. Les guides associés sur les design systems pour les agents de code, DESIGN.md et les design tokens de couleurs sémantiques expliquent les entrées possibles. La méthode de revue elle-même reste indépendante de l'outil utilisé.

• La tâche utilisateur revue, la condition de départ et le résultat attendu sont consignés par écrit.
• Les exigences et les autorités du design system sont nommées et versionnées ou identifiables d'une autre manière.
• Les artefacts de livraison et les plateformes supportées sont enregistrés.
• Le contenu représentatif, les permissions, les modes, les viewports et les états requis sont fixés.
• Les parcours principaux, d'annulation, de confirmation, d'erreur et de récupération sont validés là où c'est requis.
• Les couleurs sémantiques, la typographie, l'espacement, la mise en page, le traitement des composants, les motifs et les modes sont tracés jusqu'à l'autorité déclarée ou une exception approuvée.
• Le contenu long, les mises en page étroites, le zoom ou l'espacement du texte, l'utilisation du clavier et les états non par défaut pertinents sont documentés par des preuves.
• Les problèmes d'accessibilité et les zones non testées sont explicites ; aucune revue visuelle ou par IA n'est présentée comme une certification.
• Chaque constat est orienté vers les exigences, la source du design system, le mapping de livraison, l'implémentation ou le fixture.
• Un changement faisant autorité et contrôlé atteint l'artefact et le consommateur visés sans dérive non liée.
• Chaque problème non résolu possède une sévérité, un responsable pour la décision suivante et une condition de re-test.
• Le rapport de mise en production se termine par « validé », « à réviser » ou « bloquant », plutôt que par un commentaire d'approbation vague.

Pour la prochaine revue, choisissez une tâche critique pour la mise en production et complétez le rapport avant d'inspecter le reste de l'interface. Si le comportement attendu ou l'autorité de design ne peut être nommé, arrêtez-vous là et signalez cette lacune. Accumuler des captures d'écran ne résoudra pas l'absence d'une décision.

• 7-point checklist to review any AI-generated UI : l'article explique que des écrans générés par IA très léchés peuvent masquer une logique faible et des décisions produit manquantes ; le fini visuel ne doit donc pas être confondu avec la préparation pour la production.
• AI Generated UI Quality Checklist : cette checklist recommande de réviser la hiérarchie, la cohérence du système, le contenu réel, le comportement responsive, les mises en page mobiles et les états non par défaut avant de mettre en production une UI générée.
• AI design review assistant for modern designers : Figma présente la revue de design comme un flux de travail de feedback contextuel et d'itération, incluant des revues de frames, de composants et de flux sélectionnés.
• A pre-ship design review checklist for AI-generated UI : l'article distingue les problèmes vérifiables mécaniquement de la revue de design qualitative et couvre la palette, la typographie, la mise en page, l'espacement, les états, le focus et le mouvement.
• fonctionnalité CSS media forced-colors : MDN documente que le mode forced-colors permet au navigateur d'imposer une palette de couleurs sélectionnée par l'utilisateur et peut modifier plusieurs propriétés CSS liées aux couleurs.
• Identity Forge : Identity Forge propose des kits de design avec des tokens sémantiques, de la typographie, des règles de mise en page, des directives DESIGN.md et des flux de livraison optimisés pour les agents de code.
• Comment générer un DESIGN.md (et à quoi cela sert) : un fichier DESIGN.md peut documenter l'intention de design, les systèmes de couleurs et de typographie, les règles de mise en page et d'espacement, le traitement des composants, les motifs et les contraintes d'utilisation explicites pour un agent de code.
• Explications sur les design tokens de couleur sémantiques : les design tokens de couleur sémantiques nomment les couleurs selon leur rôle dans l'interface, permettant ainsi aux composants de se référer à des rôles stables, quel que soit le thème (clair ou sombre).
• Générateurs de design system shadcn/ui : avez-vous besoin d'un thème, d'un système ou d'un transfert vers un agent ? : cet article distingue le thème visuel du design system global et recommande d'examiner la signification des tokens, le mapping des composants, la typographie, les directives de mise en page, les méthodes d'installation et les lacunes connues.

• 7-point checklist to review any AI-generated UI: L'article explique que des écrans générés par IA au rendu léché peuvent masquer une logique fragile et des décisions produit manquantes ; le fini visuel ne doit donc pas être confondu avec l'état de préparation pour la production.
• AI Generated UI Quality Checklist: La checklist recommande de vérifier la hiérarchie, la cohérence du système, l'utilisation de contenus réels, le comportement responsive, les mises en page mobiles et les états non par défaut avant de déployer une UI générée.
• AI design review assistant for modern designers: Figma présente la revue de design comme un flux de travail de feedback contextuel et d'itération, incluant la revue de frames, de composants et de flux sélectionnés.
• A pre-ship design review checklist for AI-generated UI: L'article distingue les problèmes vérifiables mécaniquement de la revue de design qualitative, et couvre la palette, la typographie, la mise en page, l'espacement, les états, le focus et le mouvement.
• forced-colors CSS media feature: MDN indique que le mode forced-colors permet au navigateur d'imposer une palette de couleurs choisie par l'utilisateur et peut modifier plusieurs propriétés CSS liées aux couleurs.
• Identity Forge: Identity Forge propose des kits de design avec des tokens sémantiques, de la typographie, des règles de mise en page, des guides DESIGN.md et des méthodes de livraison pour les flux de travail avec agent de code.
• How to generate a DESIGN.md (and what it is): Un fichier DESIGN.md peut documenter l'intention de design, les systèmes de couleurs et de typographie, les règles de mise en page et d'espacement, le traitement des composants, les motifs et les contraintes d'utilisation explicites pour un agent de code.
• Semantic color tokens explained: Les design tokens de couleur sémantiques nomment les couleurs selon leur rôle dans l'interface, permettant ainsi aux composants de se référer à des rôles stables, quel que soit le thème (clair ou sombre).
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: L'article distingue le thème visuel du design system global et recommande d'examiner la signification des tokens, le mapping des composants, la typographie, les directives de mise en page, les méthodes d'installation et les lacunes connues.