Google standardisiert Design für Maschinen.

Google Labs hat DESIGN.md als Open Source veröffentlicht — ein Format, das die visuelle Identität eines Produkts so beschreibt, dass ein Coding-Agent sie ohne zu raten respektieren kann. Die Ankündigung erschien am 21. April 2026 auf dem offiziellen Google-Blog, zeitgleich mit der Veröffentlichung von Version 0.1.0 des Repositorys google-labs-code/design.md auf GitHub. Lesenswert wegen dessen, was es impliziert, nicht wegen dessen, was es verspricht.

Was DESIGN.md wirklich ist

Die Struktur ist einfach. Eine Textdatei mit zwei Schichten: oben ein YAML-Block, der die System-Token deklariert — Farben in Hex, Grössen in px oder rem, Typografie, Border-Radien, Komponenten-Definitionen — mit einem Querverweissystem zwischen Token; darunter Markdown-Prosa, die die Entscheidungen und ihr Warum erklärt. Konzipiert, von einem Agenten gelesen zu werden, bevor von einem Menschen. Das Paket enthält eine CLI mit vier essentiellen Befehlen: lint zur Validierung der Datei und WCAG-Kontrastprüfung, diff zum Versionsvergleich, export zur Ausgabe von Tailwind, CSS und W3C-DTCG-Token, spec zur Rückgabe der Formatspezifikation.

Der operative Sinn besteht darin, Informationen, die heute in den Köpfen der Designer leben, in Brand-Book-Folien und in mit Berechtigungen geschützten Figma-Ordnern, in eine einzige Textdatei zu verlagern, die neben dem Code lebt. Ein Agent, der eine Oberfläche erzeugt, muss nicht mehr die Palette aus einem Screenshot ableiten oder sich an die richtige Schrift erinnern: er liest sie, und wenn er sich irrt, sagt es ihm der Linter.

Ein minimales Beispiel, wie eine DESIGN.md in der Praxis aussieht, für die Lesbarkeit vereinfacht:

---
brand: Acme
version: 1.2.0
tokens:
  color:
    primary: "#0066FF"
    primary-hover: "{color.primary | darken(0.1)}"
    page-bg: "#FFFFFF"
    page-text: "#0A0A0A"
  spacing:
    md: 16px
    lg: 24px
  typography:
    h1:
      size: clamp(2rem, 5vw, 4rem)
      weight: 800
      family: "Inter"
  components:
    btn-primary:
      bg: "{color.primary}"
      color: "#FFFFFF"
      padding: "14px {spacing.lg}"
      hover-bg: "{color.primary-hover}"
---

## Warum primary blau ist

Blau ist seit 1968 die Farbe der europäischen Nahverkehrsnetze. Acme
operiert im Logistik-Transport-Sektor: unsere Zielgruppe liest Blau als
"funktionale Zuverlässigkeit", nicht als "Technologie". Die Wahl ist
konsistent mit der Brand-Recognition-Spur.

## Wann btn-primary NICHT verwenden

Nie mehr als einen pro Fold. Nie in Tabellenspalten (reduziert die
Lesbarkeit). Nie über einem Bild ohne dunkles Overlay (Kontrast unter
WCAG AA).

Fünfzig Zeilen, die die Arbeit eines sechzigseitigen Brand-Book-PDFs leisten — mit einem zusätzlichen Vorteil: ein AI-Agent kann es direkt konsumieren und korrekten Code generieren, ohne jede visuelle Interpretation. Der Prosa-Teil ("Warum primary blau ist"), oft als Beiwerk verworfen, ist tatsächlich derjenige, der dem Modell erlaubt, intelligente Entscheidungen für Fälle zu treffen, die von den Token nicht abgedeckt sind: braucht es eine nie deklarierte Alarmfarbe, liest das Modell die Narrative und versteht, dass es im Register der "funktionalen Zuverlässigkeit" bleiben muss, nicht zu einem emotionalen, erschreckenden Rot springen darf.

Was sich gegenüber W3C Design Tokens ändert

Für diejenigen, die das Dossier der Design-Standards verfolgen, lautet die offensichtliche Frage: was fügt DESIGN.md über das hinaus, was es mit W3C Design Tokens (DTCG) schon gab? Drei Punkte. Erstens: W3C Design Tokens sind nur die Token — ein strukturiertes JSON von Farben, Abständen, Typografie. DESIGN.md schliesst die Token in dieselbe Datei ein, fügt aber den narrativen Kontext hinzu, den kein JSON natürlich strukturiert: warum primary blau ist, wann btn-primary nicht zu verwenden, welche die akzeptablen Ausnahmen sind. Ein kompetenter Coding-Agent weiss, dass die Token ihm "was" sagen, die Prosa ihm "wann" und "warum" sagt.

Zweitens: DESIGN.md enthält die CLI zur Validierung der Datei, zum Export in verschiedene Ziele und zum Versionsdiff. W3C Design Tokens überlassen die Validierung dem, der den Standard übernimmt. DESIGN.md ist opinionated: es will, dass du den Kontrast validierst, verwaiste Token zählst, zirkuläre Referenzen prüfst. Opinionated bedeutet starrer, aber auch out-of-the-box konsumierbarer.

Drittens, und vielleicht am wichtigsten: DESIGN.md wird von Google geschrieben. W3C Design Tokens sind ein Konsortium. Übersetzt: die Adoptionskurve wird ganz anders ausfallen. Ein von einem einzelnen Big-Tech mit eigener CLI vorangetriebenes Format, das Agenten nativ erkennen, tritt in der Praxis innerhalb von sechs Monaten ein. Ein Konsortium-Standard tritt in fünf Jahren ein oder tritt nicht ein. Es ist kein Qualitätsurteil — es ist eine Beobachtung zur Markt-Adoptionsgeschwindigkeit.

Drei Perspektiven, die zählen

Erste: wir beobachten die Geburt einer neuen Klasse von Artefakten — Dateien, die dafür konzipiert sind, von Maschinen gelesen zu werden, bevor von Menschen. README, AGENTS.md, jetzt DESIGN.md. Jede Domäne des Unternehmens — Verkauf, Design, Recht, interne Prozesse — wird in einer deklarativen Datei mit strukturiertem Front Matter komprimiert. Wer ein Unternehmen führt, sollte sich an die Idee gewöhnen, dass das eigene Brand-Book, heute ein sechzigseitiges PDF, bald ein zweitausendzeiliges Textdokument sein wird. Unbequemer zu layouten, unvergleichlich nützlicher.

Zweite: dass Google die Spezifikation als offenen Standard veröffentlicht, mit permissiver Lizenz und einer von Stitch unabhängigen CLI, ist ein präziser Schachzug. Sie verkaufen kein Produkt, sie versuchen, ein Protokoll festzulegen. Wer DESIGN.md als Erster übernimmt, ist faktisch auf alle künftigen Agenten ausgerichtet, die es erkennen können — und Google wird viele davon trainieren. Es ist dieselbe Logik, mit der die robots.txt von 1994 fünfundzwanzig Jahre Indexierung bestimmt haben: wer die Datei hingestellt hat, wurde respektiert.

Dritte: die Spezifikation ist Version 0.1.0, deklariert Alpha, mit ausdrücklicher Warnung, dass sich das Format ändern wird. Übersetzt: wer auf das stabile 1.0 wartet, kommt zu spät. Wer jetzt übernimmt, zahlt Wartungskosten, kauft aber Optionalität. Es ist eine kalt zu treffende Rechnung, kein Grund, die Ankündigung zu ignorieren.

Grenzen der v0.1.0 (und was darüber hinaus nötig ist)

DESIGN.md ist für das visuelle Design geboren: Farben, Spacing, Typografie, grundlegende UI-Komponenten. Gut abgedeckt. Aber ein vollständiges Brand-System enthält mindestens vier weitere Verträge, die die aktuelle Spec nicht berührt:

• Komplexe Komponenten · Anatomie + Varianten + Zustände. Eine "btn-primary"-Schaltfläche ist in YAML leicht zu deklarieren. Eine Blog-Post-Karte mit Header + Media + Body + Footer, mit Varianten für featured / regular / sponsored, mit hover / focus / loading / error states, erfordert eine Struktur, die flaches YAML nicht natürlich handhabt. Eine zweite Datei (COMPONENTS.md?) oder eine Spec-Erweiterung wird nötig sein.
• Content-Typen. Was ist ein "Blog Post"? Eine "Case Study"? Eine "Persona"? Ein Agent, der Content erzeugt, muss das Schema der Content-Typen kennen, nicht nur, wie sie zu rendern sind. DESIGN.md kümmert sich nicht darum.
• Page Templates. Eine Homepage ist Hero + 5 Sektionen + Footer. Ein Blog-Index ist Grid + Pagination. Eine FAQ ist Q&A-Liste. Die Sequenz der Komponenten auf einer Seite ist ein Vertrag für sich.
• Voice und Copy. Welche Wörter zu verwenden, welche zu vermeiden, wie der Ton ist. DESIGN.md beschreibt die Farbe einer Schaltfläche, aber nicht, was darauf zu schreiben ist.

Wer DESIGN.md heute übernimmt, tätigt eine Teilinvestition. Es ist eine gute Investition — das Stück, das es abdeckt, ist das, was zuerst angefasst wird — aber das vollständige System erfordert eine Familie von machine-readable-Dateien, nicht eine einzige Datei. Zu erwarten, dass das 1.0 alles abdeckt, wäre Kurzsichtigkeit. Zu erwarten, dass die 0.1.0 genug ist, um das Brand-Book zu ersetzen, wäre Überschätzung.

Die Position von Jigen

Unser Handwerk ist es, eine AI-Automatisierung in einundzwanzig Tagen in einem Unternehmen in Produktion zu bringen. Wenn ein kleines Team in einen Kunden geht und einen Agenten mit einer Oberfläche, einem Komponentenset, einem visuellen Tonfall sprechen lassen muss, ist das eigentliche Problem immer dasselbe: die Quelle der Wahrheit des Brands ist verstreut. Drei Figma-Dateien, zwei Notion-Seiten, ein PDF-Handbuch von 2022, ein Designer, der sich erinnert. Jede Iteration kostet Abgleich. DESIGN.md, auch in seiner unreifen Form, gibt endlich einen Verankerungspunkt: eine einzige Datei, die der Agent jedes Mal liest, der Linter überprüft, und die zusammen mit dem Code versioniert bleibt.

Der Punkt ist nicht, dass DESIGN.md perfekt sei. Es ist, dass es eine Bewegung kristallisiert, die bereits im Gang ist: die Unternehmen, die die nächsten fünf Jahre gewinnen werden, werden ihr Design-System, ihr Verkaufssystem, ihren Onboarding-Prozess in strukturierten Formaten geschrieben haben, die ein Agent ohne Vermittler konsumieren kann. Alles, was in PowerPoint bleibt, wird inert werden.

Das haben wir auf unserem internen Design System bereits gesehen. Das Jigen DS besteht aus narrativen HTML-Dokumentationsseiten (für Menschen, die lesen) plus einer Familie machine-readable-Dateien (tokens.json, components.json, glossary.json, content-types.json, page-templates.json, plus ein llm-porter-playbook, das die Lesereihenfolge deklariert). Die Logik ist dieselbe wie bei DESIGN.md, und es zeigt etwas, das es wert ist, laut gesagt zu werden: eine Maschine, die Code oder Copy produziert, ist nicht weniger anspruchsvoll als ein Designer. Sie ist sogar rigoroser, weil sie nicht mit "gesundem Menschenverstand" ergänzt — sie ergänzt mit dem, was sie findet. Ist die Quelle mehrdeutig, ist der Output mehrdeutig.

Wie man eine DESIGN.md das erste Mal schreibt

Für diejenigen, die von null starten, ist der Weg vorhersehbar. Drei oder vier halbe Tage über eine Woche verteilt, kein zu kalkulierendes Projekt:

Sitzung 1 · Farb-Token + WCAG. Die gesamte Brand-Palette aus Figma heruntergeladen oder aus einem Screenshot rekonstruiert, in Hex konvertiert, als Token deklariert. Für jede Farbe Kontrast gegen Referenz-Hintergründe berechnen (hell, dunkel, eventuelle Pastel-Variante). Paare unter AA korrigieren oder als "decorative only" annotieren. Es ist der Moment, in dem Brand-Book-Inkonsistenzen auftauchen, die niemand je benannt hatte — passiert fast immer.

Sitzung 2 · Spacing + Typografie. Die Spacing-Skala (4/8/12/16/24/32/48px) als Token deklariert. Die typografische Skala mit Font-Family, Size, Weight, Line-Height, Letter-Spacing für jede Rolle: H1, H2, H3, Body, Caption, Eyebrow. Auch die Token veröffentlichen, die in seltenen Ausnahmen verwendet werden — besser geschrieben und ungenutzt zu haben, als sie jedes Mal erfinden zu müssen.

Sitzung 3 · Fünf Core-Komponenten. Schaltfläche (Varianten primary/secondary/ghost), Karte, Form-Input, Badge, Nav. Für jede: Anatomie, Zustände, Komponierregeln, bekannte Anti-Pattern. Dies ist die Sitzung, die den Designer in Person erfordert, denn einige Details (wie ein disabled-Button gehandhabt wird, wo ein Focus-Ring lebt) können aus keinem Screenshot abgeleitet werden.

Sitzung 4 · Begleitende Prosa. Für jede nicht offensichtliche Entscheidung zwei bis drei Sätze, die das Warum erklären. Dies ist die Sektion, die die meisten Unternehmen überspringen — "versteht sich aus dem Token, oder?" — und die tatsächlich diejenige ist, die einem Agenten erlaubt, intelligente Entscheidungen zu treffen, wenn er einen Fall ausserhalb des Katalogs trifft.

Am Wochenende gibt es eine Datei, die neben dem Code lebt, versioniert wird und von jedem Coding-Agenten konsumiert werden kann. Kosten: ~20 Stunden verteilter Arbeit. Nutzen: jede zukünftige Brand-Alignment-Iteration kostet Minuten statt Tage.

Schneller Test · ist dein Brand schon maschinenlesbar?

Ein diagnostisches Raster für die Geschäftsführung eines Unternehmens, das wissen will, wo sie steht. Fünf Fragen:

1. Existiert eine Textdatei (egal welches Format), die die vollständige Brand-Palette deklariert? Ja → weiter. Nein → es gibt die erste Sitzung zu machen.
2. Existiert eine Datei, die die vollständige typografische Skala deklariert, mit Font-Family + Size + Weight für jede Rolle? Ja → weiter. Nein → zweite Sitzung.
3. Existiert für jede Haupt-UI-Komponente eine strukturierte Beschreibung von Varianten, Zuständen, Komponierregeln? Ja → weiter. Nein → dritte Sitzung.
4. Existiert ein Prosa-Dokument, das die nicht offensichtlichen Brand-Entscheidungen erklärt (warum Blau und nicht Rot, warum Inter und nicht Garamond)? Ja → weiter. Nein → vierte Sitzung.
5. Kann ein Coding-Agent (Claude, GPT, Gemini, ein interner Copilot) diese Dateien konsumieren, ohne vorher von einem Menschen "erklärt" werden zu müssen? Ja → du bist maschinenlesbar, Glückwunsch. Nein → die letzte Sitzung besteht darin, sie konsumierbar zu machen, typischerweise durch Konvertierung von PDF oder Slides zu YAML/JSON/Markdown.

Fünf Ja von fünf: der Brand ist bereit für 2026 und darüber hinaus. Drei oder vier Ja: eine Arbeitswoche entfernt vom Bereitsein. Zwei oder weniger: es gibt strukturelle Schulden, die jede Woche in zerstreuenden Iterationen zahlen — und die, in sechs Monaten, noch teurer zu begleichen sein werden, weil in der Zwischenzeit Agenten mehr Dinge tun werden, jedes davon mit manuellem Abgleich.

Konkrete Implikation

Für einen Gründer oder CEO lautet die diese Woche zu stellende Frage eine: wenn morgen früh ein AI-Agent die nächste Landing Page, das nächste E-Mail-Template, das nächste Dashboard erzeugen müsste, aus welcher Datei würde er Farben, Typografie und Komponenten-Regeln lesen? Lautet die Antwort "keiner, wir fragen den Designer", ist das Unternehmen ausserhalb des Standards. Es ist nicht nötig, DESIGN.md heute zu übernehmen; es ist nötig zu akzeptieren, dass das Brand-Book von morgen eine Textdatei sein wird, und damit anzufangen, sie zu schreiben. Kosten: ein Nachmittag. Kosten des Nicht-Tuns: jede zukünftige Iteration in Nacharbeitsstunden bezahlt.

Google hat eine Alpha-Spezifikation und eine CLI von ein paar hundert Zeilen veröffentlicht. Das Ereignis wirkt nebensächlich. Ist es nicht. Es ist der erste öffentliche Standard eines Protokolls, das in sechs Monaten die stille Voraussetzung jedes Design-Agenten sein wird.

Quelle: Google Labs, "Stitch app's DESIGN.md format is now open-source for designers", blog.google, 21. April 2026 — Ankündigung lesen ↗ und das Repository auf GitHub ↗. Jigen-Lesart: DESIGN.md ist kein Werkzeug für Designer — es ist ein Werkzeug für Coding-Agenten, die eine Identität respektieren müssen, ohne zu raten. Es ist ein Schritt in dieselbe Richtung wie unser internes Design System, das heute schon eine Familie machine-readable-Dateien exponiert (tokens / components / content-types / page-templates / glossary / playbook). Früh zu übernehmen heisst sich auf das Protokoll auszurichten, das in sechs Monaten stille Voraussetzung sein wird. Auf das stabile 1.0 zu warten heisst, anzukommen, nachdem andere sich bereits eingereiht haben.