Das Design System ist tot. Lang lebe das Design System.

Alle achtzehn Monate erscheint mit nahezu meteorologischer Regelmäßigkeit ein maßgeblicher Artikel, der den Tod des Design Systems verkündet. Ich habe die Sketch-Version gelesen, dann die Figma-Version, dann die Version mit KI-generierten Komponentenbibliotheken, dann die Version mit CSS-Frameworks ohne Konfiguration. Jedes Mal ist die Beerdigung verfrüht. Jedes Mal steckt im identifizierten Problem etwas wirklich Neues und in der Diagnose etwas Falsches.

Ich baue seit zehn Jahren Enterprise-Design-Systems. Tarvos für Exein – ein Design System für eine IoT-Sicherheitsinfrastruktur, das für Firmware-Ingenieure lesbar und für den Vorstand verständlich sein musste. Das Komponentensystem für Vodafone Italia. Frameworks für juristische, medizinische und Finanzprodukte. Ich habe gesehen, was überlebt und was nicht. Und ich sage es so: Die Grabredner irren sich immer über den Patienten, haben aber fast immer recht mit der Diagnose.

Das Muster, das sich wiederholt: neue Tools, dieselben Vorwürfe

Der wiederkehrende Vorwurf lautet, Design Systems seien zu starr, zu langsam, zu weit entfernt von der Realität der täglichen Entwicklung. Produktteams würden sie umgehen, statt sie zu nutzen. Die Figma-Bibliothek liege immer drei Versionen hinter dem Code. Niemand wisse, wem eine Komponente gehört, wenn sie aktualisiert werden muss. Die Notion-Dokumentation sei am Tag ihrer Erstellung korrekt gewesen und sechs Monate später nutzlos.

Alles wahr. Aber das sind keine Probleme des Design Systems – es sind Governance-Probleme. Und Governance verbessert sich nicht durch einen Wechsel des Tools. Der Umstieg von Sketch auf Figma hat das Problem veralteter Dokumentation nicht gelöst. Der Umstieg auf Storybook hat nicht geklärt, wer entscheidet, wenn Produkt und Design System einander widersprechen. Der Umstieg auf Design Tokens hat nicht geklärt, wer die Tokens aktualisiert, wenn sich die Marke ändert.

Was zyklisch stirbt, ist nicht das Design System. Es ist die Illusion, dass man es gelöst hat, wenn man es einmal gebaut hat.

Was zyklisch stirbt, ist nicht das Design System. Es ist die Illusion, dass man es gelöst hat, wenn man es einmal gebaut hat.

Was wirklich tot ist: das monolithische Modell

Eines ist wirklich tot, zumindest für mittlere bis große Enterprise-Teams. Es ist das Modell, das ich „den einen Ring“ nenne – ein zentralisiertes System, das den Anspruch erhebt, jedes Produkt, jede Oberfläche, jeden Anwendungsfall in der gesamten Organisation abzudecken.

Das Problem ist nicht konzeptionell, sondern operativ. Ein zentrales Team kann nicht jedes Produkt gut genug kennen, um für alle sinnvolle Entscheidungen über das Design System zu treffen. Ein System, das generisch genug ist, um überall zu funktionieren, ist am Ende generisch genug, um nirgendwo optimal zu sein. Und jede Ausnahme, die ein Produktteam anfordert, wird zu einem Ticket in einer Warteschlange, das Frustration erzeugt und inoffizielle Forks, die niemand dokumentiert.

Das Modell, das ich in den letzten drei Jahren am besten habe funktionieren sehen, ist föderiert: ein kleiner Kern gemeinsamer Entscheidungen – Typografie, semantische Farben, Abstandsskala, verpflichtende Barrierefreiheitsmuster – und dann ein dokumentiertes Erweiterungssystem, das es Produktteams erlaubt, ihre spezifischen Komponenten zu bauen und dabei den Kernvertrag einzuhalten. Keine totale Freiheit. Keine totale Kontrolle. Ein klarer Rahmen mit Autonomie innerhalb davon.

Was generative KI tatsächlich verändert hat

Das Versprechen lautete: Mit KI wird das Erzeugen von Komponenten sofort möglich, das Design System wird überflüssig. Die Realität, die ich beobachtet habe, ist interessanter und weniger dramatisch.

Generative KI hat das Erstellen von Komponentenvarianten und Prototypen beschleunigt. Aber sie hat das vorgelagerte Problem nicht gelöst – und konnte es nicht lösen: zu entscheiden, welche Komponenten existieren, was sie tun, welche Muster sie fördern und welche sie ausschließen, wie sie sich im Fehlerfall verhalten, welche Barrierefreiheitsanforderungen sie erfüllen. Das sind Governance-Entscheidungen, die organisatorischen Kontext erfordern, den ein generatives Modell nicht hat.

Was ich bei Teams beobachtet habe, die generative KI ohne Design System einführen: Die Geschwindigkeit der Komponentenproduktion steigt, aber ebenso die Divergenz. Jeder Entwickler erzeugt seine eigene, leicht abweichende Modal-Komponente. Die visuelle Konsistenz nimmt ab. Technische Schulden wachsen still. Und sechs Monate später muss jemand wie ich ein Audit durchführen, um die Ordnung wiederherzustellen.

Paradoxerweise hat generative KI das Design System notwendiger gemacht, nicht weniger notwendig. Denn ohne eine maßgebliche Referenzspezifikation erzeugt schnelle Generierung schnell Divergenz.

Das Design System im Jahr 2025: kleinere Fläche, stärkere Tokens

Das Enterprise-Design-System, das ich heute baue, ist strukturell anders als das, was ich 2018 gebaut habe. Nicht weil sich die Philosophie geändert hat, sondern weil ich gelernt habe, wo ich Investitionen bündeln muss, um den Ertrag zu maximieren.

Die Fläche des Systems ist kleiner. Weniger Komponenten, aber besser dokumentiert und stabiler. Die Regel, die ich anwende: Eine Komponente kommt erst dann ins System, wenn sie in mindestens drei verschiedenen Produkten oder Kontexten vorkommt. Bis dahin lebt sie als lokale Lösung. Das senkt den Wartungsaufwand drastisch und hebt die durchschnittliche Qualität der Komponenten im System.

Semantische Tokens sind der Kern. Nicht color-blue-500, sondern color-action-primary, color-feedback-error, color-surface-elevated. Tokens, die semantische Entscheidungen kodieren, keine visuellen Werte. Wenn sich die Marke ändert – und das tut sie immer –, werden die zugrunde liegenden Werte aktualisiert, nicht das System neu geschrieben. Bei Tarvos habe ich diesen Ansatz verwendet, und die Migration zum dunklen Theme dauerte zwei Arbeitstage statt drei Wochen.

Die Dokumentation lebt im Code, nicht in Notion. Nicht weil Notion das falsche Werkzeug ist, sondern weil Dokumentation, die von der Quelle der Wahrheit getrennt ist, immer veraltet. Komponenten werden über Storybook mit Argumenten, Anwendungsfällen und Barrierefreiheitsverhalten dokumentiert. Wenn sich die Komponente ändert, ändert sich die Dokumentation mit – weil es dieselbe Datei ist.

Eine Komponente kommt erst dann ins System, wenn sie in mindestens drei verschiedenen Produkten vorkommt. Bis dahin lebt sie als lokale Lösung.

Governance: das Einzige, was wirklich zählt

Das Wichtigste habe ich mir für den Schluss aufgehoben, weil es am mühsamsten zu lesen und am entscheidendsten richtig zu machen ist. Die Governance eines Design Systems beantwortet vier Fragen, und wenn Sie nicht alle vier beantwortet haben, bevor Sie mit dem Bau beginnen, wird das System unabhängig von seiner technischen Qualität scheitern.

Wem gehört das System? Nicht einem generischen Team – einer bestimmten Person, die reagiert, wenn eine Komponente an einem Donnerstag um 23 Uhr einen kritischen Fehler hat. In den Organisationen, in denen ich Design Systems am längsten habe überleben sehen, gibt es immer eine Person mit klarer Verantwortung, auch wenn die Arbeit verteilt ist.

Wie werden Entscheidungen getroffen, wenn das System mit einem Produktbedarf kollidiert? Sie brauchen einen dokumentierten Prozess, keine Einzelfalldiskussion. Die Antwort kann ein Gremium sein, ein asynchroner Prozess auf GitHub oder eine einfache Regel („Das System gewinnt immer bei Layout und Typografie, das Produkt gewinnt bei spezifischen Abläufen“). Was nicht funktioniert, ist, keine Antwort zu haben.

Wie wird die Übernahme gemessen? Wenn Sie nicht messen, wissen Sie nicht, ob das System genutzt oder umgangen wird. Die Kennzahlen, die ich verwende: Komponentenabdeckung (wie viele Oberflächen Systemkomponenten im Vergleich zu individuellen nutzen), durchschnittliche Implementierungszeit für ein neues Feature im Vergleich zum Referenzwert vor dem System, Anzahl visueller Abweichungen, die in Design-Reviews gemeldet werden. Es sind keine perfekten Kennzahlen, aber sie sind besser als nichts.

Wie wird das System aktualisiert, ohne Produkte zu beschädigen? Semantische Versionierung für Komponentenbibliotheken ist nicht bloß ein technisches Detail – sie ist ein Versprechen an die Produktteams, dass sie kontrolliert aktualisieren können. Wenn jedes Update ohne Vorwarnung etwas kaputt zu machen droht, wird das System aus Angst eingefroren und dann aufgegeben.

Wohin die Reise geht

Die nächste Veränderung, die ich kommen sehe, ist der Einsatz von KI zur automatischen Konsistenzprüfung: Tools, die Screenshots aus der Produktion analysieren und erkennen, wo Komponenten vom Design System abweichen, ohne dass ein manuelles Review nötig ist. Technisch ist das bereits möglich – einige Teams experimentieren mit Ansätzen auf Basis von Vision-Modellen und automatisierten visuellen Tests. Es ist noch kein Branchenstandard, wird es aber werden.

Der andere Trend, den ich sehe, ist die Kodierung von Designentscheidungen direkt in Tokens, nicht nur von Werten. Tokens, die Metadaten über den Nutzungskontext, Kontrastanforderungen und Barrierefreiheitsvorgaben tragen. Ein Token ist nicht nur eine Farbe – es ist eine Farbe mit ihren Regeln. Das macht das System intelligenter und schwerer aus Nachlässigkeit falsch zu verwenden.

Das Design System ist nicht tot. Es hat sich weiterentwickelt, wie es das immer getan hat. Und diejenigen, die die verfrühte Beerdigung ausgerufen haben, arbeiten jetzt mit Teams, die drei Jahre visueller Konsistenz verloren haben und gezwungen sind, von Grund auf neu aufzubauen, was sie im Trend-Eifer abgebaut haben.