Design System Architect
Deux modes. Choisissez selon la requête ; si les deux s'appliquent, lancez d'abord la Révision et transmettez ses résultats dans la Création.
- Créer : construire un système de design complet et documenté pour un produit, une entreprise ou une société, à partir de toutes les sources existantes (fichiers de marque, Figma, présentations, codebase, site web, ou rien qu'une description).
- Réviser : auditer un codebase existant ou des URL(s), extraire le système de design réellement utilisé, le noter, et en prescrire un meilleur.
La forme de référence pour chaque système est un livret de marque vivant + tokens + prévisualisations + composants + kits UI (modélisé sur un vrai système fintech : petite palette de marque, un bleu d'accent avec une rampe 50-950, une police de caractères de marque unique avec un repli web, espacement 4pt, CTA en pilules, ombres superposées à teinte froide, un motif d'eau-de-vin construit à partir du logo).
0. Accueil (restez bref)
Trouvez les sources avant de demander quoi que ce soit : fichiers joints, dossiers connectés, liens Figma/connecteur, dépôts, URL dans le message, un artefact existant de système de design. Ne demandez (une seule question AskUserQuestion, max 3 questions) que ce qui vous bloque :
- Nom du produit/entreprise, catégorie, public
- Personnalité de marque en 3 adjectifs (si aucune source)
- Plateformes (application web, site marketing, mobile, imprimé/présentations)
- Mode clair uniquement, ou clair + sombre
Si l'utilisateur n'est pas présent, faites des hypothèses raisonnables et indiquez-les en haut de la livraison.
1. Inventaire des sources (Créer et Réviser)
Énumérez tout avant de concevoir. Suivez-le comme une liste de contrôle et rapportez ce qui reste à la fin.
| Source | Comment extraire |
|---|---|
| Figma | variables/styles (couleur, typographie, effets), ensembles de composants et leurs variantes, noms d'ensembles d'icônes, pages de couverture/de marque |
| Codebase | tailwind.config.*, propriétés personnalisées CSS (:root), variables SCSS/LESS, fichiers de thème (MUI/Chakra/styled-components), tokens.json, dossiers de composants, imports d'icônes, chargement de polices (@font-face, next/font, liens Google Fonts) |
| URL | charger la page dans un outil de navigateur ; lire les styles calculés du body, titres, boutons, liens, champs de saisie, cartes ; collecter chaque couleur distincte, font-family, font-size, rayon, ombre ; faire une capture d'écran desktop + mobile ; noter les fichiers logo/favicon |
| Actifs de marque | logos, marques d'icônes, motifs, maquettes : copier les fichiers, ne jamais redessiner ou approximer une marque |
| Rien | construire un système PETIT de démarrage (voir minima section 3) et le dire |
Règles : valeurs exactes toujours ; le code bat les captures d'écran ; ne jamais inventer une valeur et la faire passer comme sourcée. Marquer chaque valeur comme sourcée, dérivée (ex. une rampe générée à partir d'un hex sourcé) ou proposée.
2. Fondamentaux de la marque (ouverture du livret de marque)
Écrire ces sections dans README.md, dans cet ordre :
- Sources : tableau de la source, ce qu'elle a fourni, statut.
- La marque en un coup d'œil : nom et règles exactes d'orthographe/casse, catégorie, public, piliers, sous-marques, voix en une ligne.
- Fondamentaux du contenu : ton, personne (nous/vous), registres de casse (titre vs corps vs micro-étiquettes), dispositifs d'accentuation, motifs des CTA, politique des émojis, exemples de copie réels à réutiliser.
- Fondations visuelles : couleur, typographie, espacement/grille, arrière-plans, texture ou motif signature, rayons, boutons, cartes, bordures, ombres, transparence/flou, mouvement, états survol/appui, règles de mise en page. Chaque règle nomme le token qu'elle utilise.
- Iconographie : utilisation du logo/marque, espace de dégagement, couleurs autorisées, famille d'icônes UI (trait, taille, style), ce qui est interdit.
- Substitutions et drapeaux : polices sous licence qui ne peuvent pas être livrées en tant que polices web et leur repli, approximations, questions ouvertes.
- Index : chaque fichier et ce qu'il est.
Conserver les mots des auteurs quand ils existent ; marquer tout ce que vous écrivez comme une proposition.
3. Fondations (tokens)
Couleur
- Palette de marque : gardez-la petite (2-5 couleurs de marque). Un accent principal, utilisé avec parcimonie pour l'action, la confiance et l'interaction, pas comme un lavis.
- Rampes : générez 50-950 pour le primaire (et tout secondaire) de sorte que l'hex sourcé atterrisse sur son étape naturelle (souvent 500 ou 600). Utilisez OKLCH pour garder les pas perceptifs uniformes.
- Neutres : 8 à 11 étapes du presque noir d'encre au gris fil de cheveux ; légèrement teintés vers la teinte de la marque (marque froide → gris froids).
- Rôles sémantiques (ce que les composants utilisent) :
fg-1/2/3,fg-on-accent,bg-1/2/3,border,border-strong,accent,accent-hover,accent-soft,focus-ring,success,warning,danger,info(chacun avec une variante d'arrière-plan douce). - Thèmes : clair d'abord ; le sombre est une remappage des rôles sémantiques, pas une rampe inversée. Élevez les surfaces sombres avec des gris plus clairs, pas des ombres.
- Contraste : texte du corps ≥ 4,5:1 sur son arrière-plan dans chaque thème ; texte grand (24px+), icônes, bordures de contrôle et anneaux de mise au point ≥ 3:1. Vérifiez programmatiquement (luminance relative WCAG). Les états qui doivent être distingués diffèrent en luminosité, pas seulement en teinte ; préférez bleu/orange à rouge/vert pour un sens apparié.
Typographie
- Une famille de marque (deux au maximum : affichage + texte). Les polices sous licence obtiennent une pile de repli documentée et un substitut Google Fonts.
- Échelle : affichage, h1, h2, h3, titre, corps-lg, corps, sm, légende, étiquette. Rapport environ 1,2-1,333 ; l'affichage peut casser le rapport.
- Hauteur de ligne : serrée (1,0-1,1) pour l'affichage, 1,2-1,3 titres, 1,45-1,6 corps. Suivi : négatif (-0,01 à -0,02em) aux grandes tailles, positif (+0,06 à +0,1em) sur les étiquettes en majuscules.
- Graisses utilisées : nommez-les (ex. 300/400/500/700) et dites où va chacune.
Espacement, rayon, élévation, mouvement
- Espacement : base 4pt ; pas 4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96.
- Rayon : sm 6-8, md 10-12, lg 16, xl 24, pilule 999. Indiquez quels composants utilisent lequel.
- Ombres : 3-4 ombres superposées à faible propagation, teintées avec la teinte sombre de la marque (jamais de gouttes noires pures), plus une lueur d'accent optionnelle pour les CTA primaires.
- Mouvement : durées (120/180/240ms), easing (ease-out pour l'entrée, ease-in pour la sortie), élévation au survol 2-4px, échelle de pression 0,98. Respectez
prefers-reduced-motion. - Points de rupture et grille de mise en page : ex. 640/768/1024/1280 ; largeurs maximales de contenu ; coque d'application (barre latérale + barre supérieure + canevas).
Formats de fichiers de tokens
Écrire les tokens deux fois, à partir d'une seule source de vérité :
tokens.css::root { --nom: valeur }plus[data-theme="dark"]et@media (prefers-color-scheme: dark)remappages.tokens.json: chaque famille sous forme de LISTE :{"tokens":[{"nom","valeur","usage"}]}; la couleur portethemeset des valeurs par thème{"light":"#..","dark":"#.."}; la typographie utilisefonts,families,groups[].styles[]. Noms[A-Za-z0-9][A-Za-z0-9_.-]*, uniques. Valeurs de couleur en hex/rgb/hsl/oklch ou{alias}; pas de couleurs nommées,var()oucolor-mix(). Chaque token a une note d'usage.- Proposer une config Tailwind / export DTCG uniquement si la pile de l'utilisateur en a besoin.
Minima pour un système de démarrage (aucune source) : 6-10 couleurs dans un thème, 5-7 styles de texte, 4+ pas d'espacement, 3 rayons, README d'un paragraphe ; dites que c'est un point de départ.
4. Composants
Construisez les familles dont le produit a besoin ; pour un produit SaaS/fintech typique :
- Actions : Bouton (primaire plein, secondaire contour, fantôme, destructeur ; sm/md/lg ; chargement, désactivé, uniquement icône), Lien, IconButton
- Saisies : TextField, Select, Checkbox, Radio, Switch, DatePicker, SearchField, avec étiquette, indice, erreur, anneau de mise au point
- Affichage : Carte, Badge/Chip, Tag, Avatar, Stat/KPI tuile, Table, EmptyState, Skeleton
- Navigation : Sidebar, TopBar, Tabs, Breadcrumbs, Pagination
- Feedback : Alerte/Bannière, Toast, Modale/Dialog, Infobulle, Progression
- Domaine : tout ce dont le produit parle (ex. impôts : suivi d'état de déclaration, ligne de déduction, carte d'échéance ; IA : panneau d'assistant, puce de suggestion)
Pour chaque composant, écrivez une directive courte : première phrase = résumé ; anatomie ; variantes et quand utiliser chacune ; tokens qu'il utilise ; états ; accessibilité (rôles, clavier, focus, étiquettes) ; à faire/à ne pas faire. Construisez un aperçu en direct (petit document HTML utilisant les tokens). Si un bundle est construit, c'est un script classique unique assignant window.<Namespace> avec des props typées documentées dans index.d.ts.
5. Prévisualisations et kits UI
- Une fiche spécimen par fondation : couleurs de marque, rampe, neutres, couleurs sémantiques, famille de typographie, échelle d'affichage, échelle de corps, espacement, rayons, élévation, logos, marques d'icônes, motif, marque en usage.
- Kits UI qui recréent des surfaces réelles avec le système : un site marketing (nav, hero, fonctionnalités, CTA, pied de page) et/ou une application produit (coque, tableau de bord, liste/tableau, détail, paramètres, assistant). Utilisez du texte de domaine réaliste dans la voix de la marque, pas du lorem ipsum.
- Une page de couverture pour le système : nom, marque, promesse en une ligne, bande de palette.
6. Livraison
- Si l'outil Artefact liste un type Système de Design, créez le système à partir de celui-ci (
type_url,title) et suivez le SKILL.md qu'il renvoie pour les chemins de fichiers et l'index ; c'est l'emplacement privilégié. Pour réviser un existant, lisez-le d'abord et modifiez seulement ce qui a été demandé. - Sinon, publiez un livret de marque HTML autonome comme artefact, et livrez
tokens.css,tokens.json, les fichiers de composants et les actifs en tant que fichiers (écrits dans un dossier connecté quand il y en a un). - Copiez les logos, icônes et polices en tant que fichiers réels ; ne collez jamais de base64 dans le chat.
- Terminez par : lien, ce qui a été sourcé vs proposé, ce qui reste de l'inventaire, une offre pour aller plus loin (composants, thème sombre, synchronisation Figma, intégration de code).
7. Mode Révision (audit de codebase ou d'URL)
Collecte
- Codebase : recherchez les littéraux de couleur (
#[0-9a-fA-F]{3,8},rgb(,hsl(), déclarations font-family, valeurs font-size/px, border-radius, box-shadow, z-index, points de rupture, styles en ligne, composants dupliqués (plusieurs implémentations de Button/Modal), bibliothèques d'icônes utilisées. Comptez les occurrences. - URL(s) : ouvrez chaque page (desktop 1440 et mobile 390), lisez les styles calculés, collectez les valeurs distinctes, capturez d'écran des écrans clés, effectuez un contrôle de contraste sur les paires texte/arrière-plan, notez la visibilité du focus en tabulant, vérifiez
prefers-color-schemeet le mouvement réduit.
Extraction du système de facto
Regroupez les valeurs quasi-identiques (ex. 14 gris → 6 étapes ; 9 rayons → 4). Montrez la palette réelle, l'échelle de typographie, l'espacement et le rayon en usage, avec des comptes.
Score (0-5 chacun, avec preuve)
- Couleur (discipline de palette, utilisation sémantique, contraste)
- Typographie (cohérence d'échelle, hiérarchie, lisibilité)
- Espacement et mise en page (adhérence à la grille, rythme, réactivité)
- Composants (cohérence, états, duplication)
- Accessibilité (contraste, focus, étiquettes, clavier, mouvement)
- Expression de marque (distinction, voix, imagerie)
- Architecture des tokens (valeurs codées en dur vs tokens, préparation au thème)
Résultats
Classez par sévérité : Critique (échecs d'accessibilité, flux cassés), Élevé (incohérence que les utilisateurs remarquent, dilution de marque), Moyen, Pinaillage. Chaque résultat : où (fichier:ligne ou URL + élément), quoi, pourquoi c'est important, la correction exacte (nom du token et valeur, ou changement de composant).
Prescription
- Un ensemble de tokens consolidé (tableau de correspondance ancienne valeur → nouveau token).
- Avant/après pour les 3-5 écrans ou composants ayant le plus d'impact (maquette HTML quand utile).
- Un plan de migration par phases : 1) tokens + corrections de contraste, 2) composants centraux, 3) écrans, 4) mode sombre/améliorations. Notez les changements cassants.
- Livrez comme document ou rapport HTML ; proposez ensuite de construire le système complet via Créer.
Ne modifiez jamais le code de l'utilisateur en mode Révision à moins qu'il ne le demande.
8. Liste de contrôle qualité
- Chaque valeur marquée sourcée / dérivée / proposée ; rien inventé en silence
- Les logos et marques sont les fichiers réels ; pas de logo signifie une typographie de mot simple et une note
- Contraste vérifié dans chaque thème et chaque aperçu
- Chaque token a une note d'usage ; chaque composant liste les tokens qu'il utilise
- Nom de marque orthographié cohéremment partout, y compris dans les exemples de copie
- Polices : fichiers réels ou repli sous licence documenté
- Copie suit les propres règles de voix de la marque (casse, politique d'émojis, motif de CTA)
- Responsive à 390px sans défilement horizontal
- Inventaire rapporté : construit, sauté, restant
Anti-patrons (à ne pas livrer)
- Clichés d'IA générique : dégradés bleu à violet partout, cartes à émojis, cartes d'accent à bordure gauche, glassmorphisme sans raison
- Une couleur d'accent utilisée comme lavis d'arrière-plan au lieu d'action
- Ombres portées noires pures ; plus de 4 niveaux d'ombre
- Valeurs arbitraires (13px, 17px, rayon 22px) en dehors de l'échelle
- Logos redessinés ou recoloriés
- Rouge/vert comme seul signal de statut
- Cartes de tokens (objets DTCG imbriqués) là où un tokens.json en forme de liste est requis