design.md vs. Design Tokens für KI-UI-Workflows

Ich bin Dora. Ich verbringe den größten Teil meiner Woche in Coding-Agents und KI-UI-Tools — Cursor, Claude Code, Stitch, das übliche Lineup — und baue und rebuilde Interfaces schneller, als ich Zeit habe, sie zu dokumentieren. Vor etwa einem Monat begann ich, dieselbe Datei in jedem zweiten Repo zu sehen, das ich anfasste: DESIGN.md. Selber Name, selbe YAML-oben-Prosa-unten-Struktur. Beim dritten Projekt erkannte ich, dass es kein Zufall war. Es war das Ding, das ersetzte, was die meisten von uns früher als tokens.json ausgeliefert haben.

Also habe ich eine meiner eigenen Komponentenbibliotheken zweimal neu gebaut — einmal mit einer klassischen DTCG-Style-Token-Datei, einmal mit einer DESIGN.md — und denselben Coding-Agent gegen beide laufen lassen. Das ist der Teil des Vergleichs, den ich nirgendwo aufgeschrieben finden konnte: nicht was jedes Format ist, sondern wofür jedes tatsächlich optimiert und welches gerade jetzt in deinen Stack gehört.

design.md vs. traditionelle Design-Tokens

Wofür jedes Format optimiert

Design-Tokens sind im klassischen Sinne eine Methodik. Der Begriff wurde bei Salesforce um 2014 geprägt, um ein sehr spezifisches Skalierungsproblem zu lösen: Wie hält man eine Farbentscheidung über Web, iOS, Android und vier Codebasen hinweg synchron, ohne vier Tickets einzureichen? Die Antwort war ein plattformagnostisches Name-Wert-Paar, gespeichert in JSON oder YAML, das zur Build-Zeit in das umgewandelt wird, was jede Plattform braucht. Diese Methodik ist jetzt durch die Design Tokens Community Group beim W3C kodifiziert, und Ende 2025 hat das DTCG-Format eine stabile v1-Spezifikation.

Tokens optimieren für deterministische Verteilung. Ein Hex-Code geht rein, derselbe Hex-Code kommt auf jeder Plattform, bei jedem Build, für immer raus. Es gibt keine Mehrdeutigkeit. Es gibt auch keine Narrative — eine Token-Datei sagt dir primary: #1A1C1E, aber sie sagt dir nicht, warum diese Farbe existiert oder wann man sie nicht verwenden sollte.

DESIGN.md, im April 2026 von Google Labs als Open Source veröffentlicht, optimiert für etwas anderes: einem Coding-Agent genug Kontext zu geben, um Entscheidungen zu treffen, die die Token-Datei nicht abdeckt. Es ist eine einzelne Markdown-Datei mit YAML-Front-Matter für Tokens und Prosa darunter für die Begründung. Dieselbe Datei, zwei Zielgruppen — der deterministische Teil für Parser, der narrative Teil für das LLM, das das Repo liest.

Das ist die eigentliche Trennung. Nicht „alt vs. neu.” Nicht „JSON vs. Markdown.” Es sind Werte vs. Werte plus Begründung in derselben Datei.

Warum KI-Agents neue Anforderungen schaffen

Wenn ein Mensch ein Design implementiert, wird die Lücke zwischen „der Token sagt #1A1C1E” und „dieser leere Zustand braucht eine Tonalität” vom Menschen gefüllt. Er hat die Figma-Datei gesehen. Er saß im Brand-Workshop. Er weiß, dass der sekundäre Button ruhig wirken soll, nicht assertiv.

Ein Coding-Agent hat nichts davon. Er hat, was du im Repo abgelegt hast, und was er aus Dateinamen schlussfolgern kann. Wenn du ihn also bittest, einen Screen zu generieren, den die Token-Datei nicht vollständig spezifiziert — einen Edge Case, eine neue Komponente, eine Layout-Entscheidung — rät er entweder oder fällt auf das zurück, was er im Training am häufigsten gesehen hat. Das ist die Quelle der „KI-Beige”-Ästhetik, über die sich alle beschweren: nicht schlechte Modelle, nur fehlender Kontext.

Das ist es, was DESIGN.md löst. Die offizielle Spezifikation auf GitHub ist explizit darüber — Tokens geben Agents exakte Werte, Prosa sagt ihnen, warum diese Werte existieren und wie man sie anwendet. Das Format erwartet beide Hälften.

Wo design.md Mehrwert schafft

Persistenter narrativer Kontext

Was mir in den ersten 48 Stunden des Testens auffiel: Derselbe Agent, mit demselben Brief, erzeugt spürbar unterschiedlichen Output, wenn Prosakontext vorhanden ist. Nicht „etwas bessere Farben.” Unterschiedliche Layout-Entscheidungen, unterschiedliches Copy-Register, unterschiedliche Komponentendichte. Die Token-Werte waren in beiden Durchläufen identisch — was sich änderte, war, ob der Agent einen Absatz hatte, der sagte: „Die Markenstimme ist zurückhaltend und redaktionell; bevorzuge Weißraum gegenüber Dekoration.”

Das ist der Teil, den die traditionelle Token-Pipeline nicht transportiert. Eine DTCG-JSON-Datei kann --color-primary präzise beschreiben, aber sie kann einem Agent nicht sagen, dass die Primärfarbe sparsam verwendet werden soll. DESIGN.md trägt dieses Urteil bei jedem Generierungsdurchlauf persistent mit, ohne dass jemand es erneut in einen Prompt eintippen muss.

Es funktioniert.

Bessere Multi-Screen-Konsistenz für Generierungs-Workflows

In meinem zweiten Test generierte ich acht Screens für dieselbe App über zwei Tage. Mit reinem Token-Kontext begannen die Screens 5–8 zu driften — gleiche Palette, aber die Layout-Sprache lockerte sich. Mit DESIGN.md war die Drift deutlich kleiner. Nicht null. Kleiner.

Meine Einschätzung warum: Der Prosa-Abschnitt wirkt wie ein Re-Anker, jedes Mal wenn der Agent die Datei liest. Tokens allein geben einem Agent genug, um bei einzelnen Werten korrekt zu sein. Die Narrative gibt ihm genug, um konsistent über Entscheidungen hinweg zu sein, die die Tokens nicht antizipiert haben. Für einmalige Generierung ist diese Lücke egal. Für Multi-Screen-Output und laufende Iteration verstärkt sie sich.

Hier harmoniert DESIGN.md auch gut mit dem breiteren Agent-Instruktions-Stack — die meisten Setups referenzieren es jetzt aus einem AGENTS.md neben SKILL.md-Dateien, sodass das Design-System in derselben Kontext-Ebene sitzt wie der Rest der persistenten Instruktionen des Agents.

Wo traditionelle Tokens nach wie vor gewinnen

Zwei Szenarien, beide real.

Plattformübergreifende Verteilung jenseits des Webs. Wenn du dasselbe Design-System in iOS, Android, eine React Native App und eine Marketing-Website auslieferst, ist die DTCG-Pipeline über Style Dictionary oder Terrazzo immer noch der Weg des geringsten Widerstands. Das YAML von DESIGN.md kann in DTCG-JSON exportieren über die offizielle @google/design.md CLI, aber die Frage nach der Wahrheitsquelle bleibt relevant — wenn dein Token-Graph groß, multi-themed und von Nicht-KI-Tooling konsumiert wird, ist DTCG als kanonisches Format das sauberere Setup.

Ausgereifte Design-Systeme mit etablierter Governance. Tokens sind nicht nur ein Dateiformat. Sie sind eine Methodik mit etwa einem Jahrzehnt akkumulierter Praxis — primitive Schichten, semantische Schichten, Aliasing, Theming, die gesamte Taxonomie, die Nathan Curtis in Tokens in Design Systems dargelegt hat. Wenn dein Team bereits auf diese Weise arbeitet, ersetzt DESIGN.md es nicht. Es sitzt darauf oder daneben als Kontext-Ebene für Agents. Tokens bleiben die kanonische Quelle; das Markdown wird zur KI-gerichteten Übersetzung.

Der Fehler wäre, DESIGN.md als Ersatz für die Token-Pipeline zu lesen. Das ist es nicht. Es ist eine andere Schicht mit einem anderen Konsumenten.

Ein Entscheidungsrahmen für Teams, die KI-UI-Pipelines aufbauen

Ich komme immer wieder auf vier Fragen zurück, wenn ich entscheide, was in ein Repo gehört:

Wer liest diese Datei? Wenn der primäre Konsument eine Build-Pipeline ist, die CSS, Swift und Kotlin ausgibt, willst du Tokens in einem kanonischen Format. Wenn der primäre Konsument ein Coding-Agent ist, der UI auf Abruf generiert, willst du DESIGN.md. Wenn beides, behältst du beides — und lässt das YAML der Markdown-Datei eine Teilmenge der Tokens spiegeln.
Wie oft wird deine UI-Oberfläche neu generiert? Teams mit niedriger Frequenz (stabiles Produkt, gelegentlich neue Screens) bekommen den größten Wert aus Tokens. Teams mit hoher Frequenz (schnelles Prototyping, agent-getriebene Iteration, neue Screens jede Woche) spüren die fehlende-Kontext-Lücke akut. Je höher die Generierungsfrequenz, desto mehr verdient die Prosa-Schicht ihren Platz.
Wie viele Plattformen? Nur Web oder Web-primär mit agent-gesteuerter Generierung — DESIGN.md ist der einfachere Stack. Drei oder mehr Plattformen mit ernsthafter nativer Präsenz — Tokens-first, mit DESIGN.md als nachgelagertem Artefakt.
Ist die Begründung bereits irgendwo dokumentiert? Wenn deine Brand-Guidelines, dein Voice-Dokument und deine Komponentenphilosophie auf einer Notion-Seite leben, die kein Agent jemals lesen wird, ist DESIGN.md der einzelne Hebel mit der höchsten Wirkung, den du dieses Quartal ziehen kannst. Du erstellst keine neue Dokumentation — du verschiebst bestehende Dokumentation in eine Datei, die der Agent tatsächlich öffnet.

Das ist mein Rahmen. Deiner mag abweichen. Was ich betonen würde: Wähle kein Format, weil es neu ist. Wähle es aufgrund dessen, wer die Datei liest.

FAQ

Ist design.md ein Ersatz für Design-Tokens?

Nein. DESIGN.md ist ein Wrapper, der Design-Tokens (in YAML-Front-Matter) plus die Begründung dahinter (in Markdown-Prosa) enthält. Die Tokens darin sind immer noch Design-Tokens im konventionellen Sinne. Wenn du bereits eine DTCG-Format-Token-Datei hast, ersetzt DESIGN.md sie nicht — es sitzt als paralleles Artefakt für KI-Agents daneben, oder du kannst das Markdown bei Bedarf DTCG-JSON exportieren lassen.

Warum brauchen KI-Agents mehr als numerische Tokens?

Weil die meisten UI-Generierungsanfragen nicht vollständig durch den Token-Graph spezifiziert sind. „Generiere eine Preisseite” erfordert Hunderte von Micro-Entscheidungen — Hierarchie, Dichte, Ton, was zu betonen ist — die keine Token-Datei abdeckt. Ohne narrativen Kontext füllt der Agent diese Lücken mit dem, was er in den Trainingsdaten am häufigsten gesehen hat, was den generischen Look produziert, den die meisten KI-generierten UIs teilen. Prosa in DESIGN.md ist das, was diese Lücke schließt.

Welche Workflows profitieren am meisten von design.md?

Drei Muster, die ich am meisten zahlen gesehen habe:

Solo-Builder und kleine Teams, die Cursor, Claude Code oder Stitch nutzen, um UI schneller zu liefern, als sie es per Hand schreiben können.
Design-System-Teams, die mehrere interne Produkte pflegen, wo Konsistenz über KI-generierte Screens hinweg zu einem echten Problem wird.
Agenturen und Vertragsteams, die eine einzelne Drop-in-Datei wollen, die die Design-Sprache eines Kunden für jeden Coding-Agent kodiert.

Wenn dein Workflow hauptsächlich handkodiert ist mit gelegentlicher KI-Unterstützung, sinkt der Grenznutzen.

Wann ist klassische Design-Token-Infrastruktur noch ausreichend?

Wenn du keine UI mit Agents generierst, oder wenn deine Plattformreichweite weit über das Web hinausgeht. Native Mobile schwer, Multi-Theme-White-Label-Produkte, ausgereifte Design-Ops-Praktiken — diese bekommen immer noch mehr aus dem DTCG-Ökosystem als aus einer Markdown-Datei. Die beiden schließen sich nicht gegenseitig aus, aber wenn du dich für eine entscheiden musst, hängt die Antwort davon ab, wo deine Generierungsreibung tatsächlich liegt.

Fazit

Die ehrliche Version: DESIGN.md ist kein Paradigmenwechsel. Es ist eine fokussierte Lösung für eine spezifische Lücke — Coding-Agents fehlt die Begründung, die Token-Dateien nicht transportieren. Für die Workflows, in denen diese Lücke real ist, ist der Gewinn sofort und offensichtlich. Für die Workflows, in denen es das nicht ist, erledigen traditionelle Tokens immer noch den Job.

Ich nutze DESIGN.md seit zwei Monaten in jedem KI-Generierungsprojekt, das ich betreibe. Es ist im Workflow geblieben, was der einzige Test ist, dem ich vertraue. Die Token-Dateien sind auch nicht verschwunden — sie tun immer noch, was sie immer getan haben, nur jetzt mit einer Geschwisterdatei für das Publikum, das mehr als Zahlen braucht.

Probiere es selbst an einem Projekt aus. Zwei Tage werden dir mehr sagen als dieser Artikel.

Vorherige Beiträge: