Brauchen jetzt alle ein AI-ready Design System?

Brauchen jetzt alle ein AI-ready Design System?

Warum es bei AI und Design Systems weniger um perfekte UI-Generierung geht, sondern darum, Produktwissen explizit zu machen.

Rund um Design Systems und AI entsteht gerade eine neue Kategorie von Best Practices. Design Tokens werden maschinenlesbar gemacht, Komponenten für LLMs katalogisiert. llms.txt, Agent-Anweisungen, Skills und MCP-Server [1] sollen AI-Agenten dabei helfen, bestehende Design Systems korrekt zu verwenden. Automatisierte Checks erkennen unerlaubte Spacing-Werte oder erfundene Komponenten, manche Organisationen evaluieren ihre AI-Artefakte inzwischen sogar mit Benchmarks und Regressionstests.

Die Beispiele dafür kommen meistens von Unternehmen wie Atlassian, Shopify oder IBM. Also von Organisationen mit großen Design-System-Teams, vielen Produktteams und entsprechend komplexer Infrastruktur.

Atlassian experimentiert zum Beispiel damit, Design-System-Wissen über Skills und MCP für Agenten verfügbar zu machen und die Qualität der Ergebnisse zu messen. [2] Shopify bietet AI-Zugriff auf Polaris über einen eigenen Dev-MCP-Server, ein Plugin und dedizierte Skill-Dateien. [3] Und IBMs Design System Carbon macht über einen eigenen MCP-Server und ein offenes Repository sehr explizit, welche Komponenten tatsächlich zum System gehören – eine simple, aber wirkungsvolle Methode gegen halluzinierte UI-Bausteine. [4]

Schaut man sich solche Beispiele an, könnte man schnell denken: So muss ein modernes Design System heute aussehen.

Das wäre allerdings die falsche Lektion.

Entscheidend ist nämlich gar nicht, welche Infrastruktur die fortschrittlichsten Design-System-Teams der Welt aufgebaut haben, sondern welches Problem damit eigentlich gelöst wird, und ob dieses Problem in der eigenen Organisation überhaupt existiert.

Das eigentliche Problem ist nicht AI

LLMs können schon heute erstaunlich brauchbare Interfaces erzeugen. Dabei treffen sie allerdings permanent kleine Entscheidungen: Welche Abstände werden verwendet? Welche Komponente passt? Wie sieht ein Empty State aus? Ist die richtige Lösung ein Modal, ein Drawer oder eine Inline-Interaktion? Welche Button-Variante wird verwendet? Wie werden Fehler kommuniziert?

Ohne weitere Vorgaben entscheidet das Modell das einfach selbst. Und jede einzelne dieser Entscheidungen kann für sich genommen völlig plausibel aussehen. Das eigentliche Problem entsteht erst in der Summe.

Der erste Screen verwendet 16 Pixel Abstand, der nächste 12. Ein Agent baut einen Stack, obwohl die Komponenten-Bibliothek nur Flex kennt. Ein anderer implementiert einen eigenen Select, obwohl längst einer existiert. Nach zehn Durchläufen sieht das Produkt immer noch irgendwie richtig aus, aber nicht mehr wirklich wie dasselbe Produkt. [5]

Die naheliegende Antwort darauf lautet meistens: mehr Kontext. Das LLM muss das Design System einfach besser kennen.

Genau hier beginnt aber schon die erste Fehlannahme. Das Ziel sollte nicht sein, einem Modell ein möglichst umfassendes Handbuch zu geben und zu hoffen, dass es alles korrekt berücksichtigt. Das sinnvollere Ziel ist, dass das Modell dort möglichst wenig neu entscheiden muss, wo Entscheidungen längst getroffen wurden.

Sind im Design System fünf Spacing-Werte festgelegt, soll der Agent keinen sechsten erfinden. Gibt es keinen Stack, darf er auch keinen Stack verwenden. Und müssen destruktive Aktionen immer bestätigt werden, ist das keine kreative Entscheidung des Modells.

AI macht damit vor allem eines sichtbar: wie viel von unserem Produktwissen tatsächlich definiert ist und wie viel eigentlich nur implizit existiert.

Von der Dokumentation zum Executable Design System

Der Begriff „Executable Design System“ ist mittlerweile hilfreicher als „AI Design System“.

Ein Executable Design System ist kein zusätzlicher Reifegrad und auch kein Synonym für MCP, Skills oder Agent Tooling. Gemeint ist einfach ein Design System, dessen Regeln nicht ausschließlich dokumentiert sind, sondern teilweise auch von Software und Agenten gelesen, verwendet und überprüft werden können.

Ein klassisches Design System sagt: „Diese Button-Varianten gibt es.“ Ein ausführbareres System macht dieselbe Information gleichzeitig über mehrere Wege zugänglich. Designer sehen die Varianten in Figma. Entwickler bekommen sie über Komponenten und Types. Agenten können sie aus einer Registry oder Dokumentation abrufen. Und ein Linter erkennt, wenn eine nicht erlaubte Variante verwendet wird.

Dasselbe Prinzip lässt sich auf Tokens, Barrierefreiheits-Regeln, Komponenten-APIs oder ausgewählte UX Patterns übertragen. Damit entstehen keine perfekt deterministischen Interfaces, sondern etwas viel Praktischeres: eine gemeinsame Produktgrammatik für Menschen und Maschinen.

„Agent-ready“ beschreibt dann eigentlich nur noch, wie gut ein Agent auf diese Produktgrammatik zugreifen kann und wie zuverlässig er innerhalb ihrer Grenzen arbeitet.

Nicht alles lässt sich in Regeln übersetzen

Hier liegt gleichzeitig die Grenze der ganzen Idee.

Design Systems können relativ gut definieren, was man die Design-Grammatik nennen könnte: Welche Komponenten existieren, welche Tokens erlaubt sind, wie Komponenten kombiniert werden. Sie können auch Teile der Interaktions-Grammatik abbilden, also wann man einen Dialog verwendet, wie Formularfehler funktionieren, wie Bulk Actions aussehen oder wie sich Empty States verhalten.

Deutlich schwieriger wird es bei Produktentscheidungen. Soll dieses Feature überhaupt existieren? Welche Information braucht ein Nutzer an dieser Stelle wirklich? Ist eine Tabelle die richtige Darstellung? Warum scheitert ein bestehender Prozess eigentlich? Und sollte man einen komplexen Workflow besser gestalten oder ihn lieber ganz abschaffen?

Keine Komponenten-Registry beantwortet diese Fragen. Und genau deshalb wäre es zu kurz gedacht, das Ziel dieser Entwicklung so zu verstehen: Anforderung rein, AI, perfektes Interface raus.

Je besser AI in der reinen Produktion von Screens und Code wird, desto stärker verschiebt sich der Wert zu den Entscheidungen davor und zur Validierung danach. Die Frage lautet dann seltener, wie wir dieses Interface bauen. Sondern öfter, was wir damit eigentlich erreichen wollen und welche Entscheidungen wir überhaupt automatisieren sollten.

Für einen Mittelständler sieht die Aufgabe anders aus als für einen Konzern

Der Mittelständler: erst einmal systematisieren

Viele Unternehmen brauchen zunächst gar kein AI-ready Design System. Sie brauchen überhaupt erst ein belastbares System. Da existieren dann vielleicht fünf verschiedene Varianten eines Primary Buttons, Abstände werden nach Gefühl vergeben, Design und Frontend verwenden unterschiedliche Komponenten, und wichtige Interaction Patterns unterscheiden sich von Produktbereich zu Produktbereich.

In so einem Fall wäre es nicht zielführend, als Erstes über MCP-Server oder AI-Eval-Pipelines zu sprechen. Der sinnvollere Schritt ist viel grundlegender: Tokens definieren, Komponenten konsolidieren, wiederkehrende UX-Patterns festhalten, Design und Code zusammenbringen, klare Regeln etablieren.

Dass Agenten davon profitieren, ist ein netter Nebeneffekt. Aber im Kern löst man damit ein Problem, das lange vor generativer AI existiert hat. AI liefert vielleicht nur einen weiteren guten Grund, diese Arbeit endlich anzugehen, denn wenn künftig sowohl Menschen als auch Agenten Interfaces produzieren, wird eine gemeinsame Produktsprache noch wichtiger.

Der Konzern: vorhandenes Wissen für Agenten operationalisieren

Bei reiferen Organisationen sieht die Situation anders aus. Dort gibt es meistens schon umfangreiche Figma-Bibliotheken, Design Tokens, Storybook, hunderte Komponenten, Richtlinien zur Barrierefreiheit, etablierte UX-Patterns und mehrere Produktteams.

Das Problem lautet nicht „Was ist unser Design System?“, sondern eher „Wie stellen wir sicher, dass Agenten es genauso zuverlässig verwenden wie unsere Teams?“

Genau dort werden die Enterprise-Beispiele interessant, allerdings nicht als Blaupause, sondern eher als Werkzeugkasten. Vielleicht reicht schon eine kleine Agent-Datei, die auf relevante Pattern-Dokumentation verweist. Vielleicht braucht es eine explizite Komponenten-Allow-list, also eine feste Liste erlaubter Bausteine. Vielleicht lassen sich AI-Dokumentationen automatisch aus dem bestehenden Code generieren, damit sie nie veraltet. Oder ein Linter, der Regelverstöße automatisch erkennt, ist wichtiger als noch mehr Kontext im Prompt. Und bei ausreichend vielen Teams, Repositories und Tools kann irgendwann auch ein zentraler Retrieval-Layer sinnvoll werden, über den alle denselben aktuellen Stand abrufen, oder MCP als Protokoll, das genau das standardisiert.

Die Reihenfolge sollte dabei aber immer dieselbe bleiben: erst das Problem, dann die Infrastruktur. Nicht umgekehrt.

Was sich wirklich lohnt

Weder Mittelständler noch Konzern brauchen dafür zwangsläufig die Infrastruktur der eingangs genannten Enterprise-Beispiele. Für viele Organisationen dürfte eine erstaunlich unspektakuläre Architektur schon sehr weit reichen.

Eine belastbare Source of Truth

Tokens, Komponenten und ihre APIs müssen eindeutig sein. Nicht perfekt, nicht akademisch vollständig modelliert, aber klar genug, dass zwei Menschen und zwei Agenten nicht fünf verschiedene Interpretationen daraus ableiten.

Explizite Grenzen

„Halte dich an unser Design System“ ist eine schlechte Regel. „Verwende ausschließlich diese Komponenten“ ist eine gute. „Nutze unsere Farben“ ist schwammig, „keine hardcodierten Farben, ausschließlich definierte Tokens“ ist überprüfbar. Besonders nützlich sind dabei negative Regeln, also was ausdrücklich nicht passieren darf. LLMs sind gut darin, plausible Lücken kreativ zu füllen, und genau deshalb sollte man ihnen bei bekannten Fehlermustern sagen, was nicht existiert und nicht erfunden werden darf.

Die wichtigsten UX-Patterns

Nicht jede Entscheidung steckt in einem Button oder Token. Formulare, Tabellen, Dialoge, Navigation, Suche, Empty States oder komplexe Actions enthalten oft viel mehr Produktwissen als einzelne Komponenten. Dafür braucht es keine Dutzenden Spezifikationsdateien. Fünf bis fünfzehn gut formulierte Patterns können für ein Produkt wertvoller sein als eine vollständige Dokumentation jedes UI-Atoms.

Deterministische Checks

Was Software eindeutig prüfen kann, sollte nicht von einem LLM beurteilt werden. Existiert die Komponente? Ist der Token erlaubt? Ist TypeScript valide? Gibt es offensichtliche Barrierefreiheits-Probleme? Wurde eine verbotene Variante verwendet? Je mehr dieser Fragen automatisch beantwortet werden, desto weniger hängt die Qualität davon ab, welches Modell heute gerade eingesetzt wird. Das ist vermutlich einer der wichtigsten Punkte der ganzen Diskussion: Modelle ändern sich, deterministische Regeln nicht. [6]

Auch hier gilt: Die technische Lösung sollte aus einem beobachtbaren Problem entstehen, nicht umgekehrt. Erfinden Agenten Komponenten, hilft eine Allow-list. Verwenden sie ständig falsche Spacing-Werte, ist eine Token-Prüfung vermutlich sinnvoller als ein MCP-Server. Ist die zentrale Agent-Datei so groß geworden, dass relevanter Kontext untergeht, lohnt sich progressive disclosure. Veraltet die AI-Dokumentation nach jedem Release, kann automatische Generierung helfen. Und brauchen Dutzende Teams in unterschiedlichen Repositories zuverlässig Zugriff auf denselben aktuellen Stand des Design Systems, wird ein zentraler Retrieval-Layer interessant.

Die Architektur folgt also dem Problem, nicht dem aktuellen Tooling-Trend.

Vielleicht verändert AI vor allem die Rolle von Design Systems

Design Systems wurden lange über zwei Argumente verkauft: Konsistenz und Effizienz. Ein Button muss nicht immer wieder neugestaltet werden, ein Pattern muss nicht jedes Team neu erfinden.

Mit AI kommt jetzt eine dritte Dimension dazu: explizites Produktwissen.

Denn vieles, was ein Produkt heute konsistent macht, steht eigentlich nirgendwo. Es steckt in Figma-Kommentaren, in Slack-Unterhaltungen, in alten Tickets oder schlicht in der Erfahrung einzelner Designer und Entwickler. Menschen können mit diesem impliziten Wissen erstaunlich lange arbeiten. Agenten deutlich schlechter.

AI macht damit eine Schwäche sichtbar, die auch ohne AI längst existiert: Unternehmen haben oft sehr genaue Vorstellungen davon, wie ihre Produkte funktionieren sollen, aber nur einen Teil davon tatsächlich systematisiert.

Genau darin liegt vielleicht der eigentliche Wert dieser Entwicklung. Nicht jedes implizite Wissen muss formalisiert werden, und schon gar nicht jede Entscheidung automatisiert. Aber überall dort, wo Entscheidungen wiederholt getroffen werden, wo Standards gelten oder wo Abweichungen regelmäßig zu Problemen führen, lohnt es sich, dieses Wissen expliziter zu machen.

Ein AI-ready Design System versucht im besten Fall also nicht, jede Designentscheidung zu automatisieren. Es sorgt dafür, dass bereits getroffene Entscheidungen so klar beschrieben und technisch abgebildet sind, dass Menschen und Maschinen gleichermaßen darauf aufbauen können.

Und genau hier zeigt sich, worum es bei der Begleitung digitaler Produkte eigentlich gehen sollte: nicht darum, möglichst viel AI-Infrastruktur zu verkaufen, sondern darum, gemeinsam mit Organisationen zu klären, welche Teile ihrer Produktlogik überhaupt systematisiert werden sollten und welche technische Unterstützung ihrem tatsächlichen Reifegrad angemessen ist.

Die Antwort kann eine saubere Komponenten-Bibliothek und ein paar gut dokumentierte Patterns sein. Sie kann Agent-Anweisungen und automatisierte Checks umfassen. Und bei entsprechender organisatorischer Größenordnung kann auch umfangreichere Infrastruktur sinnvoll werden. Der Maßstab sollte dabei aber nie sein, wie nah die eigene Architektur an einem vermeintlichen Enterprise-Goldstandard liegt, sondern ob sie ein reales Problem löst.

Je besser LLMs darin werden, grundsätzlich gute Interfaces zu erzeugen, desto weniger interessant wird eigentlich die Frage, ob sie wissen, wie man UI baut. Entscheidender wird, ob eine Organisation selbst klar genug definiert hat, wie ihre Produkte gebaut werden sollen und warum.

Vielleicht ist genau das die eigentliche Chance hinter AI und Design Systems. Nicht die perfekte automatisierte Oberfläche, sondern ein Anlass, Produktwissen endlich so explizit zu machen, dass es nicht mehr nur in den Köpfen einzelner Menschen existiert.

Fußnoten

1. llms.txt-Spezifikation; AGENTS.md-Standard
2. Atlassian: Building the context engine for the AI era; Teaching AI to speak our design language
3. Shopify AI Toolkit Setup Guide
4. Carbon Design System auf GitHub
5. Hardik Pandya: Expose your design system to LLMs
6. Kaelig Deloumeau-Prigent: Building design system components with agent teams