Aller au guide d’utilisation
Design QA Checklistpar owl-listener

Design QA Checklist Skill.

Transformez une spécification de design en contrôles d’implémentation.

  • QA design
  • Transmission
Revue de la source · design-qa-checklistSKILL.md
Tâche Transformez une spécification de design en contrôles d’implémentation. Résultats Une liste délimitée dérivée de la spécification de design. Avant de commencer La liste nécessite une référence de design ; une intention vague ne permet pas d’établir une correspondance exacte.
Résumé éditorial · source examinée le 2026-11-02 · ce n’est pas un exemple généré

01 Fonctionnement

Transformez une spécification de design en contrôles d’implémentation

Créez une liste QA couvrant fidélité visuelle, disposition, interactions, contenu, accessibilité et plateformes requises.

Flux de travail fondé sur la sourcePas un benchmark d'exécution

La méthode de travail

Design QA Checklist aide l’équipe à vérifier qu’une interface réalisée correspond à sa spécification. Il couvre valeurs visuelles, mise en page responsive, états des composants, contenu réel, accessibilité et exigences de plateforme. La référence est la spécification réelle, ce qui permet d’identifier les écarts plus précisément qu’une revue de mémoire.

La source décrit un parcours allant de l’auto-vérification du développeur à la QA du designer, aux rapports de défauts avec captures et à la vérification des corrections. Créer la liste prépare ce processus ; l’exécuter nécessite toujours l’interface en fonctionnement, les appareils cibles et les vérifications pertinentes avec les technologies d’assistance.

Livrables attendus

  • Une liste délimitée dérivée de la spécification de design.
  • Des contrôles des états visuels, responsive, d’interaction et de contenu pertinents.
  • Une structure de signalement et de nouveau test des écarts d’implémentation.
Voir l'exemple de brief

Du brief à la revue

  1. 01
    Lire le design attendu

    Rassemblez spécification, tokens et plateformes requises. Traduisez les exigences en contrôles décrivant ce que l’examinateur doit observer.

  2. 02
    Couvrir états et cas limites

    Incluez survol, focus, activation, désactivation, chargement, vide et erreur selon le contexte. Utilisez du contenu réel et vérifiez troncature, débordement et redistribution du contenu.

  3. 03
    Examiner l’implémentation

    Commencez par l’auto-revue du développeur, puis l’inspection du designer. Utilisez les outils du navigateur pour les valeurs exactes et des captures pour comparer utilement design et réalisation.

  4. 04
    Prioriser et retester

    Consignez les écarts par gravité et vérifiez les corrections. Notez les types de problèmes récurrents pour les repérer plus tôt aux revues suivantes.

02 Cas d’usage

Quand l’utiliser

La liste nécessite une référence de design ; une intention vague ne permet pas d’établir une correspondance exacte.

Un bon choix

  • Transmission de l’implémentationUne fonctionnalité réalisée nécessite une validation de design concrète.
  • QA d’équipe reproductibleDéveloppeurs et designers ont besoin des mêmes attentes sur états et détails visuels.

Limites à vérifier

  • Dépendance aux spécificationsLa liste nécessite une référence de design ; une intention vague ne permet pas d’établir une correspondance exacte.
  • Exécution toujours nécessaireUne liste écrite ne prouve pas que navigateurs, appareils ou lecteurs d’écran ont été testés.
  • Livrable différentLa source renvoie les spécifications de transmission technique au skill handoff-spec.

Éléments à fournir

  • Spécification de designFournissez dispositions, tokens et comportement attendu des composants.
  • Version en fonctionnementIdentifiez l’implémentation et les états accessibles aux examinateurs.
  • Matrice de plateformesPrécisez navigateurs, appareils, tailles de texte et conditions d’accessibilité requis.

03 Décisions importantes

Les décisions importantes

  1. Attentes partagées

    Développeurs et designers inspectent selon une référence commune définie.

  2. Couverture des états

    Erreurs et états vides restent dans la validation, en plus de la vue par défaut.

  3. Discipline de retest

    Une correction signalée est vérifiée à nouveau avant de considérer le problème résolu.

04 Exemple de brief

Essayez un brief ciblé

L'exemple de brief ci-dessous n'a pas été testé. Vérifiez la configuration du skill avant de l'utiliser.

Examinez la source et la configuration

Fournissez dispositions, tokens et comportement attendu des composants.

Fichier source amont
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md

Le lien ci-dessous ouvre les instructions d’origine. Vérifiez la configuration du dépôt avant utilisation ; ce n’est pas une commande d’installation.

Commencez par un livrable

Adaptez le périmètre, les sources et les contraintes de ce brief avant d’exécuter le skill.

Exemple de brief
Utilise design-qa-checklist pour le nouvel écran de factures. Lis spécification et tokens, puis crée les contrôles pour ordinateur et mobile, résultats vides, chargement, erreurs de validation et actions désactivées. Inclus ordre au clavier, focus visible, agrandissement du texte et réduction des animations lorsque pertinents. Utilise les vraies factures d’exemple, pas du texte fictif. Distingue préparation de la liste et tests exécutés. Pour chaque écart observé, note comportement attendu, comportement réel, captures et gravité, puis prévois explicitement le retest de la correction.

Examinez le résultat

Comparez le résultat réel à ces critères observables.

  • Chaque point renvoie à une spécification ou exigence produit déclarée.
  • Les vérifications exécutées et conditions non testées sont clairement séparées.
  • Les défauts résolus incluent la vérification de l’état corrigé.

OpenDesign fournit un espace de travail de design local pour les agents de code. Cette fiche ne signifie pas que le skill est fourni avec ses outils externes, ses identifiants et ses dépendances logicielles.

05 Source et licence

Source et licence

Cette page décrit la révision source figée liée ci-dessous. Le comportement et les exigences en amont peuvent changer.

Propriétaire de la source
owl-listener
Fichier du skill
SKILL.md
Licence
MIT
Version examinée
2026-11-02 · 9a6930cf84a8
Résumé éditorial de la source
Transformez une spécification de design en contrôles d’implémentation.

Résumé original de OpenDesign, fondé sur la source liée. Les étoiles du dépôt sont un indicateur de popularité daté, pas une mesure d'utilisation du skill ni une note de qualité.

06 Questions avant de commencer

Questions avant de commencer

Est-ce seulement une liste visuelle ?

Non. Elle inclut interaction, contenu, accessibilité et vérifications multiplateformes.

Une capture prouve-t-elle le comportement au clavier ?

Les contrôles de clavier et de focus nécessitent une interaction avec l’interface ; les captures étayent la comparaison visuelle.

Quel contenu utiliser pour la QA ?

La source recommande contenu réel et cas limites plutôt que seulement des parcours sans erreur ou du texte fictif.

OpenDesign

Gardez votre brief et votre travail de design au même endroit.

Gardez votre brief, vos sources et votre travail de design ensemble dans un espace de travail local. Vérifiez la configuration propre au skill avant de l'ajouter à votre flux de travail.

Fichier source amont
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md