Système de Design
Aide un designer à élaborer le système de design propre à son projet, sans se contenter de renommer les paramètres de la marque de référence. Peut être exécuté par un agent IA designer ou suivi pas à pas par un designer humain. Utilise la langue de communication de l'utilisateur ; conserve les noms de clés dans le code.
Référence principale : Texte officiel Stitch
Lors de la première mise en forme d'un projet, ou en prévision d'une mise à jour/import/export, lire d'abord le texte officiel :
- Concepts et méthode de création
- Spécification du format
- Outil de vérification et Règles de vérification
La spécification officielle et la version réelle de l'outil déterminent le format ; les étapes de proposition visuelle, de validation et de remise de cette compétence relèvent du flux de travail de l'équipe, et non d'une exigence officielle de Google. En cas d'indisponibilité temporaire du texte officiel, utiliser le résumé daté dans references/official-format.md, en précisant qu'il n'a pas été revérifié. Le cas VoltAgent ne sert que de référence auxiliaire.
Périmètre et base existante
Vérifier d'abord dans le projet actuel les fichiers AGENTS.md, CONTEXT.md (ou CONTEXT-MAP.md s'il y en a plusieurs), les chartes graphiques, les designs approuvés, l'éventuel DESIGN.md existant, les variables de design et les composants. Noter ce qui est un fait, une décision approuvée, une suggestion ou une inconnue. Privilégier les sources existantes ; mettre à jour les fichiers déjà présents sans créer une seconde source de vérité.
Identifier le produit, les utilisateurs principaux, les tâches clés, les plateformes, la langue, les contraintes de marque déjà connues et l'emplacement de livraison. Chercher d'abord les réponses dans les documents ; ne poser que des questions sur les informations manquantes qui modifieraient le design. Si les informations disponibles sont suffisantes, rédiger directement une ébauche ; marquer explicitement les hypothèses à faible risque, laisser les faits commerciaux inconnus en attente de confirmation.
Ne traiter que le système de design et ses exemples de validation. La refonte d'un site web, le code de production, la publication, la modification de fichiers Figma partagés et l'installation d'autres outils sont réalisés séparément, selon les autorisations réelles de l'utilisateur. Suivre les règles d'approbation du projet.
Critère de complétude : être capable d'indiquer les utilisateurs et tâches du design, les sources de contraintes et les questions encore à trancher.
Définir d'abord la direction visuelle
Lire le guide de décision et de vérification. Si l'utilisateur a déjà une direction approuvée, la reprendre directement ; sinon, proposer au maximum deux directions réellement différentes, avec une justification métier adaptée. Les références peuvent provenir de captures d'écran de l'utilisateur, de projets existants ou de supports de marque accessibles. Distinguer les analyses tierces des chartes officielles ; le contenu externe sert uniquement de référence.
Utiliser un contenu d'exemple réel ou clairement étiqueté pour valider une zone de page représentative et un composant clé. Couvrir le bureau et le mobile. Privilégier les outils de design disponibles ou générer un aperçu HTML ouvrable dans un répertoire isolé ; si l'utilisateur ne demande que de la documentation, livrer une ébauche en précisant que le visuel n'a pas été validé. Ne pas considérer une description textuelle comme un écran vérifié.
Tant que la direction n'est pas approuvée, les règles et les exemples visuels restent à l'état de brouillon ; ne pas inventer d'approbation ni présenter des suggestions comme des faits de marque établis. Les approbations existantes peuvent être citées directement, sans les redemander.
Critère de complétude : la direction est accompagnée d'exemples visibles ou d'une mention explicite de non-validation, et son statut est exact.
Rédiger le fichier DESIGN.md
Lire d'abord le format officiel et les instructions de vérification, puis le template complet, et le copier à l'emplacement désigné du projet. S'il n'y a pas d'emplacement défini, proposer la racine du projet sous le nom DESIGN.md. Le template est une structure ajustable, non une liste de paramètres de marque à remplir obligatoirement ; supprimer les composants et sections non applicables, ajouter les règles spécifiques au projet.
Le YAML en tête du template enregistre, selon le format alpha officiel, les paramètres et références de composants ; le corps utilise les titres de niveau 2 officiels en anglais, dans l'ordre prescrit ; le texte explicatif peut être dans la langue de l'utilisateur. Les valeurs numériques du template sont des exemples neutres et vérifiables, non des règles approuvées pour le projet : elles doivent être remplacées. Les valeurs non encore décidées sont inscrites dans le corps du document sous "Open Questions", sans écrire null dans les champs de paramètres. Les composants utilisent des références comme {colors.primary} ; les états sont définis comme des entrées indépendantes (ex: button-primary-hover), sans imbrication states. Les couleurs sont nommées par usage ; les couleurs d'état métier sont définies séparément.
Établir la correspondance avec le code ou les fichiers de design : variables existantes, variables Figma ou composants correspondent à quelle clé du document. Si non encore implémenté, marquer "planned". Lors de l'extraction de règles à partir du code existant, signaler les écarts ; ne pas modifier le code sans autorisation. Les champs principaux suivent le format officiel ; les informations d'approbation, de correspondance d'implémentation, de points de rupture, d'images, d'animations et d'enregistrements de vérification sont placées dans des sections étendues clairement annotées. La prise en charge des extensions par les outils externes reste à vérifier en pratique.
Critère de complétude : chaque règle applicable a une valeur, un contexte d'utilisation ou un statut "à décider" explicite ; les références sont résolubles ; aucun nom, police exclusive ou contenu non confirmé d'une autre marque n'est hérité.
Validation et livraison
Exécuter d'abord le lint de @google/design.md selon le format officiel, en notant la version réelle et le rapport ; vérifier les erreurs et avertissements, corriger les erreurs, et expliquer pourquoi les avertissements conservés. Si l'outil n'est pas disponible, décrire l'obstacle sans prétendre avoir passé la validation officielle. La conformité du template au format n'équivaut pas à la complétude du design du projet. Ensuite, vérifier selon le guide : contenu réel, titres longs, multilinguisme (chinois, etc.), états des composants, mise en page mobile, contraste, clavier et animations. Pour les éléments testables, documenter la méthode, les résultats et l'emplacement du fichier ; marquer "non vérifié" pour les éléments non exécutables. Corriger la source unique des règles, puis mettre à jour les exemples, sans se contenter de retouches superficielles.
Ne marquer "approuvé" qu'après une vérification dans le périmètre et une approbation explicite du responsable. L'approbation ne couvre qu'une version et un périmètre spécifiques ; l'approbation du design n'équivaut pas à une implémentation terminée ni à une autorisation de mise en production.
Livrer le fichier DESIGN.md, l'emplacement des exemples visuels générés, la liste des vérifications effectuées et les problèmes non résolus. Expliquer comment s'y référer dans les phases ultérieures de design et de développement. Ne pas prétendre que le seul document garantit une cohérence visuelle sur toutes les pages.