DESIGN.md : le framework de design IA caché en pleine vue
J'avais un samedi prévu pour repenser trois produits que j'expédie sous différentes marques. Site de marketing pour un. Des écrans d’applications mobiles pour un autre. Un pitch deck pour le troisième. Trois esthétiques différentes. Trois publics différents. Trois piles différentes. L'année dernière, cela aurait duré quatre semaines. Le mois dernier, avec Claude Code et une pile de compétences, cela a duré trois jours. Cette semaine, je l'ai fait avant le déjeuner.
Ce qui a changé, c'est un seul fichier. Six cent douze lignes de démarque à la racine de chaque projet. Un nom que je voyais apparaître sur mon fil Twitter depuis des semaines mais que je n'avais pas pris la peine de réellement utiliser. DESIGN.md. Ou, selon la transcription que vous lisez, design.mmd. Même fichier. Différentes touches sur le même instrument.
Je me suis trompé pendant presque un mois. Je pensais qu'il s'agissait d'un autre YAML de jeton de conception enveloppé dans un cycle de battage médiatique. J'ai pensé "super, une autre spécification à mémoriser, une autre norme à abandonner lorsque la prochaine sera expédiée dans six semaines". Je me suis assis sur mes mains et j'ai regardé les étoiles GitHub grimper. Le dépôt officiel google-labs-code/design.md a dépassé les 10 000 étoiles huit jours après que Google a rendu la spécification open source le 21 avril 2026. La collection VoltAgent/awesome-design-md, pilotée par la communauté, a dépassé les 68 000 dans la même fenêtre et se situe désormais quelque part au nord de 71 000 cette semaine. De tels chiffres, dans un marché aussi saturé, n'arrivent pas pour un fichier YAML.
Ce qui m'a manqué, c'est que DESIGN.md n'est pas vraiment un format de fichier. C'est un protocole. Une façon d'enseigner votre marque à un étranger en le temps qu'il faut pour servir un café, où l'étranger se trouve être chaque agent de codage que vous utiliserez. Une fois que cela a cliqué, tout mon flux de travail de conception AI s'est restructuré autour de lui. Cet article est la version de l’explication que j’aurais aimé que quelqu’un me remette quatre semaines plus tôt.
Laissez-moi vous montrer ce qui se passe réellement lorsque vous arrêtez de le combattre.
Pourquoi « Juste inviter le modèle » n'est plus suffisant
Voici le mode de défaillance que chaque bâtiment de conception doté de AI en 2026 a rencontré au moins une fois.
Vous lancez un nouveau projet. Vous invitez Claude Code ou Cursor ou Codex avec quelque chose de raisonnable : "créez-moi une section héros de tableau de bord pour une application fintech, moderne et propre." Le modèle se met au travail. Cela produit quelque chose. Ce qu'il produit est très bien. En fait, c'est plus que bien : c'est techniquement correct, il utilise des valeurs par défaut raisonnables, l'espacement est régulier, l'échelle typographique a du sens. Et pourtant, on y jette un coup d'œil et on sent déjà la pente.
Vous ne pouvez pas mettre le doigt dessus une seule seconde. Alors vous pouvez. L'ombre est fausse. Pas faux dans le sens de cassé — faux dans le sens où tous les autres tableaux de bord générés par AI sur Internet ont cette ombre exacte. Le bleu est le même bleu utilisé par Vercel, qui est le même bleu utilisé par l'ancien design de Stripe, qui est le même bleu utilisé par chaque site marketing de l'entreprise YC en 2024. Vous regardez une moyenne statistique portant un costume de marque.
C'est la chose dont personne ne vous prévient lorsqu'il vous vend des outils de conception AI. Le modèle ne prend pas de décision créative. C'est une moyenne. Il fait la moyenne de votre vague invite par rapport à toutes les autres interfaces que ses données d'entraînement lui ont déjà montrées, et le résultat atterrit directement au-dessus de la médiane. Médiane UI. Espacement médian. Marque médiane. La raison pour laquelle cela semble générique est parce que c'est.
Les concepteurs dénoncent précisément ce problème depuis près d’un an. Il y a un terme qui circule maintenant - "Claude slop", "Cursor slop", choisissez votre modèle - et il est plus laid que le design lui-même. Cela vous dit une chose vraie : le goulot d’étranglement n’est plus le modèle. Le goulot d'étranglement est de savoir si le modèle a une idée de ce à quoi votre goût est censé ressembler.
C'est le vide que DESIGN.md comble. Pas en étant plus intelligent que le modèle. En étant un contrat, le modèle peut réellement suivre.
Nous aborderons le format lui-même dans un instant. Mais je dois d’abord vous parler du moment où j’ai cessé d’être sceptique.
La première fois que je l'ai vu fonctionner réellement
J'avais un site de marketing pour un produit secondaire. Ambiance de fondateur solo – une de ces pages de destination minimalistes avec un héros, trois blocs de fonctionnalités, une preuve sociale, des prix, une FAQ. J'avais fait esquisser la marque dans Figma mais je n'avais encore rien implémenté. J'étais sur le point de faire ce que je fais toujours : coder manuellement le premier passage, puis le remettre à Claude Code pour le peaufiner.
Au lieu de cela, j'ai essayé le chemin DESIGN.md. J'ai écrit un fichier de 412 lignes décrivant chaque décision de marque dans un anglais simple. Jetons de couleur avec une phrase chacun lorsqu'ils s'appliquent. Échelle de typographie avec la justification de chaque étape. Système d'espacement lié à une base de 4px. Voix et ton. Une section dédiée « Anti-Patterns » répertoriant les huit erreurs qu'un agent ne devrait jamais commettre dans ce projet. J'ai déposé le fichier à la racine du projet. Ensuite, j'ai ouvert Claude Code et j'ai tapé exactement ceci :
Lisez DESIGN.md. Ensuite, créez-moi une page de destination marketing en utilisant uniquement les jetons, composants et règles qui y sont définis. Hero, trois blocs de fonctionnalités, bande de preuve sociale, tarification, FAQ.
Ce qui est revenu quarante-cinq secondes plus tard n’était pas un brouillon. C'était la page. Pixel proche de ce que j'avais esquissé dans Figma sans jamais ouvrir Figma. Le héros a utilisé mon en-tête serif personnalisé à la bonne taille. La fiche de tarification utilisait mon style de surface "élevé" - le bon, pas le modal - car j'avais décrit dans le fichier le moment où chaque surface était appliquée. L'état de survol du bouton était le bon changement de tonalité, avec le bon timing de transition, car ce timing existait dans la section de mouvement.
Je suis resté assis là pendant environ trente secondes à le traiter. Ensuite, j'ai essayé de le casser. Je lui ai demandé d'ajouter une section témoignage. Il a utilisé le bon style de carte. J'ai demandé un tableau comparatif avec trois concurrents. Il a sélectionné la bonne variante de densité de table. J'ai demandé un mode sombre. Il a réappliqué chaque jeton correctement sans que j'aie à lui rappeler les arrière-plans teintés de marque que j'avais définis pour le contenu promu.
Le tout m'a pris quarante minutes. Le fichier DESIGN.md m'a pris environ trois heures pour écrire correctement. Quarante minutes pour la page. Trois heures pour le fichier qui génère désormais une infinité de pages cohérentes. Ce calcul est tout le problème.
Depuis, j'ai expédié ce flux de travail sur quatre produits distincts, chacun avec son propre DESIGN.md. La composition devient ridicule après le deuxième projet. Pour le troisième projet, j'avais un modèle que je copie-colle-modifie et le fichier est réalisé en vingt minutes.
Mais rien de tout cela ne fonctionne si le fichier est bâclé. Alors laissez-moi vous montrer ce que contient réellement le fichier.
Que contient un fichier DESIGN.md, section par section
Le format Google open-source possède une structure spécifique. Il ne s'agit pas d'un essai de forme libre. La spécification actuelle définit un corps de démarque avec des sections prédéfinies, des éléments de présentation YAML facultatifs en haut pour les jetons lisibles par machine et une règle d'ordre stricte : les sections peuvent être omises, mais celles présentes doivent apparaître dans l'ordre des spécifications.
Voici les neuf sections demandées par la spécification, ainsi que la manière dont j'utilise chacune d'elles :
1. Version et nom. Deux lignes. La balise de version est actuellement alpha et existe afin que les futurs outils sachent quelle édition de spécifications le fichier cible. Le nom est le nom du projet. Vous penserez qu’il s’agit de métadonnées jetables. Ce n'est pas. Lorsque vous créez un DESIGN.md à partir d'un projet frère et oubliez de le renommer, chaque agent de votre chaîne d'outils finit par créer en toute confiance « AcmeBank » UI pour une marque de bien-être. J'ai vu cela se produire.
2. Description. Un seul paragraphe décrivant le positionnement et la personnalité du produit. C'est la section "âme" dont la communauté source ne cesse de parler. Le mien ressemble plus à un dossier créatif qu'à une spécification : trois phrases indiquant à qui le produit est destiné, deux phrases sur le sentiment qu'il devrait produire, une phrase répertoriant ce qu'il n'est absolument pas. Le modèle utilise cela pour rompre les liens dans chaque décision ambiguë en aval. Si vous sautez cette section, attendez-vous à un plat fade.
3. Présentation. Un paragraphe d'apparence holistique. Là où la description concerne le positionnement, l'aperçu concerne le caractère visuel. Ce produit est-il chaud ou frais ? Dense ou aéré ? Fort ou discret ? Éditorial ou utilitaire ? C'est la section où vos goûts se manifestent sous forme linguistique. Je garde le mien spécifique : "Éditorial-silencieux. Neutres chaleureux, utilisation sobre des accents, espaces généreux. Les titres font le gros du travail ; le texte de support recule. Pas de dégradés au premier plan. Pas d'effets de verre. Pas de mouvement gratuit."
4. Couleurs. Valeurs hexadécimales mappées à des noms sémantiques. L'astuce qui m'a pris trois projets pour apprendre : ne pas nommer les couleurs d'après leur apparence. Nommez-les d’après leur travail. surface-base et non gray-50. action-primary et non indigo-600. status-warning-subtle et non amber-100. Chaque jeton reçoit une description en une phrase indiquant quand l'utiliser. Les descriptions empêchent le modèle de saisir le mauvais bleu à 2 heures du matin.
5. Typographie. Familles de polices, échelle, épaisseurs, hauteurs de ligne, espacement des lettres. Douze à quinze jetons sont typiques. Le mien en a treize : affichage, titre-xl, titre-l, titre-m, titre-s, corps-l, corps, corps-s, légende, code, bouton, étiquette, sourcil. Chacun avec des règles explicites sur l'endroit où il apparaît.
6. Disposition. Grilles, points d'arrêt, échelle d'espacement de base. Que vous utilisiez 4px ou 8px comme unité. La densité de votre page typique. Que vos gouttières évoluent avec un point d'arrêt ou restent fixes. C’est ici que vous encodez le rythme de la marque.
7. Élévation et profondeur. Ombres, couches d'index z, règles de stratification visuelle du système. C’est la section que la plupart des équipes oublient. Cela compte plus que vous ne le pensez : la moitié de la pente que vous voyez dans UI généré par AI provient du modèle qui sélectionne les valeurs d'ombre à partir des moyennes des données d'entraînement. Si votre fichier ne spécifie pas l'élévation, le modèle devinera, et la supposition ressemblera à n'importe quel autre tableau de bord généré.
8. Composants. Modèles pour boutons, cartes, formulaires, navigation, avec toutes les variantes et états. C'est là que le fichier devient long. Pour un projet sérieux, je décris environ quinze à vingt primitives de composants, chacune avec ses accessoires et la règle d'utilisation pour chaque variante.
9. À faire et à ne pas faire. Règles explicites. "N'utilisez jamais de gris brut pour le corps du texte - utilisez toujours un jeton de contenu." "Ne jamais animer plus de 240 ms au premier plan UI." "Évitez les images à fond perdu sur le site marketing ; utilisez plutôt le composant multimédia encadré." Cette section est votre dernière ligne de défense contre la moyenne. Le modèle les traite comme des contraintes strictes. Plus vous en avez, plus votre marque survit.
C'est la structure. La spécification complète est documentée dans le référentiel google-labs-code/design.md et est simple à lire de bout en bout en une vingtaine de minutes, soit bien moins de temps que ce que vous avez passé à lutter contre une mauvaise sortie.
Il y a encore une chose à laquelle la spécification fait allusion mais n'aborde pas complètement, et c'est là que beaucoup de gens restent bloqués. Laissez-moi vous montrer ce que j'ai dû comprendre à mes dépens.
La tension entre les jetons et la prose dont personne ne vous prévient
Voici la partie de DESIGN.md qui m'a pris le plus de temps à intérioriser. Le format a deux voix. Le YAML en haut est destiné aux machines. La prose ci-dessous est destinée aux humains et aux modèles linguistiques. Vous avez besoin des deux, et vous avez besoin qu’ils acceptent.
La plupart des équipes se trompent dans deux directions.
Le premier mode d’échec : trop de YAML, pas assez de prose. Votre fichier ressemble à une configuration Tailwind. Chaque jeton a un nom et une valeur. Il n'y a pas de description environnante. Le modèle lit le fichier, traite les jetons comme des données brutes et finit par commettre les mêmes erreurs de moyenne qu'il aurait commises sans aucun fichier. Les jetons sont le quoi. Sans le quand, le modèle est encore en train de deviner.
Deuxième mode d’échec : trop de prose, pas assez de jetons. Votre fichier se lit comme un livre de marque PDF. De belles phrases sur l'âme du produit. Aucune valeur lisible par machine. Le modèle obtient l’ambiance mais ne peut pas réellement déterminer quel code hexadécimal exact va sur un bouton principal. Vous vous retrouvez avec une sortie qui semble correcte et brise tous les contrôles d'accessibilité.
Le truc, c'est le mariage. Jetons avec des phrases. Phrases qui se résolvent en jetons. Chaque valeur a une description de poste. Chaque description de poste indique une valeur.
J'écris le mien dans des tableaux. Voici un véritable morceau de mes jetons de surface, extraits d'un de mes projets en direct avec les détails de la marque échangés :
| Token | Hex | Dark | When to use |
|--------------------|----------|----------|-------------------------------------------------|
| surface-base | #FAF9F6 | #0E0E10 | The page background. Nothing sits behind this. |
| surface-raised | #FFFFFF | #161618 | Cards, list rows — one layer above base. |
| surface-elevated | #FFFFFF | #1C1C20 | Modals, popovers, menus. Floating UI only. |
| surface-sunken | #F2F1ED | #08080A | Input fields, inset wells, read-only regions. |
| surface-brand | #F4EFE8 | #221C12 | Brand-tinted backgrounds for promoted content. |
C'est cette quatrième colonne qui fait fonctionner le fichier. Un modèle indiquant « utiliser une surface élevée pour le UI flottant uniquement » ne peut jamais l'utiliser accidentellement pour un arrière-plan de page. Le jeton est une valeur. La phrase est la contrainte. Ensemble, ils constituent une instruction.
Ce modèle s'aligne sur les recommandations du W3C Design Token Community Group auxquelles font référence les spécifications Google, et il correspond clairement aux outils existants : les exportations style-dictionary, le plug-in de jetons de conception de Tailwind, le format d'exportation DTCG qui réside dans la CLI design.md. Rien de tout cela n’est nouveau. Ce qui est nouveau, c'est d'avoir un seul fichier canonique où les jetons et la justification cohabitent, contrôlés par la version, ingérés par chaque agent de codage qui touche le projet.
Si vous avez lu mon article précédent sur le flux de travail du système de conception AI avec Claude et Figma MCP, vous avez déjà vu le modèle de jeton à quatre colonnes. DESIGN.md est le format qui le standardise enfin. Le format que je recherchais est le format Google qui a fini par être expédié.
Jusqu'à présent, nous avons parlé du dossier. Laissez-moi maintenant parler de la partie qui transforme le dossier en fossé.
Compétences, packs de remix et composition du goût
La percée n’est pas due uniquement à DESIGN.md. La percée a été DESIGN.md plus la couche qui s'est développée dessus dans les quarante-cinq jours suivant la suppression des spécifications.
La communauté a évolué rapidement. Début mai 2026, trois éléments étaient entrés en production :
La collection Awesome-design-md. Un référentiel organisé par la communauté sur VoltAgent/awesome-design-md contenant plus de cinquante fichiers DESIGN.md extraits de marques du monde réel : Stripe, Vercel, Notion, Supabase, Linear, NVIDIA, Apple, x.ai. La collection est passée de zéro à 35 000 étoiles en dix jours, puis à 68 000 fin avril, puis au-delà de 71 000. Le ratio de fork se situe à plus de 12 pour cent, ce qui est sauvage – pour le contexte, Awesome-go est à 7,8 pour cent, Awesome-python à 9,5 pour cent. Les gens ne se contentent pas de mettre ces fichiers dans leurs favoris. Ils les entraînent dans des projets.
L'intégration de Claude Design. Lorsque Anthropic a expédié Claude Design le 17 avril 2026 – quatre jours avant que Google ne rende le format open source – il a atterri avec une profonde compatibilité DESIGN.md. Vous pouvez déposer un fichier DESIGN.md dans Claude Design et obtenir un échafaudage UI complet en une seule fois. Jetons, échelle de caractères, boutons, cartes, navigation, kit de prévisualisation fonctionnel. J'ai couvert le premier aperçu dans [ma revue de conception Claude] (/claude-design-anthropic-first-look) - l'intégration avec DESIGN.md est la partie qui a le mieux vieilli.
Remix basé sur les compétences. C'est là que les choses deviennent intéressantes. La communauté a commencé à proposer des « compétences » – de petits plugins de démarque ciblés qui se superposent à un DESIGN.md pour le pousser dans une direction spécifique. Traitements de surface skeuomorphes. Effets d'accentuation de style laser. Règles de composition éditoriales. Modèles d'interaction 3D basés sur WebGL. Début mai, plus de soixante compétences publiques étaient disponibles, et ce nombre augmente chaque semaine.
Le flux de travail qui en a résulté est quelque chose auquel je suis encore en train de m’adapter. Vous écrivez votre base DESIGN.md une fois. Vous appliquez des compétences en superposition. Les compétences ne remplacent pas vos jetons : elles les étendent, en ajoutant des couches modulaires que l'agent peut composer avec votre base. Vous choisissez deux familles esthétiques qui ne devraient pas fonctionner ensemble. Vous laissez le modèle les remixer à travers la couche de compétences. Vous itérez sur le résultat.
C'est la boucle que la communauté source ne cesse de décrire comme « itération contre remix ». L'itération est le lent raffinement d'une seule direction de conception : déplacer un bouton de deux pixels, resserrer un paragraphe, affiner un état de survol. Remix crée une toute nouvelle direction en combinant deux fichiers DESIGN.md non liés ou en superposant une compétence par-dessus une compétence existante. Les deux comptent. L'itération produit du vernis. Remix produit de nouvelles catégories.
Voici l'article que personne ne vous dit dans la copie marketing. Les produits matures exécutent des milliers d’itérations. Je n'exagère pas. Les équipes avec lesquelles j'ai parlé et qui utilisent sérieusement cette pile signalent entre 4 000 et 10 000 itérations rapides par surface polie avant leur expédition. Le coût est réel : en termes de jetons, de temps et d’attention. Le résultat, lorsqu’il est bien fait, est le genre de qualité de conception pour laquelle il fallait auparavant un studio de six personnes pour le produire.
Si cela semble cher, ça l’est. Si cela semble plus lent que d'appliquer un modèle sur un projet, c'est aussi cela. Ce qui a changé, c'est le plafond. Avec un DESIGN.md et une bibliothèque de compétences saine, un opérateur solo peut désormais atteindre la qualité de conception de production sur autant de produits que son jugement le permet.
Quelle est la vraie conversation. Laissez-moi y arriver.
Le goût est le nouveau fossé – et presque personne n'y croit encore
Si vous êtes un designer qui lisez ceci et que votre travail vous rend nerveux, je veux vous donner la version du futur en laquelle je crois réellement.
Le pixel-push a disparu. Le travail de documentation exhaustif – chaque jeton décrit, chaque variante de composant cataloguée, chaque état rédigé à la main – ce travail est désormais un coût unique payé dans un fichier de démarque. L'élément de campagne « 20 heures de maintenance du système de conception par semaine » qui figurait autrefois sur la feuille de route de chaque équipe produit est en train de tomber vers zéro. Les vraies équipes signalent une réduction de 60 à 80 % de la maintenance du système de conception au cours du premier trimestre suivant l'adoption correcte de DESIGN.md.
Ce qui ne disparaît pas – ce qui devient plus précieux, pas moins – c'est le jugement qui décide en premier lieu de ce qui doit figurer dans le dossier.
Le DESIGN.md que vous écrivez est la chose. C'est les douves. Le fichier de 412 lignes à la base de mon projet marketing ? Ce fichier est la marque du produit. Chaque variation, chaque page, chaque e-mail, chaque écran, le modèle génère des traces. Le dossier est en amont de tout. Et le fichier est exactement aussi bon que le goût de celui qui l’a écrit.
C’est la partie qui n’atteint pas encore la plupart des gens. Ils examinent le design du AI et constatent une démocratisation : n'importe qui peut désormais expédier un UI raffiné. Cette partie est vraie. Mais la démocratisation est un niveleur au bas de la courbe, pas au sommet. Le bas de la courbe s’améliore considérablement. Le haut de la courbe s'améliore également, plus rapidement et reste différencié, car les personnes situées au sommet sont celles dont les goûts sont suffisamment informés pour écrire un DESIGN.md qui produit quelque chose que la médiane ne peut pas produire.
L'avenir du travail de conception, tel que je le lis depuis le flux de travail, est à peu près le suivant :
Plus de jugement par minute. Vous passerez moins de temps à pousser les pixels et plus de temps à décider de ce qui devrait exister. L'unité de travail passe de « produire » à « décider ».
La saturation de référence comme pratique réelle. Vous avez besoin d'un deuxième cerveau pour concevoir. Une bibliothèque de références (captures d'écran, films, magazines, emballages, études de mouvement) que vous avez réellement intériorisées, et pas seulement mises en signet. Les agents feront la synthèse. Votre travail consiste à savoir ce qui mérite d’être synthétisé en premier lieu.
** Goût de niche authentique plutôt que maîtrise générique. ** Un designer avec un goût profond pour une esthétique spécifique - Y2K, Suisse, minimalisme japonais, Web brutaliste, Memphis, éditorial - surpassera un généraliste en utilisant les mêmes outils. Les agents penchent vers la moyenne. Le DESIGN.md que vous écrivez est ce qui les en éloigne.
Opérateurs solo gérant plusieurs produits. Je connais trois personnes qui gèrent désormais quatre à sept produits en parallèle en tant que fondateurs solo, chacun avec son propre DESIGN.md, chacun avec sa propre marque. Aucun d’eux ne faisait ça il y a deux ans. Le goulot d’étranglement était autrefois la production. Le goulot d’étranglement est désormais la gestion de portefeuille.
Le marketing comme extension du jugement de conception. Lorsque le fichier génère des pages de destination, des créations publicitaires, des cartes sociales, des pitch decks, le tout à partir de la même source de vérité, la frontière entre « concevoir le produit » et « commercialiser le produit » s'effondre. Le même goût qui a écrit le DESIGN.md est celui qui façonne chaque point de contact client.
Je veux être honnête sur la partie sur laquelle je me trompe encore. Je ne sais pas encore si les agences vont s'adapter. Je ne sais pas encore si l’enseignement du design rattrapera son retard. Je ne sais pas encore si la spécification elle-même tiendra - la spécification de Google est dans alpha, et il existe déjà au moins trois formats concurrents dans l'écosystème (la variante de Anthropic, la version de l'équipe Cursor, quelques-unes des alternatives BYOK locales). L’un d’eux va probablement se consolider. Je parierais, aujourd'hui, sur les Google, car la dynamique open source et l'avance en matière d'outillage sont trop en avance pour qu'un fork puisse rattraper son retard. Mais je me suis déjà trompé sur ce genre de pari.
Ce sur quoi je ne me trompe pas, c'est la direction. Si vous passez votre temps à pousser manuellement des pixels en 2026, vous effectuez le travail que les fichiers de démarque font désormais gratuitement.
Comment démarrer réellement, sans brûler un week-end
Je veux vous laisser avec la version de "pour commencer" que j'aurais aimé que quelqu'un me remette il y a un mois. Évitez les longs didacticiels d'intégration. Voici ce qu'il faut faire cette semaine.
Premier jour, soir. Choisissez le plus petit projet live que vous avez. Site de commercialisation. Produit secondaire. Même une seule page de destination. Lisez trois vrais fichiers DESIGN.md à partir de VoltAgent/awesome-design-md : Linear, Stripe et un dont l'esthétique correspond réellement à la vôtre. Lisez-les attentivement. Le format deviendra évident dans une vingtaine de minutes.
Deuxième jour. Écrivez votre propre DESIGN.md à partir de zéro, à la main, dans un éditeur de texte brut. N'utilisez pas de générateur. L’intérêt de ce fichier est qu’il vous oblige à prendre des décisions explicites au niveau des goûts. Un générateur cache ces décisions. Visez 300 à 600 lignes. Passez plus de temps sur les sections Description, Présentation et Choses à faire et à ne pas faire. Ce sont les sections que le modèle utilise pour rompre les égalités.
Troisième jour. Déposez le fichier à la racine de votre projet. Ouvrez Claude Code, Cursor, Codex ou tout autre agent que vous utilisez. Dites-lui de lire DESIGN.md et de reconstruire une seule page ou un seul composant en utilisant uniquement les jetons et les règles qui y sont définis. Regardez ce qui revient. Notez où les choses se trompent : ces erreurs indiquent des lacunes dans votre fichier, pas dans le modèle.
À partir du quatrième jour. Itérez sur le fichier. Chaque fois que l’agent se trompe d’une manière que vous n’aviez pas prévue, demandez-lui pourquoi. La réponse est presque toujours que votre fichier ne le précise pas. Ajoutez la règle. Le fichier s'améliore à chaque correctif. Au bout de deux semaines d'utilisation régulière, il se stabilise — à ce stade, le rendement de l'agent commence à sembler distinctement le vôtre, et non générique.
Si vous souhaitez une rampe d'accès plus rapide, le site getdesign.md répertorie les guides d'installation pour Claude Code, Cursor, Kiro, Windsurf et Stitch. La spécification officielle se trouve sur github.com/google-labs-code/design.md. La CLI pour la validation, la comparaison et l'exportation vers Tailwind ou DTCG réside dans le même dépôt. Rien de tout cela n’est protégé par un paywall. La spécification est Apache 2.0. Les fichiers communautaires sont open source. La couche de compétences est pour la plupart gratuite.
J'ai une confession à vous laisser. Le samedi que j'ai décrit en haut de cet article — les trois produits en trois heures — je travaillais déjà sur une base de trois mois avec ce format. La première fois que j'ai essayé d'écrire un DESIGN.md, cela m'a pris un après-midi entier et le résultat était médiocre. Le second a duré trois heures et était utilisable. Le cinquième a duré vingt minutes et a été excellent.
Le format est simple. Le goût requis pour bien le remplir ne l’est pas. C’est la partie qui ne se démocratise pas. C'est la partie qui devient plus précieuse, et non moins, à mesure que ces agents s'améliorent.
Écrivez votre fichier. Prenez votre temps. La prochaine décennie de travail de conception se déroulera en aval de la démarque que vous écrivez cette semaine.
Questions fréquemment posées
Quelle est la différence entre DESIGN.md et design.mmd ?
Ils font référence au même format. DESIGN.md est le nom de fichier canonique Google fourni dans la spécification github.com/google-labs-code/design.md. L'orthographe design.mmd apparaît dans certaines vidéos et articles de la communauté comme une transcription alternative. Le contenu du fichier est identique : corps de démarque avec présentation facultative du jeton YAML, sections dans l'ordre des spécifications. Utilisez DESIGN.md pour la compatibilité avec les outils officiels.
Ai-je besoin d'un concepteur pour écrire un fichier DESIGN.md ?
Non, mais il faut du goût. Le fichier impose chaque décision de marque dans un langage explicite : justification des couleurs, hiérarchie typographique, logique d'espacement, règles d'utilisation des composants. Si vous ne pouvez pas répondre vous-même à ces questions, le fichier que vous écrivez produira une sortie générique quel que soit l'agent qui le lit. Un non-designer avec un goût prononcé et une saturation de références battra un designer qui copie un modèle. Voir la section « Le goût est le nouveau fossé » ci-dessus pour l'argumentation complète.
Quels agents AI prennent actuellement en charge DESIGN.md ?
Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, Kiro, Windsurf et Claude Design de Anthropic lisent tous DESIGN.md de manière native. La plupart lisent le fichier comme une simple démarque – aucun plugin n’est requis. L'outil Google Stitch était le propriétaire du format d'origine et possède toujours l'intégration la plus approfondie. Certains agents prennent également en charge l'exportation facultative de jeton YAML générée par la CLI design.md.
Combien de temps faut-il pour écrire un DESIGN.md utilisable ?
Trois à six heures pour une première version sérieuse sur un vrai projet. Vingt à quarante minutes pour les projets ultérieurs une fois que vous avez votre propre modèle. Les sections Description, Présentation et Choses à faire et à ne pas faire prennent le plus de temps et constituent les parties du fichier qui ont le plus grand impact : investissez-y avant d'être obsédé par le nombre de jetons.
DESIGN.md remplacera-t-il Figma ?
Non. DESIGN.md remplace le document de transfert entre la conception et le code, ainsi que la couche de données de formation entre votre marque et un agent. Figma reste le lieu idéal pour l'exploration visuelle, le prototypage de mouvement et la révision de la conception. Le modèle sur lequel la plupart des équipes convergent à partir de mai 2026 : explorer dans Figma, codifier dans DESIGN.md, échafauder avec un agent, affiner dans le code. Le fichier est la source de vérité qui circule entre chaque outil.
Travaillons ensemble
Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.
- Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
- Portefeuille : mejba.me
- Ramlit Limited (solutions d'entreprise) : ramlit.com
- ColorPark (conception et image de marque) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
