Die meisten Organisationen behandeln ihr Design System als Deliverable des Design-Teams. Das Design-Team erstellt Komponenten in Figma, dokumentiert die Nutzungsleitlinien, übergibt sie ans Engineering und hofft das Beste. Sechs Monate später haben drei Teams ihren eigenen Date Picker gebaut, weil der offizielle ihren Sonderfall nicht abgedeckt hat, und die "Single Source of Truth" ist eine Quelle der Wahrheit, der niemand vertraut.

Das Problem liegt nicht beim Design-Team. Das Problem ist, dass ein Design System im Enterprise-Massstab Infrastruktur ist. Es braucht dasselbe architektonische Denken, dieselbe Governance und dasselbe Ownership-Modell, das man auf ein API-Gateway, eine CI-Pipeline oder eine Deployment-Plattform anwenden würde. Behandelt man es als weniger, ist Fragmentierung garantiert.

Warum Design Systems in grossem Massstab scheitern

Ein Design System, das für 20 Entwickler funktioniert, bricht bei 200. Die Gründe sind strukturell.

Kein klares Ownership-Modell. Wenn eine Komponente geändert werden muss, wer entscheidet? In kleinen Teams ist die Antwort offensichtlich: jemand geht rüber und spricht mit der Person, die sie gebaut hat. Im grossen Massstab betreffen Komponentenänderungen Dutzende von Teams. Ohne ein Governance-Modell passieren Änderungen entweder nicht (weil niemand das Risiko eingehen will, andere Teams zu beeinflussen) oder sie passieren eigenmächtig (weil das Team, das die Änderung braucht, nicht warten möchte).

Einheitskomponenten für alle Fälle. Enterprise-Plattformen bedienen unterschiedliche Nutzertypen, unterschiedliche Märkte und unterschiedliche Kontexte. Eine Button-Komponente, die für einen verbraucherorientierten Checkout-Flow funktioniert, hat andere Anforderungen als eine in einer industriellen Steuerungsschnittstelle. Wenn das Design System diese Variation nicht aufnehmen kann, forken Teams die Komponenten. Jeder Fork divergiert. Das System fragmentiert.

Keine Versionierungsstrategie. Breaking Changes an einer gemeinsamen Komponente wirken sich auf jedes Team aus, das sie nutzt. Ohne Versionierung haben Teams die Wahl: sofort aktualisieren und Regressionen riskieren, oder bei der alten Version bleiben und weiter vom System abdriften. Beide Optionen sind schlecht. Eine saubere Versionierungsstrategie mit klaren Deprecation-Fristen und Migrations-Support ist das, was ein Design System im grossen Massstab nutzbar macht.

Ich habe an Deutsche Telecoms Magenta View CRM gearbeitet, wo 200+ Entwickler auf europäischen Märkten von einer gemeinsamen Komponentenbibliothek abhingen. Die Pattern Library war nicht nur eine Sammlung von UI-Komponenten. Sie war ein Governance-System, das bestimmte, wie schnell Teams ausliefern konnten und wie konsistent das Produkt über Märkte hinweg blieb.

Design Systems als Architekturentscheidungen

Ein Design System ist ein Satz von Architekturentscheidungen darüber, wie Ihre Benutzeroberfläche strukturiert, zusammengesetzt und gepflegt wird. Jede Entscheidung hat Kompromisse, die die Entwickler-Velocity, die Produktkonsistenz und die langfristige Wartbarkeit beeinflussen.

Komponentengrenzen. Wo endet eine Komponente und beginnt eine andere? Das ist dieselbe Frage wie die nach Modulgrenzen bei der Backend-Modularisierung. Grenzen zu weit ziehen und Komponenten werden zu starren Monolithen, die sich nicht anpassen können. Grenzen zu eng ziehen und Teams verbringen ihre Zeit damit, Dutzende von Primitiven zu kombinieren, anstatt Features zu bauen.

Anpassung versus Konsistenz. Wie weit können Teams eine Komponente anpassen, bevor sie aufhört, Teil des Systems zu sein? Das ist ein Spektrum, keine Binärwahl. Manche Komponenten (Buttons, Formularfelder, Typografie) brauchen strikte Konsistenz. Andere (Seitenlayouts, Datenvisualisierung) brauchen Flexibilität. Die Architektur sollte diese Unterscheidung ausdrücken, nicht der Konvention überlassen.

State Management. Wo lebt der Komponenten-State? Wer verwaltet ihn? In einer formularintensiven Enterprise-Applikation bestimmt die Antwort auf diese Frage, ob Teams Features unabhängig bauen können oder ständig um gemeinsamen State koordinieren müssen. Auf der Siemens SIMATIC AX-Plattform war die Entkopplung des Komponenten-States eine Voraussetzung für die Microfrontend-Architektur, die die Build-Zeiten von 30 Minuten auf unter fünf reduzierte.

Kompositionsmodell. Wie passen Komponenten zusammen? Slots, Props, Render-Funktionen, Compound Components. Jeder Ansatz hat Auswirkungen auf Wiederverwendbarkeit, Testbarkeit und die Lernkurve für neue Entwickler. Das ist eine Architekturentscheidung, keine Stilpräferenz.

Governance, die skaliert

Design-System-Governance ist der Satz von Regeln, der bestimmt, wie Komponenten vorgeschlagen, gebaut, reviewt, versioniert und zurückgezogen werden. Ohne Governance ist ein Design System nur eine Komponentenbibliothek, die zufällig Dokumentation hat. Mit Governance ist es Infrastruktur, auf die sich die Organisation verlassen kann.

Ein klares Contribution-Modell. Wer kann Komponenten hinzufügen? Wer reviewt sie? Welche Kriterien muss eine Komponente erfüllen, bevor sie ins System aufgenommen wird? Die besten Contribution-Modelle, die ich gesehen habe, behandeln Design-System-Komponenten wie internes Open Source: jeder kann vorschlagen, ein Core-Team reviewt, und die Aufnahme erfordert Dokumentation, Tests und Barrierefreiheitskonformität.

Semantische Versionierung mit Migrations-Support. Jeder Breaking Change bekommt einen Major-Version-Bump, einen Migrations-Leitfaden und ein Deprecation-Fenster. Teams brauchen Zeit, Änderungen zu adoptieren. Sofortige Updates auf 200 Entwickler zu erzwingen ist der Weg zu Teams, die gar nicht mehr aktualisieren.

Nutzungsanalysen. Wissen, welche Komponenten genutzt, welche geforkt und welche ignoriert werden. Wenn eine Komponente geringe Adoption hat, erfüllt sie entweder keine echten Bedürfnisse oder Teams wissen nicht, dass sie existiert. Beides sind lösbare Probleme. Wenn eine Komponente häufig geforkt wird, bedeutet das, dass die API nicht flexibel genug ist.

Funktionsübergreifendes Review. Komponentenänderungen sollten von Design und Engineering reviewt werden. Eine Komponente, die richtig aussieht, aber schlecht performt, ist defekt. Eine Komponente, die technisch elegant ist, aber nicht zur Design-Sprache passt, ist ebenfalls defekt. Der Review-Prozess braucht beide Perspektiven.

Die Brücke zwischen Design und Engineering

Design Systems sitzen genau an der Grenze zwischen Design und Engineering, weshalb sie scheitern, wenn nur eine Seite sie verantwortet.

Design-Teams fokussieren sich auf visuelle Konsistenz, Markensprache und User Experience. Engineering-Teams fokussieren sich auf Performance, Wartbarkeit und Developer Experience. Ein Design System, das nur einer Seite dient, wird von der anderen abgelehnt. Das Design-System-Team (ob dediziertes Team oder virtuelles Team mit Vertretern beider Seiten) muss beide Sprachen sprechen.

Das habe ich über viele Aufträge hinweg immer wieder beobachtet. Die Organisationen, in denen Design Systems wirklich funktionieren, sind jene, in denen das System an der Schnittstelle der Disziplinen verantwortet wird, nicht innerhalb einer einzelnen. Die Rolle des Design-System-Architekten, ob formeller Titel oder informelle Verantwortung, braucht jemanden, der Komponenten-APIs und visuelle Hierarchie, Performance-Budgets und Abstands-Systeme, Developer Ergonomics und Barrierefreiheitsanforderungen versteht.

Worauf Sie achten sollten

Das Design System, das eigentlich ein Style Guide ist. Wenn Ihr Design System ein Satz Figma-Dateien und ein CSS-Framework ist, haben Sie einen Style Guide. Ein Design System umfasst Komponentenlogik, Verhalten, State Management und Interaktionsmuster. Die visuelle Ebene ist der sichtbarste Teil, aber nicht der wichtigste.

Für Vollständigkeit statt Nutzung bauen. Bauen Sie keine 80 Komponenten, wenn Ihre Teams 15 nutzen. Beginnen Sie mit den Komponenten, die jedes Team braucht: Typografie, Layout, Buttons, Formularsteuerelemente, Navigation. Fügen Sie Komplexität hinzu, wenn Teams sie anfragen. Ein kleines, zuverlässiges System ist besser als ein umfassendes, unzuverlässiges.

Das Adoptionsproblem ignorieren. Ein Design System, das existiert, aber nicht genutzt wird, ist schlimmer als gar keines. Es erzeugt die Illusion von Konsistenz, während Teams ihre eigenen Lösungen bauen. Adoption ist ein Produktproblem: Sie brauchen Dokumentation, Beispiele, Migrations-Tools und einen Support-Kanal. Behandeln Sie Ihr Design System wie ein internes Produkt mit Ihren Entwicklern als Nutzer.

Die besten Design Systems, mit denen ich gearbeitet habe, wurden von Anfang an als Infrastruktur behandelt. Sie hatten dedizierte Ownership, Versionskontrolle, CI-Pipelines, Release-Prozesse und funktionsübergreifende Governance. Sie waren Architekturentscheidungen, keine Deliverables. Wenn Sie ein Design System als etwas behandeln, das das Design-Team ans Engineering übergibt, bricht es. Wenn Sie es als gemeinsame Infrastruktur behandeln, die beide Seiten besitzen, skaliert es.