Design Systems werden jetzt auch für Maschinen geschrieben

Wer neu in ein Team kommt, bekommt am ersten Tag meist einen Link zum Styleguide. Den Rest lernt man nebenbei: dass dieser Button nur einmal pro Seite vorkommt, dass Rot für Fehler reserviert ist, dass man bei einer bestimmten Komponente lieber erst die Kollegin fragt. Vieles davon steht nirgends. Es funktioniert trotzdem, weil Menschen nachfragen.

Ein KI-Agent fragt nicht nach. Er liest, was er findet – und füllt den Rest mit dem, was statistisch am wahrscheinlichsten passt. Genau deshalb verändert sich gerade, für wen ein Design System geschrieben wird.

Was ein Design System eigentlich ist

Ein Design System ist das gemeinsame Regelwerk, nach dem eine Organisation ihre digitalen Oberflächen baut. Es besteht grob aus drei Schichten:

• Design Tokens – benannte Grundwerte wie Farben, Schriftgrößen und Abstände. Statt eines Farbwerts wie „#CC0000“ steht im Code etwa farbe-fehler. Ändert sich der Wert, ändert er sich überall.
• Komponenten – fertige Bausteine wie Buttons, Formularfelder oder Dialoge, in Design-Werkzeug und Code.
• Regeln und Dokumentation – wann welcher Baustein passt, welche Zustände er hat, was man vermeiden soll und warum.

Ich verantworte am Flughafen München das digitale Design System. Die dritte Schicht ist die, bei der Menschen Lücken am leichtesten überbrücken: Fehlt eine Regel, fragt man nach. Ein Agent kann das nicht.

Der Anlass: Design-Werkzeuge bauen für Agenten um

Am 15. Oktober 2026 hat Figma auf seiner Konferenz Config India eine Reihe neuer Funktionen vorgestellt (Figma-Blog, „Build by design“ (öffnet neuen Tab)). Für dieses Thema sind drei davon interessant:

• Guidelines: Teams können ihren veröffentlichten Bibliotheken Regeln beifügen, damit der Agent etablierten Mustern folgt. Status: offene Beta.
• Code Sources: Der Code der Komponenten lässt sich aus einem GitHub-Repository oder npm-Paket einbinden, damit der Agent bessere Komponenten baut. Status: geschlossene Beta. Beides soll in den kostenpflichtigen Tarifen verfügbar sein.
• System Map und System Checks: Eine Übersicht über Abhängigkeiten und ein Prüfwerkzeug, das Lücken findet – Figma nennt als Beispiele fehlende Beschreibungen und fehlende Interaktionszustände. Status: Vorschau.

Dazu kommen „Code Layers“, laufender Code direkt auf der Arbeitsfläche, jetzt in offener Beta, und ein erweiterter MCP-Server, über den externe KI-Werkzeuge auf diese Inhalte zugreifen. Die Begründung im Blog ist bemerkenswert offen: Design Systems seien immer die Grundlage für Konsistenz gewesen, und je mehr Teams mit Agenten arbeiten, desto wichtiger werde diese Grundlage.

TechCrunch fasst die Ankündigung unter der Überschrift „Figma announces new features to define how agents work on its platform“ (öffnet neuen Tab) zusammen und nennt den Hintergrund: KI arbeitet nicht deterministisch, also braucht es Werkzeuge, die ihre Ergebnisse vorhersehbarer machen.

Wichtig für die Einordnung: Vieles davon ist Beta oder Vorschau. Wie gut es im Alltag funktioniert, ist offen. Interessant ist weniger das einzelne Produkt als die Richtung, in die sich ein ganzes Werkzeugfeld bewegt.

Das Prinzip – unabhängig vom Hersteller

Hinter der Ankündigung stecken drei Entwicklungen, die nicht an ein Werkzeug gebunden sind.

Agenten brauchen eine Schnittstelle zum Wissen. Das Model Context Protocol (MCP) ist ein offener Standard, den Anthropic im November 2024 veröffentlicht (öffnet neuen Tab) hat. Die offizielle Dokumentation (öffnet neuen Tab) vergleicht ihn mit einem USB-C-Anschluss für KI-Anwendungen: ein einheitlicher Weg, über den ein Agent Daten und Werkzeuge anderer Systeme erreicht. Ein Design System, das per MCP erreichbar ist, kann ein Agent beim Arbeiten nachschlagen, statt zu raten.

Grundwerte brauchen ein gemeinsames Format. Die Design Tokens Community Group, eine Community Group beim W3C, hat im Oktober 2025 die erste stabile Version ihrer Token-Spezifikation (öffnet neuen Tab) veröffentlicht: ein herstellerneutrales Format, um Farben, Typografie und Abstände zwischen Werkzeugen und Plattformen auszutauschen.

Texte brauchen eine Form, die Maschinen gut lesen. Ein Beispiel ist der Vorschlag llms.txt (öffnet neuen Tab) von Jeremy Howard aus dem Jahr 2024: eine Markdown-Datei, die Agenten hilft, eine Website zu verstehen. Ein Standard ist das nicht, aber ein Hinweis darauf, wohin es geht – schlichtes, strukturiertes Markdown statt verschachtelter Seiten.

Zusammen ergibt das ein klares Bild: Ein Agent kann sich nur an Regeln halten, die er erreicht, versteht und eindeutig auslegen kann.

Was sich dadurch ändert

Für Menschen ist Dokumentation eine Hilfe. Für einen Agenten ist sie die einzige Wahrheit. Daraus folgen drei Verschiebungen.

Implizites Wissen wird zum Fehler. „Das macht man bei uns so“ wirkt nur bei Menschen, die es irgendwann gehört haben. Was nicht aufgeschrieben ist, existiert für den Agenten nicht.

Begründungen werden wichtiger als Beispiele. Ein Agent kopiert ein Beispiel gern auch dort, wo es nicht passt. Steht dabei, warum eine Regel gilt, steigt die Chance, dass er sie auch in neuen Situationen richtig anwendet.

Lücken werden sichtbar – und messbar. Fehlende Beschreibungen, fehlende Zustände, widersprüchliche Angaben: Genau so etwas sollen Prüfwerkzeuge wie die angekündigten System Checks finden. Ob man dafür ein Werkzeug braucht oder ein Agent die eigene Doku einmal gegenliest, ist zweitrangig. Wichtig ist, dass man hinschaut.

Was das für Unternehmen heißt

Kein Grund zur Eile, aber ein guter Grund, aufzuräumen. Wer ein gepflegtes Design System hat, kann KI-gestützte Entwicklung besser steuern. Wer keines hat, riskiert mit Agenten vor allem eines: schneller viele leicht unterschiedliche Oberflächen.

Eine Warnung gehört dazu: Regeln, die nur in einem Werkzeug stecken, hängen an diesem Werkzeug. Wer Tokens in einem offenen Format und Regeln als schlichten Text pflegt, kann sie jedem Agenten geben – heute über den einen Anbieter, morgen über einen anderen.

Was Sie heute tun können

1. Den Agenten-Test machen. Geben Sie einem KI-Werkzeug nur die Dokumentation einer einzigen Komponente und lassen Sie es eine Ansicht damit bauen. Was es falsch macht, zeigt Ihnen, was in der Doku fehlt.
2. Ungeschriebene Regeln einsammeln. Fragen Sie im Team: Was erklären wir neuen Kolleginnen und Kollegen immer wieder mündlich? Schreiben Sie es auf – mit Begründung.
3. Tokens befreien. Prüfen Sie, ob Ihre Grundwerte in einem offenen, maschinenlesbaren Format vorliegen oder nur in einem Werkzeug.
4. Eine Lücken-Inventur starten. Haben alle Komponenten eine Beschreibung, alle Zustände (deaktiviert, Fehler, Laden) eine Regel? Die Liste der Lücken ist Ihr Arbeitsplan.

Design Systems waren immer ein Vertrag zwischen Gestaltung und Entwicklung. Jetzt sitzt eine dritte Partei mit am Tisch, die alles wörtlich nimmt. Das ist anstrengend – und eine gute Gelegenheit, endlich aufzuschreiben, was bisher nur in Köpfen stand.