Die drei Modelle und ihre realen Kosten
Jede Auseinandersetzung mit diesem Thema landet bei denselben drei Modellen. Sie sind grundverschieden und die Wahl ist entscheidend, aber die Darstellung verschleiert, dass alle drei nur eine der drei Governance-Fragen beantworten.
| Funktionsweise | Kosten | |
|---|---|---|
| Zentralisiert | Ein dediziertes Team besitzt das System. Produktteams nutzen es und beantragen Änderungen. | Das Team wird zum Flaschenhals; Produktteams umgehen es unter Zeitdruck. Die Qualität ist hoch, das Risiko liegt in der Adoption. |
| Föderiert | Mitwirkende aus verschiedenen Produktteams besitzen Teile des Systems auf Basis gemeinsamer Standards. | Die Kohärenz schwindet. Niemand besitzt das Ganze, sodass die Teile driften, ohne dass eine einzelne Person dies bemerkt. |
| Hybrid | Ein kleines Kernteam verantwortet die Foundations und das Review; Produktteams steuern Komponenten bei. | Die häufigste Antwort und die am schwersten beizubehaltende. Sie funktioniert nur so gut, wie die Grenze zwischen Kern und Beiträgen definiert ist. |
Hybrid ist meist die richtige Wahl, und das Scheitern liegt nicht am Modell. Es scheitert, wenn nicht schriftlich fixiert wurde, was in den Kern gehört. Dann wird jeder Beitrag zur Verhandlung und der Kern absorbiert Dinge, die dort nicht hingehören.
Die Frage, die die Modelle nicht beantworten
Die Contribution-Governance entscheidet, wie sich das System ändert. Die Compliance-Governance entscheidet, ob sich überhaupt jemand daran hält. Letztere ist der Punkt, an dem Systeme sterben, wird aber kaum diskutiert, da sie wenig glamourös ist.
Das Symptom ist bekannt: Ein gut gewartetes Designsystem, ein aktiver Contribution-Prozess und eine Codebasis mit vierhundert hardcodierten Hex-Werten. Niemand hat absichtlich gegen eine Regel verstoßen. Es war Freitag, der Token passte nicht ganz und ein Hex-Wert war schneller eingetippt als ein Gespräch – dreihundert Mal hintereinander.
Niemand hat das System absichtlich verletzt. Einen einzelnen Wert hardzucodieren war dreihundert Mal schneller als ein Gespräch.
Es gibt genau drei Durchsetzungsmechanismen, und nur einer davon ist kostenlos:
| Mechanismus | Kosten | Effektivität | |
|---|---|---|---|
| Dokumentation | Das Richtige dokumentieren | Kostenlos | In etwa so effektiv wie kostenlos |
| Linting | Verstöße im Editor markieren und in der CI als Fehler ausgeben | Echte Tooling-Investition, plus ein Regelwerk, das parallel zum System gepflegt wird | Hoch. Der Großteil des Ertrags aus Governance-Aufwand liegt hier |
| Die Möglichkeit entziehen | Das Falsche unmöglich zu formulieren machen | Jeder echte neue Bedarf wird zu einer Anfrage an die Systembesitzer | Gesamt, innerhalb der abgedeckten Grenzen |
Beide effektiven Zeilen haben bereits veröffentlichte Präzedenzfälle, die es wert sind, untersucht zu werden. Salesforce's SLDS 2 liefert einen Linter und einen Validator aus, die Markup gegen eine Regeldatenbank prüfen und Korrekturen empfehlen: die mittlere Zeile, in Enterprise-Größe. Stripes App UI Toolkit verfolgt den Ansatz der unteren Zeile: Die css-Prop akzeptiert ausschließlich benannte Tokens, mehrere Komponenten lehnen Overrides komplett ab und Constraints für die Komponentenhierarchie schränken ein, welche Elemente was enthalten dürfen.
Wenn Sie nur eines tun können, fügen Sie einen einzelnen CI-Check hinzu, der bei einem wörtlichen Farbwert außerhalb Ihrer Token-Datei fehlschlägt. Das dauert einen Nachmittag und stoppt die häufigste Form von Drift dauerhaft. Alles andere in der Governance ist verhandelbar; das hier ist es nicht.
Die untere Zeile ist nur auf Oberflächen verfügbar, die Sie kontrollieren. Stripe kann die Möglichkeit innerhalb seines eigenen Dashboards entziehen, aber nicht innerhalb Ihres Checkouts, weshalb es dort stattdessen eine Anpassungsleiter bereitstellt. Die Haltung folgt der Grenze, nicht der Präferenz.
Wenn ein Governance-Problem ein strukturelles Problem ist
Die nützlichste öffentlich geteilte Governance-Lektion ist eine, die ein Team über seinen eigenen Fehler veröffentlicht hat, und sie hat überhaupt nichts mit Regeln zu tun.
Spotify's Encore startete mit einem bewusst flexiblen mobilen Subsystem. Produktteams fragten immer spezifischere Komponenten ab, und das System sagte immer wieder Ja. Bis 2022 kam das Team zu dem Schluss, dass das Pendel zu weit in Richtung Flexibilität ausgeschlagen hatte und eine Neukalibrierung erforderlich war.
Die offensichtliche Governance-Reaktion wäre gewesen, den Prozess zu verschärfen: strengere Akzeptanzkriterien, eine höhere Hürde für neue Komponenten, mehr Reviews. Sie haben etwas anderes getan. Sie haben eine neue Ebene zwischen dem flexiblen Subsystem und dem Fundament aufgebaut, beschrieben als eine erste Verteidigungslinie, die den Bedarf an dem spezialisierten Subsystem reduziert und gleichzeitig die Plattform-Parität erhöht.
Das definiert ein Governance-Problem als Architekturproblem um, und diese Neudefinition generalisiert. Wenn ein Teil eines Systems in Anfragen versinkt, sind die Anfragen meist nicht spezifisch für diesen Teil. Es fehlt eine gemeinsame Ebene darunter. Das Ablehnen der Anfragen treibt Teams dazu, außerhalb des Systems zu bauen, wo man den Überblick über die Arbeit komplett verliert. Das Hinzufügen der Ebene erfasst sie.
| Sieht aus wie | Ist meistens | |
|---|---|---|
| Ständige Anfragen nach neuen Komponenten | Mitwirkende, die den Prozess nicht respektieren | Eine fehlende gemeinsame Ebene zwischen dem Kern und dem spezialisierten Subsystem |
| Teams, die außerhalb des Systems bauen | Mangelnde Disziplin bei der Anwendung | Das System sagt schneller Nein als Ja |
| Sich vervielfältigende Komponenten-Tokens | Nachlässige Beiträge | Der semantischen Ebene fehlt etwas, das jeder benötigt |
| Regeln, die ständig Ausnahmen erfordern | Regeln, die ignoriert werden | Eine Regel, die zwei Oberflächen abdeckt, die sich legitim unterscheiden |
Die letzte Zeile ist einer spezifischen Prüfung wert. Eine Regel mit einem Vorbehalt („großzügiger Abstand, obwohl Tabellen dichter sein können“) sind zwei Regeln, die so tun, als wären sie eine. Jede Ausnahmeanfrage dagegen ist korrekt, und keine Menge an Governance behebt das.
Was sich ändert, wenn der Mitwirkende ein Modell ist
Governance-Frameworks setzen einen Rhythmus voraus: Eine Person schlägt eine Änderung vor, eine Person prüft sie, der Takt wird durch den menschlichen Durchsatz begrenzt. Diese Annahme ist nicht länger sicher.
Ein Agent schreibt zwischen zwei Reviews vierzig Screens. Er hat über verschiedene Sessions hinweg kein Gedächtnis für Ihre Konventionen, keinen Anreiz, Abkürzungen zu nehmen, und keine Möglichkeit, einen Kollegen zu fragen, welches Grau das richtige ist. Daraus ergeben sich zwei Konsequenzen, die in entgegengesetzte Richtungen ziehen.
| Effekt | |
|---|---|
| Contribution-Prozess | Geringere Last. Agenten schlagen selten Änderungen am System selbst vor: Sie konsumieren es. |
| Compliance-Durchsetzung | Viel höhere Last. Das Volumen des gegen das System geschriebenen Codes ist gestiegen; die Review-Kapazität hingegen nicht. |
| Mehrdeutigkeit im System | Weitaus kostspieliger. Ein Mensch, der unsicher ist, welchen Token er verwenden soll, fragt nach; ein Modell wählt stillschweigend in jeder Datei aus. |
| Undokumentierte Konvention | Wertlos. Alles, was nur in den Köpfen von Menschen existiert, ist nun schlichtweg nicht vorhanden. |
Die letzte Zeile beschreibt die drastischste Änderung. Die meisten Designsysteme bestanden schon immer teils aus Dokumentation und teils aus Folklore – und die Folklore funktionierte, weil ein Entwickler, der die zehn vorherigen Screens gesehen hatte, sie aufnahm. Dieser Übertragungsmechanismus existiert für einen Agenten nicht. Jede ungeschriebene Konvention wird somit zu einer Lücke, die das Modell aus seinen Trainingsdaten füllt.
Wir haben 299 DESIGN.md-Dateien analysiert, die speziell geschrieben wurden, um diese Lücke zu schließen. 76 % enthalten keinerlei Verbote, 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 69 % definieren keinen Dark Mode und 44 % nennen an keiner Stelle einen konkreten Größenwert. Das sind Governance-Dokumente, die nichts steuern – und im Gegensatz zu einem Wiki, das niemand liest, wird dieses Dokument bei jeder einzelnen Anfrage gelesen.
Identity Forge Design-Kits sind in diesem Sinne das gesteuerte Artefakt: semantische Farbrollen für Light- und Dark-Mode, Typografie- und Spacing-Skalen, Motive sowie eine explizite Liste mit Do's und Don'ts, serialisiert in einer DESIGN.md, die jeder Agent vor dem Schreiben liest. Kits durchsuchen oder lesen Sie, wie man ein System für KI dokumentiert.
Minimum Viable Governance
Die meisten veröffentlichten Ratschläge zur Governance setzen ein dediziertes Platform-Team voraus, über das die meisten Teams nicht verfügen. So sieht dieselbe Aufgabe ohne ein solches Team aus.
- 1
Festlegen, was zum Core gehört
Ein Absatz. Was niemals überschrieben werden darf (Farbrollen, Typografie-Skala, Spacing-Skala, Verbote) und was pro Oberfläche variieren darf. Die meisten Diskussionen über Contributions sind eigentlich Diskussionen über diese Grenze, ohne dass sie jemals explizit benannt wird.
- 2
Einen CI-Check hinzufügen
Lassen Sie den Build fehlschlagen, wenn ein literaler Farbwert außerhalb der Token-Datei verwendet wird. Dieser eine Check bewirkt mehr als ein kompletter Contribution-Prozess und kostet nur einen Nachmittag.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' && exit 1 || exit 0 - 3
Einen Owner benennen, kein Komitee
Jemand, der innerhalb eines Tages „Ja“ sagen kann. Ein System, das zwei Wochen braucht, um eine Änderung zu genehmigen, wird von Teams umgangen – und dieses Umgehen ist irreversibel. Die Arbeit findet außerhalb statt, wo Sie sie nicht sehen können.
- 4
Review nach Oberfläche, nicht nach Komponente
Öffnen Sie einmal im Quartal drei Screens derselben Oberfläche nebeneinander. Drift ist pro Datei unsichtbar, im Vergleich jedoch offensichtlich. Deshalb wird er bei Reviews auf Pull-Request-Ebene nie entdeckt.
- 5
Ausnahmeanträge als Systemdefekte tracken
Jeder Antrag auf eine Ausnahme ist ein Beleg dafür, dass eine Regel zwei unterschiedliche Fälle abdeckt oder dass in der semantischen Ebene etwas fehlt. Bearbeiten Sie den Antrag und beheben Sie dann die Ursache. Eine Regel, die drei Ausnahmen benötigt, wurde falsch geschrieben.
Schritt vier ist der, den Teams auslassen, obwohl er die meisten Fehler aufdeckt. Das Review eines Pull-Requests sagt Ihnen, ob diese Datei in sich konsistent ist. Nur der Vergleich fertiger Screens zeigt Ihnen, ob das Produkt in sich konsistent ist – und genau das ist es, was das System schützen soll.
Was ist Designsystem-Governance?
Die Regeln darüber, wer das System ändern darf, wie Contributions vorgeschlagen und akzeptiert werden und wie die Compliance durchgesetzt wird. Die meisten Diskussionen behandeln die ersten beiden Punkte gründlich und den dritten kaum – was bedauerlich ist, da Systeme meist am dritten Punkt scheitern.
Was ist der Unterschied zwischen zentralisierter und föderierter Governance?
Zentralisiert bedeutet, dass ein dediziertes Team das System besitzt und Produktteams Änderungen beantragen: hohe Qualität, aber Risiko eines Flaschenhalses. Föderiert bedeutet, dass Contributor über verschiedene Teams hinweg Teile unter gemeinsamen Standards besitzen: besserer Durchsatz, aber Risiko einer Erosion der Kohärenz. Hybrid teilt dies auf: Ein Core-Team besitzt die Foundations und das Review, Produktteams steuern Komponenten bei.
Wie bringe ich Teams dazu, das Designsystem tatsächlich zu befolgen?
Mechanisch. Ein Linter, der Verstöße im Editor markiert und in der CI zum Fehlschlagen bringt, bewirkt mehr als jede Dokumentation. Noch stärker ist es, die Möglichkeit zur Abweichung zu entfernen (z. B. eine Styling-API, die nur Tokens zulässt), sofern Sie die Kontrolle über die Oberfläche haben. Dokumentation allein hat fast keinen Wert für die Durchsetzung.
Mein Designsystem-Team ist mit Anfragen überlastet. Sollten wir öfter Nein sagen?
Prüfen Sie zunächst, ob eine Ebene fehlt. Spotify hatte dieses Problem mit Encore und fügte eine gemeinsame Ebene zwischen dem flexiblen Subsystem und dem Foundation-Layer hinzu, anstatt die Annahmekriterien zu verschärfen, da die Anfragen nicht spezifisch für dieses Subsystem waren. Das Ablehnen von Anfragen drängt Teams dazu, außerhalb des Systems zu entwickeln, wodurch die Arbeit unsichtbar wird.
Ändert sich die Governance, wenn KI den Großteil der UI schreibt?
Das Gleichgewicht verschiebt sich drastisch. Agents schlagen selten Änderungen am System vor, wodurch die Last bei den Beiträgen sinkt. Gleichzeitig steigt das Volumen des geschriebenen Codes, ohne dass die Review-Kapazitäten mitwachsen, was die Last bei der Durchsetzung erhöht. Auch Mehrdeutigkeiten werden kostspieliger: Eine Person, die unsicher ist, welchen Token sie verwenden soll, fragt nach – ein Modell hingegen wählt stillschweigend in jeder Datei, die es bearbeitet.