Wann ist ein Designsystem wirklich „KI-bereit“?

Laut einer Umfrage von zeroheight nennen nur 17 Prozent der Designsystem-Teams ihre Dokumentation „sehr KI-tauglich“, 48 Prozent betreiben dagegen schon einen MCP-Server. Sean Voisen, Führungskraft im Design-Systems-Engineering, hält die Frage dahinter für falsch gestellt: Entscheidend sei weniger, was ein Modell lesen kann, als wo im System noch ein Mensch urteilt.

Sean Voisen hat in einem Essay vom September 2026 beschrieben, was „KI-bereit“ bei einem Designsystem heißen sollte.^[1] Die meisten Teams setzen laut Voisen auf dieselben Mittel: maschinenlesbare Dokumentation, Tokens, Skills und MCP-Server. Wie ein Ergebnis wirken soll, sagen sie nicht.^[1]

Warum reicht lesbare Dokumentation nicht aus?

Ungeschriebenes Wissen lässt sich nicht in Markdown-Dateien packen.

Voisen berichtet von Bildschirmen, bei denen Komponenten, Abstände und Farben stimmen und das Ergebnis dennoch „ein bisschen daneben“ wirkt.^[1] Voisen erklärt das mit Ashbys Gesetz aus der Kybernetik: Ein Regler braucht mindestens so viel Vielfalt wie die Störungen, die er ausgleicht.^[1] Ein erfahrener Designer bringt davon viel mit, ein Modell mit Markdown-Dateien laut Voisen weniger.

Ein Designsystem garantiert demnach nur eine Untergrenze für Qualität, die Obergrenze halten Menschen. Gegen das Absinken helfen zwei Mittel: die Erzeugung einzuengen (Regeln, Skills) und das Ergebnis zu bewerten (Prüfschleifen).^[1]

Was zeigen Zahlen und Tests?

Dokumentation entscheidet in Tests über das Ergebnis, und nur wenige Teams halten sie für KI-tauglich. Das belegen ein Branchenreport und ein Testaufbau.

Der zeroheight-Report „State of AI in Design Systems 2026“ beruht auf 123 Befragten, meist Produktdesign-Leitern größerer Technologiefirmen. Am zufriedensten sind sie mit KI beim Schreiben von Dokumentation (63 Prozent), am unzufriedensten beim Entwerfen von Oberflächen (Netto-Zufriedenheit minus 53).^[3]

PJ Onori lässt je drei Agenten mit dem alten und dem neuen Designsystem dieselbe Oberfläche bauen und wertet unter anderem Zeit, Korrekturversuche und Inline-Styles aus. Jede erfasste Kennzahl verbesserte sich, getestet hat er bisher nur mit Claude-Modellen, und ein solcher Test kostet etwa so viel wie ein günstiger Kaffee.^[2] Zufällige Aufgaben deckten Fehler auf, die eine feste Aufgabe verbarg.^[2]

Was sollten Teams jetzt festlegen?

Teams sollten schriftlich festlegen, welche Entscheidungen ein Mensch abnimmt, und ihr System mit wechselnden Aufgaben prüfen.

Voisen schlägt eine ungetestete Idee vor, die auf David Hoang zurückgeht: ein Entscheidungsprotokoll, das Layoutentscheidungen und bewusste Abweichungen vom System beim Arbeiten festhält.^[1] Zugleich räumt Voisen ein, dass ein Protokoll zur Überwachung missbraucht werden kann und ein Modell vor allem frühere Entscheidungen wiederholt.^[1]

Für Agenturen und Inhouse-Teams heißt das: Testen Sie wie Onori mit zufälligen Aufgaben und benennen Sie die Stellen, an denen ein Mensch freigibt. Microsoft liefert sein Designsystem bereits als MCP-Server aus, doch ein gemeinsames Format fehlt: Adobes Design Data Specification liegt als Entwurf 1.0.0-draft vor,^[4] Voisen nennt zudem Googles DESIGN.md.^[1]

Wie sich eine Figma-Bibliothek aus dem Code bauen lässt, zeigt ein früherer Beitrag. Wo die Autonomie eines Agenten enden soll, behandelt der Beitrag zum Stopp-Knopf für KI-Agenten.

Quellen

Mehr Newshunger?

• Design-Systeme für KI-Agenten: Warum Microsoft sein Design-System als MCP-Server ausliefert
• Figma-Bibliothek aus dem Code bauen: Workflow mit MCP
• Stopp-Knopf für KI-Agenten: Wer gestaltet ihn?
• KI-Designer werden: Warum Designer heute ihren eigenen Code ausliefern
• interface-bts: Skill zeichnet Animationen als Spezifikations-Poster
• Die Softwarefabrik hat das Design vergessen: Atif Azam lässt KI-Agenten erst in Paper entwerfen