Ein Team besass eine vollständige Component Library und drei Produkte in Production. Das neue Dashboard kopierte einen alten Button, statt den offiziellen zu importieren. Die Library Version brauchte einen Provider, trug Annahmen einer Marketingseite und erschwerte den einfachen Screen. Das Team war nicht undiszipliniert. Das System war teurer geworden als Duplikation.
Ein Design System verdient seine Kosten durch wiederholte Entscheidungen über genügend Menschen und Produktflächen. Geschmack ist nicht die Schwelle. Koordinationskosten sind es.
Teams und Flächen vor Components zählen
Ein Product Team in einer Anwendung ist mit lokalen Components und einem kleinen Token Set oft schneller. Das gemeinsame System wird wertvoll, wenn unabhängige Teams dieselbe Interaction lösen, mehrere Flächen dieselbe Marke ausdrücken oder Accessibility und Verhalten schneller auseinanderlaufen, als Reviews sie einfangen.
Gezählt werden Consumer, Releasezyklen und wiederkehrende Entscheidungen. Website, Accountbereich, internes Tool und Native App sind nicht einfach mehr Screens. Rendering, Input und Release unterscheiden sich. Gemeinsame Foundations helfen, doch dieselbe Component Implementation überall zu erzwingen schafft einen falschen Standard.
Der Anfang liegt dort, wo Koordination sich wiederholt, nicht bei einer Liste aller denkbaren Components.
Adoption scheitert an der Systemsteuer
Teams verlassen Systeme, die schwerer zu verstehen sind als lokaler Code. Häufige Ursachen sind unklare Component Grenzen, historisch gewachsene Prop Kombinationen, schwache Dokumentation, unzugängliche Defaults und Releases, die eine eigene Verhandlung brauchen. Erfordert jede Ausnahme Erlaubnis eines zentralen Teams, entstehen stille Forks.
Visuelle Vollständigkeit kann funktionale Lücken verbergen. Ein Button existiert, aber Loading, Error, Focus und Analytics fehlen. Ein Form Field sieht richtig aus, kann aber die Validation des Produkts nicht ausdrücken. So standardisiert das System Optik, während jedes Team Verhalten neu baut.
Gemessen wird die Zeit vom Bedarf bis Production. Adoption ist ein Service Ergebnis, kein Download Counter.
Governance ist Produktarbeit
Ein Design System braucht Ownership, Priorisierung, Support und Deprecation. Jemand prüft Beiträge, beantwortet Fragen, veröffentlicht Änderungen und migriert Consumer. Fehlt diese Kapazität, friert die Library ein, während Produkte weiterziehen.
Contribution darf nicht einfach Schickt einen Pull Request bedeuten. Product Teams brauchen einen klaren Weg vom lokalen Pattern zum Shared Primitive samt Beleg, dass es sich wiederholt. Das Systemteam braucht die Autorität, produktspezifische Wünsche abzulehnen.
Versionierung kommuniziert Verhaltensänderungen, nicht nur visuelle. Focus Fix, DOM Änderung oder neuer Default können Consumer brechen, obwohl Screenshots gleich aussehen.
Foundations vor dem Katalog bauen
Die dauerhafteste Schicht ist meist kleiner als der Showroom: Farbrollen, Typografie, Spacing, Motion, Focus, Form Semantics und Layout Primitives. Sie erzeugen Konsistenz, ohne jeden Screen in eine universelle Component zu zwingen.
Shared Components kommen hinzu, wenn Wiederholung belegt und Verhalten wichtig ist. Escape Hatches bleiben ausdrücklich. Eine produktspezifische Composition kann Foundations nutzen, ohne zum Kern zu gehören. Ungenutzte Experimente werden gelöscht. Ein Design System ist kein Archiv aller Oberflächen des Unternehmens.
Diese Woche prüfen, ob sich das System lohnt
Aktive Teams und Produktflächen werden gelistet. Bereits abweichende Wiederholungen zeigen ihre Kosten: Defects, Accessibility Lücken, doppelte Arbeit oder inkonsistentes Kundenverhalten. Gewählt wird das Pattern mit dem klarsten wiederkehrenden Aufwand.
Dieser Slice wird mit einem echten Product Team gebaut oder repariert. Nutzung, Edge Cases und Migration werden dokumentiert. Gemessen werden Adoptionszeit und lokale Overrides. Kann die Shared Version eine lokale Lösung bei Delivery und Wartung nicht schlagen, wird das System vor der Erweiterung repariert.
Die unbequeme Antwort kann lauten, dass ein vollständiges Design System noch nicht gerechtfertigt ist. Ein disziplinierter Component Ordner kann reichen. Das richtige System beginnt, wenn wiederkehrende Koordination teurer als gemeinsame Ownership wird, und lebt nur, solange der gemeinsame Weg der einfachste glaubwürdige Weg bleibt.