Die drei Modelle und ihre realen Kosten
Jede Behandlung dieses Themas landet bei denselben drei Grundformen. Sie sind tatsächlich unterschiedlich 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 konsumieren es und fordern Änderungen an. | Das Team wird zum Flaschenhals, und Produktteams umgehen es unter Zeitdruck. Die Qualität ist hoch; die Adoption ist das Risiko. |
| Föderiert | Mitwirkende aus verschiedenen Produktteams besitzen Teile des Systems anhand gemeinsamer Standards. | Die Kohärenz schwindet. Niemand besitzt das Ganze, also driften die Teile ab, ohne dass eine einzelne Person dies bemerkt. |
| Hybrid | Ein kleines Kernteam besitzt die Grundlagen und übernimmt das Review; Produktteams tragen Komponenten bei. | Die häufigste Antwort und die am schwersten aufrechtzuerhaltende. Sie funktioniert nur so gut, wie die Grenze zwischen Kern und Beiträgen definiert ist. |
Hybrid ist meist der richtige Weg, und der Grund für das Scheitern ist nicht das Modell. Es scheitert, wenn niemand aufgeschrieben hat, was in den Kern gehört, sodass jede Contribution zur Verhandlung wird und der Kern Dinge aufnimmt, die er nicht enthalten sollte.
Die Frage, die die Modelle nicht beantworten
Die Contribution-Governance entscheidet, wie sich das System verändert. Die Compliance-Governance entscheidet, ob sich jemand daran hält. Letztere ist der Punkt, an dem Systeme sterben, und sie wird kaum diskutiert, weil sie wenig glamourös ist.
Das Symptom ist bekannt: ein gut gewartetes Designsystem, ein aktiver Contribution-Prozess und eine Codebasis mit vierhundert literalen Hex-Werten. Niemand hat absichtlich gegen eine Regel verstoßen. Es war ein Freitag, der Token passte nicht ganz, und das Hinzufügen eines Hex-Werts war schneller als eine Diskussion – dreihundert Mal.
Niemand hat das System absichtlich verletzt. Das Hinzufügen eines literalen Wertes war schneller als eine Diskussion, dreihundert Mal.
Es gibt genau drei Enforcement-Mechanismen, und nur einer davon ist kostenlos:
| Mechanismus | Kosten | Effektivität | |
|---|---|---|---|
| Dokumentation | Das Richtige schriftlich festhalten | 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 veröffentlichte Präzedenzfälle, die es zu studieren lohnt. Salesforce's SLDS 2 liefert einen Linter und einen Validator, die das Markup gegen eine Regeldatenbank scannen und Korrekturen vorschlagen – die mittlere Zeile, auf Enterprise-Ebene. Stripe's app UI toolkit wählt die untere Zeile: Seine css-Prop akzeptiert benannte Tokens und nichts anderes, mehrere Komponenten verweigern Overrides vollständig, und Einschränkungen der Komponentenhierarchie begrenzen, was was enthalten darf.
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 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, die als erste Verteidigungslinie beschrieben wird, 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 die Arbeit völlig aus den Augen verliert. Das Hinzufügen der Ebene fängt sie ein.
| 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 Implementierung | 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 einer Einschränkung darin – „großzügiges Spacing, 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 gehen von einem Rhythmus aus: 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 stellt die drastischste Änderung dar. Die meisten Designsysteme bestanden schon immer teils aus Dokumentation und teils aus Folklore. Die Folklore funktionierte, weil ein Entwickler, der die zehn vorherigen Screens gesehen hatte, sie absorbierte. 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 Systemfehler 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, und der, der die meisten Fehler findet. 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 ausführlich 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 anfragen – 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 komplett zu entfernen – zum Beispiel durch 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 tatsächlich 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, sodass die Last bei den Beiträgen sinkt, während das Volumen des darauf basierenden Codes steigt, ohne dass die Review-Kapazitäten mitwachsen – die Last bei der Durchsetzung steigt also. 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.