„Unser Design-System ist technisch super, aber niemand nutzt es richtig." Eine Aussage, die in vielen Unternehmen zu hören ist.

Die Komponenten funktionieren, die Tokens sind sauber strukturiert, die Dokumentation ist vollständig. Und trotzdem: Das System dümpelt vor sich hin.

Der Grund ist meist nicht technischer Natur. Es liegt an den Menschen, Prozessen und Strukturen drumherum. An der Governance.

Governance klingt erst mal nach Bürokratie, nach endlosen Meetings und Freigabeschleifen und das kann es auch sein. Muss es aber nicht.

Zeit für eine andere Sicht auf das Thema.

Das Governance-Paradox: Alle reden darüber, keiner will es machen

Design-Systeme sind soziale Systeme. Sie funktionieren nur, wenn Menschen sie verwenden, pflegen und weiterentwickeln. Doch genau hier liegt das Problem: Während alle über die Wichtigkeit von Governance sprechen, will sie kaum jemand aktiv gestalten. Aber warum ist das so?

Governance wird oft mit Kontrolle und Gatekeeper-Mentalität gleichgesetzt. Mit „Das geht so nicht, weil..." statt „Wie können wir das möglich machen?" Dabei ist gute Governance genau das Gegenteil: Sie schafft Klarheit, reduziert Reibung und ermöglicht autonomes Arbeiten. Sie ist der Unterschied zwischen einem System, das genutzt wird, und einem, das in der Schublade verstaubt.

Aufbauend auf dem „Governance Light"-Ansatz aus dem vorangegangenen Artikel geht es darum, die richtige Balance zu finden: Struktur ohne Starrheit, Richtung ohne Bevormundung.

1. Rollen und Verantwortlichkeiten: Wer macht was?

Ein Design-System ohne klare Rollen ist wie ein Orchester ohne Dirigent. Es kann funktionieren, wird aber selten harmonisch klingen, geschweige denn mitreißen.

Typische Rollen im Systembetrieb sind Maintainer (die Struktur, Qualität und Roadmap verantworten), Contributors (die neue Komponenten oder Anpassungen liefern) sowie DesignOps/System Owner (die Prozesse koordinieren, priorisieren und zwischen Teams moderieren)

Wichtig: Diese Rollen müssen keine Vollzeitrollen sein. Sie können verteilt oder rotierend organisiert werden. Entscheidend ist, dass klar ist, wer wofür zuständig ist. Schauen wir uns das im Detail an:

Core Maintainer: Das Rückgrat des Systems

• Strategische Richtung und Vision des Systems
• Qualitätssicherung und finale Entscheidungen bei Konflikten
• Release-Management und Breaking Changes
• Dokumentation und Standards pflegen

Typische Besetzung: 1–3 Personen, je nach Systemgröße. Oft eine Mischung aus Senior Designer:in und Tech Lead.
Wichtig: Maintainer sind keine Diktatoren. Sie moderieren und entscheiden, aber das System lebt vom Input aller.

Contributors: Die Gestalter der Evolution

• Neue Komponenten vorschlagen und entwickeln
• Bestehende Patterns erweitern oder verbessern
• Feedback aus Produktteams sammeln und weiterleiten
• Dokumentation und Beispiele ergänzen

Typische Besetzung: Produktdesigner:innen, Frontend-Entwickler:innen – alle, die aktiv mit dem System arbeiten.

Governance-Modelle reichen hier von Open Contribution, bei dem jeder Pull Requests stellen und Maintainer reviewen kann, über Nominated Contributors mit erweiterten Rechten bis hin zu Team‑based‑Ansätzen, bei denen Produktteams Vertreter:innen für das System nominieren.

DesignOps/System Owner: Die Prozess‑Enabler

• Prozesse koordinieren und optimieren
• Prioritäten setzen und Roadmap pflegen
• Entscheidungen moderieren
• Zwischen Teams vermitteln und Konflikte lösen
• System‑Adoption fördern und Hindernisse identifizieren
• Metriken sammeln und System‑Gesundheit überwachen

Typische Besetzung: Design‑Ops‑Spezialist:innen, erfahrene Product Manager oder Senior Designer:innen mit organisatorischem Fokus. Oft eine hybride Rolle aus strategischem und operativem Denken.

Consumers: Die eigentlichen Nutzer

• System korrekt verwenden und Feedback geben
• Bugs und Inkonsistenzen melden
• Best Practices in ihren Teams etablieren
• Bei größeren Änderungen Impact‑Assessment liefern

Typische Besetzung: Alle Produktteams, die das Design-System nutzen, also Designer:innen, Entwickler:innen, Product Manager, aber auch QA‑Teams oder Content‑Ersteller.
Das wird oft vergessen: Consumer haben auch Pflichten. Ein System funktioniert nur, wenn es richtig verwendet wird.

2. Feedback‑ und Entscheidungsprozesse: Struktur ohne Bürokratie

Change Requests: Von der Idee zur Implementierung

Ein leichtgewichtiger Prozess führt neue Ideen strukturiert vom Vorschlag zur Umsetzung: Zunächst wird die Idee strukturiert dokumentiert (Problem, Lösungsvorschlag, betroffene Teams), gefolgt von einer offenen Diskussion mit Stakeholdern und einem Feasibility-Check.

Maintainer entscheiden dann basierend auf transparenten Kriterien, ob der Vorschlag umgesetzt wird, bevor die Umsetzung durch Contributors oder Maintainer erfolgt und schließlich die Integration ins System mit entsprechender Dokumentation stattfindet.

Die Entscheidungskriterien sollten dabei transparent kommuniziert werden:

• Löst der Vorschlag ein wiederkehrendes Problem mehrerer Teams?
• Ist er mit bestehenden Patterns konsistent?
• Rechtfertigt der Nutzen den Pflegeaufwand?
• Gibt es bereits ähnliche Lösungen im System?

Gremienmodelle: Von minimal bis formal

Das Spektrum der Entscheidungsstrukturen ist breit und sollte zur jeweiligen Organisation passen. Kleinere Teams fahren oft gut mit wöchentlichen Office Hours, asynchronen Entscheidungen über Slack oder GitHub und quartalsweisen Retrospektiven.

Mittlere Unternehmen etablieren häufig monatliche Design-System Guilds mit Vertretern aller Produktteams, kombiniert mit schnellen Entscheidungsrunden für kleinere Changes und strukturiertem Decision Making für größere Änderungen.

Große Organisationen benötigen meist formellere Strukturen: Design-System Boards mit definierten Rollen, formalisierte Prozesse mit klaren Timelines und separate Working Groups für spezifische Themenbereiche.

Entscheidend ist: Das Modell muss zur Organisation passen, nicht umgekehrt.

3. Rituale & Metriken: Lebenszeichen eines gesunden Systems

Governance braucht nicht nur Rollen, sondern auch Rhythmus. Verlässliche Rituale helfen, das System lebendig zu halten.
Einige Beispiele aus der Praxis:

• System‑Check‑ins: z. B. alle 2 Wochen, Austausch über neue Bedarfe, Status‑Updates, offene Fragen
• Review‑Runden: Vorschläge bewerten, priorisieren oder ablehnen
• Contribution‑Days: feste Zeiträume, in denen bewusst am System gearbeitet wird
• Show & Tell Sessions: informelle Formate, um neue Patterns, Tools oder Learnings zu teilen
• Change Communication: regelmäßige Updates über Systemänderungen und neue Features via Newsletter, Teams‑Channel oder Release Notes

Solche Rituale senken die Hürde zur Beteiligung und geben dem System einen Platz im Teamalltag.

Metriken: Was gemessen wird, sollte Wirkung haben

Metriken sind wie Werkzeuge: Mit einem Schraubenzieher schlägt man keine Nägel ein. Genauso gilt: Die richtige Metrik für das richtige Problem und vor allem: Messe nur, was du auch ändern willst. Daten ohne Handlungskonsequenzen sind verschwendete Zeit.
Einige Metriken-Typen im Überblick:

• Adoption‑Metriken - wenn das System zu wenig genutzt wird: Hier helfen Messungen wie der Anteil der Komponenten aus dem System vs. Custom-Komponenten, die Anzahl der Teams, die das System aktiv nutzen, oder Download/Import-Zahlen der System-Bibliothek.
• Konsistenz‑Metriken - wenn Wildwuchs trotz System entsteht: Relevant sind dann die Anzahl der Farben, Schriftgrößen oder Abstände außerhalb des Systems, Konsistenz-Scores bei Design-Reviews oder die Häufigkeit von „One-off"-Lösungen.
• Effizienz‑Metriken - wenn das System bremst statt beschleunigt: Hier sollten Time-to-delivery für Standardkomponenten, reduzierte Design- und Entwicklungszeit bei neuen Features oder weniger Iterationen bei Design-Handoffs gemessen werden.
• Qualitäts‑Metriken - wenn System-Komponenten nicht richtig funktionieren: Dann sind Accessibility-Compliance-Rate, Bug-Reports pro Komponente oder Performance-Impact der System-Komponenten die richtigen Messwerte.

Die entscheidende Frage: Welche Probleme möchten wir mit den Daten besser verstehen und lösen? Eine Metrik ist nur so gut wie die Entscheidung, die sie vorbereitet.

4. Governance als Enabler: Struktur, die befreit

Gute Governance fühlt sich nicht wie Governance an. Sie schafft Klarheit, wo vorher Unsicherheit war, und gibt Orientierung, wo vorher Ratlosigkeit herrschte.

Ein System, das niemand kennt, kann auch niemand nutzen. Kommunikation ist deshalb nicht Kür, sondern Pflicht.

Sie beginnt bei der Transparenz von Entscheidungen, etwa durch nachvollziehbare Begründungen für abgelehnte Vorschläge, und reicht bis zu strukturierten Update-Mechanismen über Slack, Changelog oder Tool-Integrationen.

Wichtig ist auch, das System wie ein Produkt zu behandeln: mit einer klaren Stimme, die ansprechbar ist, Rückmeldung gibt und sich weiterentwickelt.

Konkret heißt das:

• Eskalationswege etablieren: „Wenn ihr nicht wisst, ob euer Pattern ins System gehört, fragt im Channel #design-system-help. Antwort binnen 24h garantiert.“
• Entscheidungen transparent machen: Jede Ablehnung kommt mit Begründung und Alternativen, jede Aufnahme wird dokumentiert und kommuniziert.
• Standards flexibel gestalten: „Wenn du vom System abweichen musst, dokumentiere warum. Das hilft uns, das System zu verbessern.“

Das Ziel: Autonomie mit Leitplanken. Teams können eigenständig arbeiten, wissen aber, wann und wie sie sich abstimmen sollten.

Fazit: Menschen machen Systeme erfolgreich

Das beste Design-System der Welt scheitert ohne die richtigen Menschen, Prozesse und Strukturen drumherum. Governance ist nicht das notwendige Übel, sondern der Erfolgsfaktor.

Ein gut geführtes System:

• Gibt Teams Sicherheit beim Experimentieren
• Macht Entscheidungen nachvollziehbar und fair
• Schafft Räume für Feedback und Evolution
• Balanciert Konsistenz mit Innovation

Governance ist kein Projekt, das man einmal macht. Es ist ein kontinuierlicher Prozess, der mit dem System mitwächst – von Governance Light bei kleinen Teams bis zu formalen Strukturen in Großkonzernen, nach dem Prinzip form follows function.

Wer sein Design-System technisch perfekt aufbaut, aber die sozialen Aspekte vernachlässigt, baut ein Monument und kein Werkzeug.

Die erfolgreichsten Design-Systeme sind nicht die technisch ausgefeiltesten, sondern die, die ihre Nutzer verstehen, ihnen vertrauen und strukturierte Wege für Zusammenarbeit schaffen.

Design-Systeme sind soziale Systeme. Zeit, sie auch so zu behandeln.