DESIGN.md: het AI-designframework dat overal zichtbaar was
Ik had een zaterdag in de rij om drie producten die ik onder verschillende merknamen verzend, opnieuw te ontwerpen. Marketingsite voor één. Mobiele app-schermen voor een ander. Een pitchdeck voor de derde. Drie verschillende esthetiek. Drie verschillende doelgroepen. Drie verschillende stapels. Vorig jaar zou dit een project van vier weken zijn geweest. Vorige maand, met Claude Code en een stapel vaardigheden, was het een driedaagse sleur. Deze week deed ik het vóór de lunch.
Het ding dat veranderde was een enkel bestand. Zeshonderdtwaalf regels met afwaarderingen vormen de basis van elk project. Een naam die ik al weken op mijn Twitter-feed zag verschijnen, maar die ik niet de moeite had genomen om daadwerkelijk te gebruiken. DESIGN.md. Of, afhankelijk van welke transcriptie u leest, design.mmd. Hetzelfde bestand. Verschillende toetsen op hetzelfde instrument.
Ik heb er bijna een maand lang ongelijk in gehad. Ik dacht dat het weer een design-token YAML was, verpakt in een hype-cyclus. Ik dacht: "geweldig, nog een specificatie om te onthouden, nog een standaard om te verlaten als de volgende over zes weken wordt verzonden." Ik ging op mijn handen zitten en zag de GitHub-sterren klimmen. De officiële google-labs-code/design.md-repo overschreed de 10.000 sterren acht dagen nadat Google de specificatie op 21 april 2026 open source had gemaakt. De door de gemeenschap aangestuurde VoltAgent/awesome-design-md-collectie overschreed in hetzelfde venster de 68.000 en bevindt zich nu ergens ten noorden van de 71k vanaf deze week. Dergelijke cijfers komen, in een zo verzadigde markt, niet voor bij een YAML-bestand.
Wat ik miste was dat DESIGN.md niet echt een bestandsformaat is. Het is een protocol. Een manier om een vreemde uw merk te leren in ongeveer de tijd die nodig is om koffie te schenken, waarbij de vreemdeling toevallig elke codeeragent is die u ooit zult gebruiken. Toen dat eenmaal klikte, werd mijn hele AI-ontwerpworkflow eromheen geherstructureerd. Dit artikel is de versie van de uitleg die ik graag vier weken eerder van iemand had gekregen.
Ik zal je laten zien wat er feitelijk gebeurt als je stopt met ertegen te vechten.
Waarom "Just Prompt The Model" niet meer genoeg was
Dit is de faalmodus die elk designergebouw met AI in 2026 minstens één keer heeft getroffen.
Je start een nieuw project. U vraagt Claude Code of Cursor of Codex met iets redelijks: "bouw een dashboardheld-sectie voor een fintech-app, modern en schoon." Het model gaat aan het werk. Het levert iets op. Wat het produceert is prima. Eigenlijk is het meer dan prima: het is technisch correct, het gebruikt verstandige standaardwaarden, de spatiëring is gelijkmatig, de typografische schaal is logisch. En toch, als je één blik werpt, voel je de slop al.
Je kunt er geen seconde de vinger op leggen. Dan kan dat. De schaduw is verkeerd. Niet verkeerd in de zin van kapot – verkeerd in de zin dat elk ander door AI gegenereerd dashboard op internet exact deze schaduw heeft. Het blauw is hetzelfde blauw dat Vercel gebruikt, hetzelfde blauwe oude ontwerp van Stripe dat werd gebruikt, hetzelfde blauw dat elke marketingsite van het YC-bedrijf in 2024 gebruikte. Je kijkt naar een statistisch gemiddelde als je een merkkostuum draagt.
Dit is hetgene waarvoor niemand u waarschuwt als ze u AI-ontwerptools verkopen. Het model neemt geen creatieve beslissing. Het is een middeling. Het middelt uw vage prompt tegen elke andere interface die de trainingsgegevens ooit hebben getoond, en het resultaat komt direct boven op de mediaan terecht. Mediaan UI. Mediane afstand. Middelmatig merk. De reden dat het generiek aanvoelt, is omdat het is.
Ontwerpers hebben dit exacte probleem al een groot deel van een jaar aangekaart. Er zweeft nu een term rond – ‘Claude slop’, ‘Cursor slop’, kies je model – en die is lelijker dan het ontwerp zelf. Het vertelt je iets waar: het knelpunt is niet langer het model. Het knelpunt is of het model enig idee heeft hoe jouw smaak eruit zou moeten zien.
Dat is het gat dat DESIGN.md opvult. Niet door slimmer te zijn dan het model. Doordat het een contract is, kan het model daadwerkelijk worden gevolgd.
We zullen zo meteen op het formaat zelf ingaan. Maar eerst moet ik je vertellen over het moment waarop ik ophield met sceptisch te zijn.
De eerste keer dat ik zag dat het echt werkte
Ik had een marketingsite voor een bijproduct. Solo founder-vibe – een van die minimalistische landingspagina’s met een held, drie functieblokken, sociaal bewijs, prijzen, veelgestelde vragen. Ik had het merk laten schetsen in Figma maar had nog niets geïmplementeerd. Ik stond op het punt te doen wat ik altijd doe: de eerste passage met de hand coderen en deze vervolgens ter verfijning aan Claude Code overhandigen.
In plaats daarvan probeerde ik het DESIGN.md-pad. Ik heb een bestand van 412 regels geschreven waarin elke merkbeslissing in gewoon Engels wordt beschreven. Kleur fiches met telkens een zin erop wanneer ze van toepassing zijn. Typografieschaal met de reden voor elke stap. Afstandssysteem gekoppeld aan een 4px-basis. Stem en toon. Een speciale 'Anti-Patterns'-sectie met de acht fouten die elke agent nooit mag maken in dit project. Ik heb het bestand in de projectroot neergezet. Vervolgens opende ik Claude Code en typte precies dit:
Lees DESIGN.md. Bouw vervolgens een marketinglandingspagina voor mij met alleen de tokens, componenten en regels die daar zijn gedefinieerd. Hero, drie featureblokken, social proof strip, prijzen, FAQ.
Wat vijfenveertig seconden later terugkwam, was geen tocht. Het was de pagina. Pixeldicht bij wat ik had geschetst in Figma zonder Figma ooit te openen. De held gebruikte mijn aangepaste schreefkop op de juiste maat. De prijskaart gebruikte mijn ‘verhoogde’ oppervlaktestijl – de juiste, niet de modale – omdat ik in het bestand had beschreven wanneer elk oppervlak werd aangebracht. De zweefstatus van de knop was de juiste toonverschuiving, met de juiste overgangstijd, omdat die timing bestond in de bewegingssectie.
Ik zat daar ongeveer dertig seconden te verwerken. Toen probeerde ik het te breken. Ik heb gevraagd om een getuigenisgedeelte toe te voegen. Er werd gebruik gemaakt van de juiste kaartstijl. Ik vroeg om een vergelijkingstabel met drie concurrenten. Er werd voor de juiste tafeldichtheidsvariant gekozen. Ik vroeg om een donkere modus. Het paste elk token correct opnieuw toe zonder dat ik het hoefde te herinneren aan de merkgekleurde achtergronden die ik had gedefinieerd voor gepromote inhoud.
Het hele gebeuren kostte me veertig minuten. Het DESIGN.md-bestand kostte me ongeveer drie uur om correct te schrijven. Veertig minuten voor de pagina. Drie uur voor het bestand dat nu oneindig consistente pagina's genereert. Die wiskunde is het hele punt.
Sindsdien heb ik die workflow op vier afzonderlijke producten verzonden, elk met zijn eigen DESIGN.md. De samenstelling wordt belachelijk na het tweede project. Bij project drie had ik een sjabloon die ik kon kopiëren, plakken en aanpassen en het bestand was in twintig minuten klaar.
Maar niets van dit alles werkt als het bestand slordig is. Dus laat me je laten zien wat het bestand eigenlijk bevat.
Wat zit er in een DESIGN.md-bestand, sectie voor sectie
Het formaat Google open source heeft een specifieke structuur. Het is geen essay in vrije vorm. De huidige specificatie definieert een markdown-body met vooraf gedefinieerde secties, optionele YAML-voortekst bovenaan voor machinaal leesbare tokens en een strikte ordeningsregel: secties kunnen worden weggelaten, maar de aanwezige moeten in de specificatievolgorde verschijnen.
Hier zijn de negen secties waar de specificatie om vraagt, met hoe ik ze daadwerkelijk gebruik:
1. Versie en naam. Twee regels. De versietag is momenteel alpha en bestaat zodat toekomstige tools weten op welke spec-editie het bestand zich richt. De naam is de projectnaam. Je zult denken dat dit wegwerpmetagegevens zijn. Dat is het niet. Wanneer u een DESIGN.md afsplitst van een zusterproject en vergeet de naam ervan te wijzigen, bouwt elke agent in uw gereedschapsketen vol vertrouwen "AcmeBank" UI voor een wellnessmerk. Ik heb dit zien gebeuren.
2. Beschrijving. Eén enkele paragraaf die de positionering en persoonlijkheid van het product beschrijft. Dit is de 'ziel'-sectie waar de brongemeenschap het steeds over heeft. De mijne leest meer als een creatieve opdracht dan als een specificatie: drie zinnen over voor wie het product is bedoeld, twee zinnen over welk gevoel het zou moeten oproepen, en één zin geeft aan wat het absoluut niet is. Het model gebruikt dit om de banden te verbreken bij elke dubbelzinnige beslissing stroomafwaarts. Als u dit gedeelte overslaat, kunt u flauwe verwachtingen verwachten.
3. Overzicht. Een holistische look-and-feelparagraaf. Waar de beschrijving gaat over positionering, gaat het overzicht over visueel karakter. Is dit product warm of koel? Dicht of luchtig? Luid of ingetogen? Redactioneel of utilitair? Dit is het gedeelte waar uw smaak in taalvorm leeft. Ik houd de mijne specifiek: "Redactioneel rustig. Warme neutrale kleuren, ingetogen accentgebruik, royale witruimte. De koppen doen het zware werk; de ondersteunende tekst gaat een stapje terug. Geen verlopen op de voorgrond. Geen glaseffecten. Geen onnodige bewegingen."
4. Kleuren. Hex-waarden toegewezen aan semantische namen. De truc waarvoor ik drie projecten moest leren: noem kleuren niet naar hun uiterlijk. Noem ze naar hun baan. surface-base niet gray-50. action-primary niet indigo-600. status-warning-subtle niet amber-100. Elk token krijgt een beschrijving van één zin waarin wordt aangegeven wanneer het moet worden gebruikt. Het zijn de beschrijvingen die het model ervan weerhouden om om 02.00 uur de verkeerde blauwe te pakken.
5. Typografie. Lettertypefamilies, schaal, gewichten, lijnhoogtes, letterafstand. Twaalf tot vijftien tokens is typisch. De mijne heeft er dertien: display, kop-xl, kop-l, kop-m, kop-s, body-l, body, body-s, bijschrift, code, knop, label, wenkbrauw. Elk met expliciete regels over waar het verschijnt.
6. Lay-out. Rasters, breekpunten, schaal van basisafstand. Of u nu 4px of 8px als eenheid gebruikt. Hoe compact uw typische pagina is. Of uw dakgoten nu schalen met een breekpunt of vast blijven. Hier codeer je het ritme van het merk.
7. Hoogte en diepte. Schaduwen, z-indexlagen, de visuele stratificatieregels van het systeem. Dit is het gedeelte waarvan de meeste teams vergeten dat het bestaat. Het doet er meer toe dan u denkt: de helft van de slop die u ziet in de door AI gegenereerde UI komt van het model dat schaduwwaarden uit de gemiddelden van trainingsgegevens haalt. Als uw bestand geen hoogte specificeert, zal het model een gok uitvoeren en zal de gok er uitzien als elk ander gegenereerd dashboard.
8. Componenten. Patronen voor knoppen, kaarten, formulieren, navigatie, met alle varianten en statussen. Dit is waar het bestand lang wordt. Voor een serieus project beschrijf ik grofweg vijftien tot twintig componentprimitieven, elk met hun rekwisieten en de gebruiksregel voor elke variant.
9. Do's en don'ts. Expliciete regels. "Gebruik nooit onbewerkt grijs voor hoofdtekst; gebruik altijd een inhoudstoken." "Animeer nooit langer dan 240 ms op de voorgrond UI." "Vermijd full-bleed afbeeldingen op de marketingsite; gebruik in plaats daarvan de ingelijste mediacomponent." Dit gedeelte is je laatste verdedigingslinie tegen middeling. Het model beschouwt deze als harde beperkingen. Hoe meer je hebt, hoe meer je merk overleeft.
Dat is de structuur. De volledige specificaties zijn gedocumenteerd in de google-labs-code/design.md-repository en zijn eenvoudig van begin tot eind te lezen in ongeveer twintig minuten - veel minder tijd dan je hebt besteed aan het bestrijden van slechte resultaten.
Er is nog iets waar de specificatie naar verwijst, maar niet volledig aan de orde komt, en dat is waar veel mensen vastlopen. Ik zal je laten zien wat ik op de harde manier moest uitzoeken.
De spanning tussen tokens en proza waar niemand je voor waarschuwt
Hier is het deel van DESIGN.md dat me het langst kostte om het te internaliseren. Het formaat heeft twee stemmen. De YAML bovenaan is voor machines. Het onderstaande proza is voor mensen en taalmodellen. Je hebt beide nodig, en je hebt ze nodig om * akkoord te gaan *.
De meeste teams hebben dit in twee richtingen verkeerd.
De eerste faalmodus: te veel YAML, niet genoeg proza. Uw bestand ziet eruit als een Tailwind-configuratie. Elk token heeft een naam en een waarde. Er is geen omringende beschrijving. Het model leest het bestand, behandelt de tokens als onbewerkte gegevens en maakt uiteindelijk dezelfde middelingsfouten die het zonder enig bestand zou hebben gemaakt. De tokens zijn de wat. Zonder wanneer is het model nog steeds aan het raden.
De tweede faalmodus: te veel proza, niet genoeg tokens. Uw bestand leest als een pdf met een merkboek. Mooie zinnen over de ziel van het product. Geen machinaal leesbare waarden. Het model snapt de sfeer, maar kan niet precies vaststellen welke exacte hexadecimale code op een primaire knop hoort. Je krijgt uiteindelijk een uitvoer die goed aanvoelt en die elke toegankelijkheidscontrole doorbreekt.
De truc is het huwelijk. Tokens met zinnen. Zinnen die worden omgezet in tokens. Elke waarde heeft een functiebeschrijving. Elke functiebeschrijving verwijst naar een waarde.
Ik schrijf de mijne in tabellen. Hier is een echt deel van mijn oppervlaktetokens, opgehaald uit een van mijn live projecten waarbij de merkdetails zijn verwisseld:
| 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. |
Die vierde kolom zorgt ervoor dat het bestand werkt. Een model met de tekst "gebruik alleen een verhoogd oppervlak voor zwevende UI" kan dit nooit per ongeluk gebruiken voor een pagina-achtergrond. Het token is een waarde. De zin is de beperking. Samen vormen ze een instructie.
Dit patroon komt overeen met de aanbevelingen van de W3C Design Token Community Group, de Google-specificatiereferenties, en wordt netjes gekoppeld aan bestaande tools: style-dictionary-exports, de ontwerptokens-plug-in van Tailwind, het DTCG-exportformaat dat aanwezig is in de design.md CLI. Niets hiervan is nieuw. Wat nieuw is, is het hebben van één enkel canoniek bestand waarin de tokens en de grondgedachte samenleven, versiegestuurd zijn, opgenomen door elke codeeragent die met het project te maken heeft.
Als je mijn eerdere stuk over de AI-ontwerpsysteemworkflow met Claude en Figma MCP hebt gelezen, heb je het tokenpatroon met vier kolommen al gezien. DESIGN.md is het formaat dat het uiteindelijk standaardiseert. Het formaat waar ik naar streefde is het formaat dat Google uiteindelijk werd verzonden.
Tot nu toe hebben we het over het bestand gehad. Laat me het nu hebben over het deel dat het bestand in een gracht verandert.
Vaardigheden, remixpakketten en de samenstelling van smaak
De doorbraak was niet alleen DESIGN.md. De doorbraak was DESIGN.md plus de laag die daarbovenop groeide binnen vijfenveertig dagen nadat de specificaties waren verdwenen.
De gemeenschap kwam snel in beweging. Begin mei 2026 waren drie dingen in productie gegaan:
De awesome-design-md-collectie. Een door de community beheerde repository op VoltAgent/awesome-design-md met meer dan vijftig DESIGN.md-bestanden die zijn geëxtraheerd uit echte merken: Stripe, Vercel, Notion, Supabase, Linear, NVIDIA, Apple, x.ai. De verzameling ging van nul naar 35.000 sterren in tien dagen, vervolgens naar 68.000 eind april en vervolgens voorbij de 71.000. De fork-ratio bedraagt ruim 12 procent, wat wild is – voor de context bedraagt awesome-go 7,8 procent, awesome-python 9,5 procent. Mensen maken niet alleen een bladwijzer van deze bestanden. Ze betrekken ze bij projecten.
De Claude Design-integratie. Toen Anthropic Claude Design op 17 april 2026 uitbracht – vier dagen voordat Google het formaat open source maakte – kwam het met een diepe DESIGN.md-compatibiliteit terecht. U kunt een DESIGN.md-bestand in Claude Design plaatsen en in één keer een volledig UI-scaffold verkrijgen. Tokens, typeschaal, knoppen, kaarten, navigatie, werkende preview-kit. Ik heb de eerste look besproken in [mijn Claude ontwerprecensie] (/claude-design-anthropic-first-look) - de integratie met DESIGN.md is het onderdeel dat het beste verouderd is.
Op vaardigheden gebaseerde remixen. Dit is waar het interessant wordt. De community begon 'vaardigheden' te leveren: kleine markdown-plug-ins die bovenop een DESIGN.md lagen om deze in een specifieke richting te duwen. Skeuomorfe oppervlaktebehandelingen. Accenteffecten in laserstijl. Redactionele en gedrukte compositieregels. WebGL-gestuurde 3D-interactiepatronen. Begin mei waren er ruim zestig publieke vaardigheden beschikbaar, en dit aantal stijgt wekelijks.
De workflow die daaruit voortvloeide, is iets waar ik nog steeds aan aan het wennen ben. Je schrijft je basis DESIGN.md één keer. Je past vaardigheden toe als overlays. De vaardigheden vervangen je tokens niet; ze breiden ze uit en voegen modulaire lagen toe die de agent samen met je basis kan samenstellen. Je kiest twee esthetische families die niet samen zouden moeten werken. Je laat het model ze remixen via de vaardigheidslaag. Je herhaalt het resultaat.
Dit is de lus die de brongemeenschap steeds beschrijft als 'iteratie versus remix'. Iteratie is de langzame verfijning van een enkele ontwerprichting: een knop twee pixels verplaatsen, een alineadoek strakker maken, een zweeftoestand verfijnen. Remix creëert een geheel nieuwe richting door twee niet-gerelateerde DESIGN.md-bestanden te combineren of een vaardigheid bovenop een bestaande te leggen. Beide zijn belangrijk. Iteratie levert polijstmiddel op. Remix produceert nieuwe categorieën.
Hier is het stuk dat niemand u vertelt in de marketingkopie. Volwassen producten ondergaan duizenden iteraties. Ik overdrijf niet. De teams met wie ik heb gesproken die deze stapel serieus gebruiken, rapporteren 4.000 tot 10.000 promptgestuurde iteraties per gepolijst oppervlak voordat ze worden verzonden. De kosten zijn reëel: qua symboliek, qua tijd en qua aandacht. De output is, als het goed wordt gedaan, van het soort ontwerpkwaliteit waarvoor je vroeger een studio van zes personen nodig had.
Als dat duur klinkt: dat is het ook. Als het langzamer klinkt dan een sjabloon op een project plakken, is dat ook het geval. Wat veranderd is, is het plafond. Met een DESIGN.md en een bibliotheek met gezonde vaardigheden kan een solo-operator nu productie-ontwerpkwaliteit bereiken voor zoveel producten als zijn oordeel kan ondersteunen.
Dat is het echte gesprek. Laat mij ter zake komen.
Smaak is de nieuwe gracht – en bijna niemand gelooft het nog
Als je een ontwerper bent die dit leest en zenuwachtig bent over je werk, wil ik je de versie van de toekomst geven waarin ik echt geloof.
Pixel-pushen is verdwenen. Het uitgebreide documentatiewerk – elk afzonderlijk token beschreven, elke afzonderlijke componentvariant gecatalogiseerd, elke afzonderlijke staat met de hand opgesteld – dat werk is nu een eenmalige kost die wordt betaald in een afwaarderingsbestand. Het regelitem '20 uur ontwerpsysteemonderhoud per week' dat vroeger op de roadmap van elk productteam stond, daalt richting nul. Echte teams melden een vermindering van 60 tot 80 procent in het onderhoud van ontwerpsystemen binnen het eerste kwartaal na correcte adoptie van DESIGN.md.
Wat niet verdwijnt – wat meer waardevol wordt, niet minder – is het oordeel dat bepaalt wat er überhaupt in het dossier moet staan.
De DESIGN.md die je schrijft is het ding. Het is de gracht. Het 412-regelige bestand dat de basis vormt van mijn marketingproject? Dat bestand is het merk van het product. Elke variatie, elke pagina, elke e-mail, elk scherm dat het model ooit genereert, is daar terug op terug te leiden. Het bestand bevindt zich stroomopwaarts van alles. En het bestand is precies zo goed als de smaak van degene die het heeft geschreven.
Dit is het deel dat voor de meeste mensen nog niet aankomt. Ze kijken naar het AI-ontwerp en ze zien democratisering: iedereen kan nu een gepolijste UI verzenden. Dat deel is waar. Maar democratisering is een leveller aan de onderkant van de curve, niet aan de top. De onderkant van de curve wordt dramatisch beter. De top van de curve wordt ook beter, sneller en blijft gedifferentieerd, omdat de mensen aan de top degenen zijn wier smaak voldoende geïnformeerd is om een DESIGN.md te schrijven die iets voortbrengt dat de mediaan niet kan produceren.
De toekomst van ontwerpwerk, zoals ik het vanuit de workflow lees, is grofweg dit:
Meer beoordelingsvermogen per minuut. U bent minder tijd kwijt aan het pushen van pixels en meer tijd aan het beslissen wat er moet gebeuren. De werkeenheid verschuift van ‘produceren’ naar ‘beslissen’.
Referentieverzadiging als praktijk. Voor ontwerpen heb je een tweede brein nodig. Een bibliotheek met referenties – screenshots, films, tijdschriftspreads, verpakkingen, bewegingsstudies – die je daadwerkelijk hebt geïnternaliseerd, en niet alleen als bladwijzer hebt gemaakt. De agenten zullen de synthese uitvoeren. Het is jouw taak om in de eerste plaats te weten wat de moeite waard is om te synthetiseren.
Authentieke niche-smaak boven generiek meesterschap. Een ontwerper met een diepe smaak in één specifieke esthetiek – Y2K, Zwitsers, Japans minimalisme, Brutalist web, Memphis, Editorial – zal een generalist overtreffen die dezelfde tools gebruikt. De agenten neigen naar het gemiddelde. De DESIGN.md die u schrijft, is wat hen ervan wegtrekt.
Solo-operators die meerdere producten exploiteren. Ik ken drie mensen die nu vier tot zeven producten parallel exploiteren als solo-oprichters, elk met zijn eigen DESIGN.md, elk met zijn eigen merk. Geen van hen deed dat twee jaar geleden. Het knelpunt was vroeger de productie. Het knelpunt is nu het portefeuillebeheer.
Marketing als verlengstuk van het ontwerpoordeel. Wanneer het bestand landingspagina's, advertenties, sociale kaarten en pitchdecks genereert, allemaal vanuit dezelfde bron van waarheid, valt de grens tussen 'het product ontwerpen' en 'het product op de markt brengen' in elkaar. Dezelfde smaak die de DESIGN.md schreef, is de smaak die elk klantcontactpunt vormgeeft.
Ik wil eerlijk zijn over het deel waar ik nog steeds ongelijk in heb. Ik weet nog niet of de agentschappen zich zullen aanpassen. Of het ontwerponderwijs de achterstand gaat inhalen, weet ik nog niet. Ik weet nog niet of de specificatie zelf standhoudt: de specificatie van Google bevindt zich in alpha, en er zijn al minstens drie concurrerende formaten in het ecosysteem (de variant van Anthropic, de versie van het Cursor-team, een paar van de lokaal-eerste BYOK-alternatieven). Een van deze zal waarschijnlijk consolideren. Ik zou vandaag wedden op Google's, omdat het open source-momentum en de tooling-voorsprong te ver vooruit zijn om door een vork te kunnen worden ingehaald. Maar ik heb het al eerder mis gehad met dit soort weddenschappen.
Waar ik geen ongelijk in heb, is de richting. Als je in 2026 je tijd besteedt aan het met de hand duwen van pixels, doe je het werk dat markdown-bestanden nu gratis doen.
Hoe je daadwerkelijk kunt beginnen, zonder een weekend te verbranden
Ik wil je achterlaten met de versie van 'Aan de slag'. Ik wou dat iemand mij een maand geleden had overhandigd. Sla de lange onboarding-tutorials over. Hier is wat u deze week kunt doen.
Dag één, avond. Kies het kleinste liveproject dat je hebt. Marketingsite. Bijproduct. Zelfs één enkele landingspagina. Lees drie echte DESIGN.md-bestanden van VoltAgent/awesome-design-md: Lineair, Stripe en één waarvan de esthetiek daadwerkelijk overeenkomt met die van u. Lees ze aandachtig. Het formaat zal over ongeveer twintig minuten duidelijk worden.
Dag twee. Schrijf uw eigen DESIGN.md helemaal opnieuw, met de hand, in een gewone teksteditor. Gebruik geen generator. Het punt van het dossier is dat het je dwingt beslissingen op smaakniveau expliciet te maken. Een generator verbergt die beslissingen. Streef naar 300 tot 600 lijnen. Besteed extra tijd aan de secties Beschrijving, Overzicht en Wat u wel en niet moet doen. Dit zijn de secties die het model gebruikt om de banden te verbreken.
Dag drie. Zet het bestand neer in de hoofdmap van uw project. Open Claude Code, Cursor, Codex of welke agent u ook gebruikt. Vertel het om DESIGN.md te lezen en een enkele pagina of component opnieuw op te bouwen met alleen de tokens en regels die daar zijn gedefinieerd. Kijk wat er terugkomt. Merk op waar het fout gaat: deze fouten wijzen op gaten in uw bestand, niet op het model.
Dag vier en verder. Herhaal het bestand. Elke keer dat de agent iets verkeerd doet op een manier die je niet had verwacht, vraag dan waarom. Bijna altijd is het antwoord dat uw bestand dit niet specificeerde. Voeg de regel toe. Het bestand wordt bij elke reparatie beter. Binnen twee weken na regelmatig gebruik stabiliseert het - op dat moment begint de output van de agent duidelijk van jou te voelen, en niet generiek.
Als u sneller oprit wilt, vindt u op de getdesign.md-site installatiehandleidingen voor Claude Code, Cursor, Kiro, Windsurf en Stitch. De officiële specificaties staan op github.com/google-labs-code/design.md. De CLI voor validatie, differentiëren en exporteren naar Tailwind of DTCG bevindt zich in dezelfde repository. Niets van dit alles zit achter een betaalmuur. De specificatie is Apache 2.0. De communitybestanden zijn open source. De vaardighedenlaag is grotendeels gratis.
Ik moet je een bekentenis achterlaten. De zaterdag die ik bovenaan dit artikel beschreef – de drie producten in drie uur – werkte ik al vanuit een baseline van drie maanden met dit format. De eerste keer dat ik probeerde een DESIGN.md te schrijven, kostte het me een hele middag en het resultaat was middelmatig. De tweede duurde drie uur en was bruikbaar. De vijfde duurde twintig minuten en was uitstekend.
Het formaat is eenvoudig. De smaak die nodig is om het goed te vullen is dat niet. Dat is het deel dat niet gedemocratiseerd wordt. Dat is het deel dat meer waardevol wordt, en niet minder, naarmate deze agenten beter worden.
Schrijf uw bestand. Neem de tijd. Het volgende decennium van ontwerpwerk zal plaatsvinden na de prijsverlaging die u deze week schrijft.
Veelgestelde vragen
Wat is het verschil tussen DESIGN.md en design.mmd?
Ze verwijzen naar hetzelfde formaat. DESIGN.md is de canonieke bestandsnaam Google die wordt geleverd in de specificatie op github.com/google-labs-code/design.md. De spelling design.mmd wordt in sommige communityvideo's en beschrijvingen weergegeven als een alternatieve transcriptie. De bestandsinhoud is identiek: de hoofdtekst van het bestand met optionele YAML-token vooraan, secties in specificatievolgorde. Gebruik DESIGN.md voor compatibiliteit met de officiële tooling.
Heb ik een ontwerper nodig om een DESIGN.md-bestand te schrijven?
Nee, maar je hebt smaak nodig. Het bestand dwingt elke merkbeslissing in expliciete taal: kleurgrondgedachte, typografische hiërarchie, spatiëringslogica, gebruiksregels voor componenten. Als u deze vragen niet zelf kunt beantwoorden, zal het bestand dat u schrijft algemene uitvoer produceren, ongeacht welke agent het leest. Een niet-ontwerper met een sterke smaak en referentieverzadiging zal een ontwerper verslaan die een sjabloon kopieert. Zie het gedeelte 'Smaak is de nieuwe gracht' hierboven voor het volledige argument.
Welke AI-agents ondersteunen momenteel DESIGN.md?
Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, Kiro, Windsurf en Anthropic's Claude Design lezen allemaal DESIGN.md native. De meesten lezen het bestand als een gewone prijsverlaging – er is geen plug-in vereist. De Google Stitch-tool was de oorspronkelijke formaateigenaar en heeft nog steeds de diepste integratie. Sommige agenten ondersteunen ook de optionele YAML-tokenexport die de design.md CLI genereert.
Hoe lang duurt het om een bruikbare DESIGN.md te schrijven?
Drie tot zes uur voor een serieuze eerste versie van een echt project. Twintig tot veertig minuten voor volgende projecten zodra u uw eigen sjabloon heeft. De secties Beschrijving, Overzicht en Wat u wel en niet moet doen nemen de meeste tijd in beslag en vormen de onderdelen met de meeste invloed. Investeer daar voordat u geobsedeerd raakt door het aantal tokens.
Zal DESIGN.md Figma vervangen?
Nee. DESIGN.md vervangt het overdrachtsdocument tussen ontwerp en code, en de trainingsgegevenslaag tussen uw merk en een agent. Figma blijft de plek voor visuele verkenning, motion prototyping en ontwerpbeoordeling. Het patroon waar de meeste teams vanaf mei 2026 naar toe convergeren: verkennen in Figma, codificeren in DESIGN.md, steigeren met een agent, verfijnen in code. Het bestand is de bron van waarheid die tussen elk hulpmiddel reist.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
