.md – en ny standard för designsystem?

Vad formatet faktiskt är

En design.md är i grunden två lager i samma fil. Ett YAML-block i början med tokens – färger, typografi, radius, spacing – och en lista av komponenter som kombinationer av dessa tokens. Därefter löpande text som förklarar själva designtanken.

Tolkar man det mot en klassisk designsystem-modell är det inte så mycket nytt som det först verkar. Foundation finns där fortfarande – färger, tokens, typografi, radius, spacing. Skillnaden är att den är maskinläsbar i stället för inbäddad i Figma-variabler eller en Supernova-exportfil. Och texten under är det som tidigare skulle kallats rationaler eller brand guidelines.

Det som verkligen är annorlunda är hur komponenterna hanteras.

Var tog komponenterna vägen?

I ett klassiskt system är komponenterna något konkret. En dropdown finns som en Figma-komponent och som en motsvarande Vue- eller React-komponent i kodbiblioteket. I .md-formatet är komponenter i stället specifikationer – "en primär knapp har denna bakgrundsfärg, denna radie, denna padding". Det finns ingen faktisk implementation i filen.

Det betyder inte att komponenterna försvinner. Det betyder att implementationen kommer från tre andra ställen. Agentens egen kunskap om hur en tillgänglig dropdown byggs, tränad på miljontals exempel. Open source-bibliotek som shadcn/ui som fungerar som kopierbara mallar snarare än installerade paket. Och – viktigast – projektets egna committade komponenter när de väl är genererade en gång. Första gången en agent behöver en dropdown skapar den en, och den läggs i repot. Nästa gång ska den importera den i stället för att skapa en ny.

Det här är ett annat sätt att tänka på komponentbibliotek. I stället för ett centralt bibliotek som varje produkt drar in som ett beroende blir det en uppsättning källkod som varje projekt äger och lever med. Formatet säger hur något ska se ut, men implementationen växer fram i projektet.

Konsistensfrågan – det som är lätt att missa

Det är här det blir intressant, och där den klassiska designsystem-tanken kommer tillbaka starkare än man först anar. En .md-fil ensam räcker inte för att hålla ett system konsistent. Den ger färgkonsistens och token-konsistens, men inte implementationskonsistens. Utan rätt struktur runt den riskerar man att få samma tertiära färg på knappar i hela produkten, men tio olika dropdown-implementationer med olika HTML, olika ARIA-attribut och olika animationer.

Tre saker krävs för att det ska hålla ihop över tid.

Tokens som source of truth. Ändras en färg i .md-filen uppdateras allt som refererar till den. Det är samma princip som med Figma-variabler eller CSS custom properties, men formatet är direktläsbart för agenten utan plugin eller exportsteg.

Filen i repot, inte i agentens minne. AI-agenter har kort minne mellan sessioner. Det är själva poängen med att specen ligger som en fil i projektet – varje session börjar med att läsa den. Ingenting viktigt lagras i agenten.

Committade komponenter och en instruktionsfil som säger "importera, skapa inte nya". Det här är det lager som gör att dropdown nummer två faktiskt blir dropdown nummer ett. En design.md säger hur en knapp ska se ut. En AGENTS.md eller CLAUDE.md säger var agenten ska leta efter befintliga komponenter innan den skriver nya. Utan det andra lagret drar designsystemet ifrån, även om färgerna stämmer.

Parallellen till klassiska designsystem är faktiskt rätt tydlig när man tänker på det. Foundation blir YAML-tokens. Komponentspecifikation blir YAML-komponenter. Komponentbibliotek blir committad kod i projektet. Dokumentation blir prosatexten i samma fil. Inget försvinner – det packas ihop i ett format som en agent kan agera på.

Hur vi tänker på det på Intunio

Vi följer utvecklingen nära och ser det snarare som en naturlig förlängning av token-arbetet än som ett brott mot hur vi arbetat. Token-baserade designsystem har varit kärnan i moderna leveranser i flera år. Att gå från Figma-variabler och Style Dictionary till en maskinläsbar fil som en agent direkt kan konsumera är ett steg i samma riktning – inte en ny riktning.

Det som ändras är hur leveransen ser ut i andra änden. När koden inte längre nödvändigtvis skrivs av en människa utan av en agent som läser specen, blir tydligheten i själva specen ännu viktigare. Det är mindre utrymme för implicit kunskap, för "den som bygger det förstår hur vi brukar göra". Varje designbeslut måste skrivas ned, för det är vad agenten kommer att läsa.

Samtidigt är det värt att säga rakt ut att formatet inte är färdigt. Googles design.md är tidig, konkurrerande format kommer att dyka upp, och det är ännu oklart vilket som vinner i längden. Principen – en maskinläsbar spec, committad kod och en instruktionsfil för agenten – håller oavsett vilket format som blir standard.

Vad man bör ta med sig

Ett designsystem har aldrig handlat om filerna det lagras i. Det har handlat om att säkerställa att produkten ser ut och beter sig konsistent oavsett vem som bygger nästa del. När "den som bygger nästa del" blir en AI-agent förändras inte det målet – men verktygen och formaten gör det.

.md-formatet är ett tidigt försök att möta det. Det är inte ett helt nytt sätt att tänka på designsystem, det är ett nytt sätt att paketera dem så att de blir läsbara för något som inte är en människa. Foundation finns kvar, komponenter finns kvar, dokumentation finns kvar. Det som är nytt är att allt blir text som en agent kan agera på direkt, utan plugin, export eller handoff.

Och kanske är det den verkliga insikten: ett designsystem som inte går att läsa av en AI-agent kommer snart att kännas lika begränsat som ett designsystem som inte går att läsa av en utvecklare.