Du hast über Jahre ein richtig gutes Designsystem aufgebaut. Es ist aus der Praxis herausgewachsen, wird mehr oder weniger selbstorganisiert gepflegt, ist soweit es geht aktuell und wird von den Entwicklungsteams weitestgehend berücksichtigt. Die Regeln stehen in Confluence oder SharePoint. Alles ist sauber dokumentiert. Die UI-Komponenten gibt es einmal für die Designer:innen in Figma und einmal für die Entwickler:innen in Storybook. Ein kleines DesignOps-Team hält das Ganze zusammen und es funktioniert. Bisher.
Denn jetzt arbeiten immer mehr Entwicklungsteams mit agentischen Entwicklungsframeworks (z.B. BMAD) oder Entwicklungsagents. Prototypen-Generatoren, wie Figma Make, sind ein selbstverständlicher Bestandteil des Kreationsprozesses. Auf einmal sollen nicht nur Menschen mit Deinem Designsystem arbeiten, sondern auch Agenten. Sie sollen daraus in Minuten Bedienoberflächen generieren, die dem Designsystem entsprechen. Das ist genau der Moment, in dem ich gemerkt habe, dass ein gut gepflegtes klassisches Designsystem für die neuen agentischen Leser schlicht nicht ausreicht.
In diesem Artikel möchte ich mit Dir die Erfahrungen teilen, die ich gerade bei der Transformation eines großen Designsystems mache, dass von sehr vielen Teams in der Softwareentwicklung verwendet wird. Wir haben in den letzten Monaten sehr viel ausprobiert, getestet, verworfen und in Produktion überführt – von KI-basierten Prototypen-Generatoren über Design2Code-Pipeline bis hin zu automatisierter Qualitätssicherung. Manches war auf den ersten Blick begeisternd. Vieles davon war ernüchternd. Manches war auch ein echter Aha-Moment.
Fangen wir mal von vorn an und werfen einen Blick darauf, was Designsysteme bisher waren. Ein klassisches Designsystem war bisher im Kern ein Dokumentationssystem. Ein typischer Aufbau eines Designsystems für eine Softwareentwicklung sah beispielsweise so aus:
- Confluence für die Designregeln,
- Storybook und Repositories für die UI-Komponenten und
- Figma für den Entwurf.
Die Erstellung und Weiterentwicklung des Designsystems ist Aufgabe des DesignOps-Teams. Die UX-Designer:innen in den Teams nutzen das Designsystem indem sie es lesen, interpretieren und mit ihrer Expertise anwenden. Konsistenz entsteht dabei durch ein gemeinsames Verständnis unter den UX-Designer:innen, durch guten Willen und durch Formate wie Design Reviews. Das trägt erstaunlich weit.
Wo die Änderungen beginnen
Und genau hier ist jetzt ein Bruch entstanden. Agents interpretieren Designregeln nicht so, wie es ein:e erfahren:e UX-Designer:in tun würde. Designregeln, die für Menschen geschrieben wurden, verleiten sie ganz schnell zum Halluzinieren. Ein gemeinsames Design-Verständnis zwischen Design-Agents und UX-Designer:innen kann so nicht entstehen.
Das lässt sich gut am Beispiel Call-to-Action-Button erklären. In einem klassischen Designsystem würde es schon reichen, wenn man neben der Figma-Komponente definiert, dass der primäre Call-to-Action einen klaren Aufforderungscharakter haben soll und gut sichtbar positioniert sein soll. Ein paar Beispiele würden den Einsatz zeigen. Ein:e erfahren:e UX-Designer:in weiß damit sofort, was gemeint ist.
Ein Sprachmodell auch, glaubt es zumindest. Es liest die Beschreibung und bewertet dann aber jede halbwegs bunte und hervorgehobene Schaltfläche als regelkonform. Denn “Aufforderungscharakter” ist für ein Sprachmodell keine prüfbare Bedingung. Maschinenlesbar wird die Regel erst, wenn Du sie konkretisierst. Die Beschreibung könnte dann zum Beispiel und auszugsweise so aussehen:
- Nur semantische Tokens aus `tokens/action.json` verwenden, referenziert über CSS Custom Properties: `var(–action-primary-bg)`.
- NIEMALS Hex-Werte, `rgb()`, Tailwind-Farbklassen oder Pixelwerte hart codieren.
- NIEMALS Primitive direkt nutzen (`–palette-blue-600` ist verboten, `–action-primary-bg` ist korrekt).
- Immer `<button type=”button”>`. Kein `<div>`, kein `<a>` mit onClick. `<a>` nur, wenn das Ziel eine navigierbare URL ist.
- Genau ein Primary-CTA pro Bildschirmabschnitt. Weitere Aktionen als Secondary oder Tertiary.
- Trefferfläche mindestens `var(–action-size-min-target)` in beide Richtungen, auch wenn der sichtbare Button kleiner wirkt (Pseudo-Element nutzen).
- Verb im Infinitiv + Objekt, maximal drei Wörter, maximal 25 Zeichen.
- Das Label beschreibt das Ergebnis für die Person, nicht die Systemaktion.
- Kein Punkt am Ende, keine Versalien-Schreibweise per CSS.
- Verboten: “Hier klicken”, “Absenden”, “OK”, “Weiter” ohne Kontext, “Mehr erfahren” als alleinstehendes Label.
- Gut: “Beleg hochladen”, “Termin buchen”, “Auswertung starten”.
- Sichtbares Label ist der Accessible Name. `aria-label` nur bei Icon-only- Buttons und dann identisch zur Bedeutung des Icons.
- Fokus: `:focus-visible` mit mindestens 2px Outline und 2px Offset, Farbe `var(–action-focus-ring)`. `outline: none` ohne Ersatz ist verboten.
- Kontrast: Text zu Fläche mindestens 4.5:1, Button-Fläche zu Umgebung und Fokusindikator mindestens 3:1
Designregeln lassen sich zu einem großen Teil in solche maschinenlesbaren und prüfbaren Bedingungen überführen. Das ist allerdings eine genauso große Herausforderung, wie die Erklärung von Designregeln an eine nicht-designaffine Zielgruppe. Außerdem hat die Erfahrung auch gezeigt, dass es bei manchen Designregeln nicht die richtigen Worte gibt, um sie für Agents ausreichend zu beschreiben.
Ein Designsystem ist kein Nachschlagewerk mehr, in dem man bei Bedarf nachschlägt. Es ist zu einem Produkt geworden, was einen Teil der Infrastruktur für UI-Generierung bereitstellt. Es ist ein integraler Bestandteil des Entwicklungsprozesses. Es liefert Kontextinformationen zu Design, wie z.B. Design-Tokens nach dem W3C-Standard oder Regeln als strukturierte Markdown-Dateien. Es wird durch QS-Tools, wie z.B. Design Linter, die generierte Oberflächen automatisch gegen das Designsystem prüfen, ergänzt. Und, es muss für zwei unterschiedliche Arten von Anwender:innen gestaltet werden. Die Menschen, die damit gestalten bzw. entwickeln, und die Maschinen, die daraus generieren bzw. prüfen.
Warum das Führung braucht
Solange das Designsystem eine Dokumentation war, konnte es im Hintergrund vor sich hin wachsen. Fiel die Confluence-Seite mal einen Tag aus oder war eine Designregel nicht bis ins letzte Detail ausdefiniert oder nicht ganz aktuell, war das zwar ärgerlich, aber nicht tragisch. Die menschliche Expertise der UX-Designer:innen hat für einen passenden Ausgleich gesorgt. Nun ist das Designsystem aber zum Treibstoff der Softwareentwicklung geworden und das ändert die Lage grundlegend.
Denn mit dem Produktcharakter kommt auch eine Betriebsverantwortung. Wenn die maschinenlesbaren Designinformationen lückenhaft, widersprüchlich oder schlicht nicht erreichbar sind, dann generiert der agentische Entwicklungsprozess für viel Geld Müll. Die Schadensbreite ist eine ganz andere als früher. Vorher hat eine unklare Regel eine:n UX-Designer:in vielleicht 1-2 Stunden Klärung gekostet. Jetzt ziehen sie sich solche Fehler gleichzeitig durch mehrere generative Entwicklungs-Pipelines im Unternehmen.
Außerdem kann die Umsetzung von Designregeln nicht mehr auf einem gemeinsamen Verständnis ala “Wir wollen alle eine konsistente Gestaltung und deshalb halten uns alle an das Designsystem” ruhen. Das trägt in der neuen Welt nicht mehr. Ein Designsystem, aus dem laufend generiert wird, braucht eindeutige Ownership und eine entsprechende Governance. Es braucht eine Person, die verantwortet, dass die gelieferten Kontextinformationen stimmen und aktuell sind sowie die Daten bereitgestellt werden und die QS-Tools laufen.
Die bisher häufig genutzten Ansätze zur selbstorganisierten Pflege des Designsystems bzw. Innersource-Ansätze für die Weiterentwicklung von Designsystemen waren die richtige Antwort für die Dokumentations-Ära. Für die Produkt-Ära sind sie es nur noch bedingt. Das Designsystem als Infrastruktur braucht klare Verantwortung, Führung und definierte Ressourcen.
Was sich nicht maschinenlesbar machen lässt
Die Maschinenlesbarkeit hat Grenzen. Werfen wir nochmals einen Blick auf das CTA-Beispiel von eben. Wir konnten den Aufforderungscharakter recht gut in Tokens und Textregeln übersetzen. Ob der Button aber letztendlich im konkreten Kontext wirklich das erwünschte Verhalten erzeugt, ob er zur Situation oder zur Emotion der Anwender:innen passt, das kann bislang kein automatisiertes System beurteilen.
Das ist aus meiner Sicht keine Kinderkrankheit, die sich mit der nächsten Sprachmodell-Version erledigt hat. Das liegt in der Natur von Sprachmodellen. Und lässt damit weiterhin Raum für die menschlichen Aspekte von Produktgestaltung.
Das menschliche Urteil verschwindet nicht aus dem Entwicklungsprozess. Es wandert weg vom stundenlangen Ausarbeiten einzelner Screens, hin zu definierten Prüfpunkten, an denen UX-Designer:innen prüfen und entscheiden. Human-in-the-Loop nennt sich das im Fachjargon. Praktisch heißt es, dass die Maschine generiert und das Prüfbare prüft, während der Mensch beurteilt, was sich nicht prüfen lässt. Und, der Mensch passt die Maschine an, wenn sie handwerkliche Fehler macht.
Genau hier schließt sich der Kreis zur Führungsfrage. Wenn Menschen an klar definierten Punkten prüfen und anpassen müssen, dann brauchst Du zum einen diese Checkpoints und Du brauchst die Menschen mit dem Mandat, dort zu entscheiden.
Was Designsystem-Führung jetzt heißt
Wenn das Designsystem ein Produkt ist, dann muss es auch wie eins geführt werden. Das heißt konkret, dass es eine:n Product Owner:in bekommt. Jemanden, die/der ein Zielbild für die Weiterentwicklung des Produktes hat, Governance und Quality Gates für Design in agentischen Entwicklungsprozessen definiert, für die Bereitstellung von Designregeln als maschinenlesbare Kontextinformationen sorgt, Namenskonventionen durchsetzt, ein Contribution-Modell für die Weiterentwicklung des Designsystems aufsetzt, das Onboarding neuer Verwender:innen des Designsystems regelt und die Beschreibungspakete bereitstellt, mit denen die Design-Agents überhaupt erst sauber arbeiten.
Für die Führung des Designsystems gibt es aus meiner Sicht noch zwei Herausforderungen:
Erstens Tool-Unabhängigkeit: Die Werkzeuglandschaft im KI-Design ändert sich im Monatstakt und die Preise sind noch weniger vorhersehbar. Wer seine Design-Pipeline hart an ein proprietäres Tool, wie z.B. Figma, verdrahtet, gibt die Kontrolle über Kosten und Zukunft aus der Hand. Deshalb lohnt es sich, die Designinformationen unabhängig vom einzelnen Werkzeug zu halten, in gängigen Standardformaten sowie über generische Schnittstellen bereitzustellen. So bleibt die Souveränität über Deinen Design-Prozess im Unternehmen.
Zweitens die Weiterentwicklung der Designsprache: Generative Designprozesse konservieren nämlich den Status quo. Je tiefer eine Designsprache über Tokens, Designkontextinformationen und UI-Komponenten in die UI-Generierung eingebrannt ist, umso weniger variieren die Ergebnisse und umso weniger gestalterische Varianten werden entstehen. Wenn Du nicht aufpasst, friert Dir die Automatisierung genau die Gestaltung ein, die eigentlich lebendig bleiben soll. Die Weiterentwicklung der Designsprache braucht deshalb einen bewusst geschützten Raum außerhalb der automatisierten Design-Prozesse. Dieser kann beispielsweise in der Product Discovery als gestalterische Experimente nah an echten Anwender:innen seinen Platz finden. Wie das genau gelingt, dazu haben wir ehrlich gesagt noch keine fertige Antwort.
Was das mit Deinem DesignOps-Team macht
Diese Veränderungen treffen eine Gruppe besonders: Dein DesignOps-Team. Dessen Rolle verschiebt sich spürbar. Bisher war DesignOps eine operative Unterstützung für die Design-Community, die Tools und Prozesse am Laufen hielt. Sie sorgen für Effektivität und Effizienz in der Designarbeit. In einer automatisierten Infrastruktur verantwortet DesignOps auf einmal die Qualität der Design-Daten, aus denen generiert wird und damit mittelbar die gestalterische Qualität der Produkte selbst. Es übernimmt die Verantwortung von Teilen der agentischen Entwicklungspipeline (z.B. Design-Agents) oder betreibt die automatisierten QS-Mechanismen.
Damit ändern sich die Anforderungen an die Skills. Es reicht nicht mehr, Design bis zur Perfektion zu beherrschen und Design beschreiben zu können. Gefragt sind Fähigkeiten wie, Gestaltung in maschinenlesbare Regeln zu übersetzen, Design-Agenten zu definieren und zu orchestrieren sowie die QS-Werkzeuge für Design in agentischen Prozessen zu betreiben, zu überwachen bzw. zu verbessern.
Dafür zeichnet sich eine neue Rolle ab, die es in den meisten Organisationen bisher nicht gibt. Ich nenne sie UX-Pipeline Engineer. Gemeint sind damit Menschen, die über die Fähigkeiten verfügen Design, Entwicklung und Infrastruktur zusammendenken zu können. Die verstehen, was ein Designsystem gestalterisch leisten muss und die zugleich wissen, wie eine Maschine aus diesen Informationen produktiven Code erzeugt.
Wie Du da hinkommst
Vielleicht liest sich das bis hierhin wie ein großer Berg an Arbeit. Und ja, das ist es auch. Aber niemand kippt ein Designsystem über Nacht ins KI-Zeitalter. Es geht um einen gestuften Umbau und nicht um einen großen Sprung auf einmal.
Der häufigste Fehler, den ich beobachtet habe, ist der erste Griff zum Tool als Rettungsanker. “Wir kaufen uns KI-Tool XY und damit ist alles gut.” So funktioniert es leider nicht. Ohne sauberes Fundament aus maschinenlesbaren Kontextinformationen, kann auch das beste KI-Tool keine guten Ergebnisse liefern.
Fang mit dem Zielbild an. Was soll Dein Designsystem für Menschen und für Maschinen leisten? Danach kommt die unspektakuläre Basisarbeit. Also: Namen sauber ziehen, Tokens W3C-konform aufsetzen und Design-Dokumentation so umschreiben, dass sie auch eine Maschine verstehen kann. Parallel dazu lernst Du aus ersten Experimenten, welche Art von Ownership und welche Rollen gebraucht werden. Und erst dann kommen Design-Agents, UI-Generatoren, QS-Werkzeuge und ähnliche Tools dazu.
Was Du jetzt tun kannst
Wenn Du für ein Designsystem verantwortlich bist und Dich fragst, wo Du anfangen sollst, dann ist die kürzeste Antwort: nicht beim Tool. Fang bei Deinen Regeln an und frag Dich, ob eine Maschine sie verstehen kann und probiere es aus. Kläre, wer das Designsystem als Produkt verantwortet. Und schütze parallel den Raum, in dem Eure Designsprache weiter wachsen darf, damit die Automatisierung sie nicht einfriert.
Im KI-Zeitalter ist der Erfolg des Designsystems eine Frage von Infrastruktur, klaren Regeln, Rollen und einer guten Führung.
Beim Roundtable “Revolution der Designsysteme” tauschen wir uns über diese Fragen aus, mit Designsystem-Verantwortlichen, die gerade mitten in diesem Umbau stecken. Wenn Dich das Thema umtreibt, komm gern dazu. Es ist gerade eine der spannendsten Baustellen im UX-Bereich.
