Der Fehlerfall ist nie die Komponentenbibliothek
Es ist der Start ohne Sponsor, ohne Budget und ohne Mandat, und das Zusehen, wie daraus ein Nebenprojekt wird, das drei Designerinnen und Designer in ihrer eigenen Zeit pflegen. Komponentenbibliotheken zu bauen ist nicht schwer. Eine durch eine Reorganisation, eine Budgetrunde und einen CTO-Wechsel am Leben zu halten, ist schwer, und das ist ein organisatorisches Problem mit einer organisatorischen Antwort.
Die Reihenfolge ist deshalb immer dieselbe: den Fall machen, als Produkt mit Team, Backlog und einer Zahl finanzieren lassen, die gezeigt werden muss, und erst dann den ersten Token benennen.
Diese Reihenfolge bin ich zweimal gegangen, in Organisationen, die fast nichts gemeinsam hatten.
Fuse, bei Conrad Electronic. Sieben Produktteams auf einer Plattform, shadcn-vue, damit der Komponentencode in Conrads eigenem Repository liegt, 35 Komponenten mit CI/CD und ein Rollout-Plan für den CTO. Im ersten Jahr.
Sunscreen, bei der FTI Group. 90 Tochtergesellschaften, eine React-Bibliothek für einen Next.js-Stack, ein finanziertes Produktteam aus acht Personen, 356 Komponenten und ein gemessener Return über 170 Prozent in den ersten zwei Monaten.
Ein drittes ist bei Smart InsurTech als Designgrundlage neben der Research-Praxis entstanden, während das Unternehmen lernte, als Produktorganisation zu arbeiten.
Was ein Unternehmen ohne eines bezahlt
Die Rechnung wird nie aufgeschlüsselt, und genau deshalb wird sie jahrelang bezahlt, ohne dass jemand sich dafür entschieden hätte.
Dieselbe Ebene entsteht einmal pro Team. Ein Datumsfeld, eine Tabelle, ein Dialog, ein Filter. Sieben Teams, jedes im eigenen Bereich im Recht, jedes schreibt eine Komponente, die die anderen sechs schon haben. Der erste Bau ist nicht der Preis. Der Preis ist, dass eine Komponente nun sieben Verantwortliche hat, sieben Verhaltensweisen und sieben Mengen von Sonderfällen, und jede spätere Änderung muss sie alle finden.
Barrierefreiheit wird einmal pro Implementierung gekauft. Eine Pflicht, die für den gesamten Katalog gilt, lässt sich nicht Komponente für Komponente erfüllen. Ein Kontrastfehler, siebenmal unabhängig geschrieben, bedeutet sieben Korrekturen, sieben Prüfungen und sieben Gelegenheiten, eine zu übersehen, und das nächste Audit beginnt wieder bei null.
Die Kundschaft bezahlt das Organigramm. Wer zwischen Bereichen wechselt, und das ist im B2B dieselbe Person für Beschaffung, Verwaltung und Support, bekommt in jedem Bereich eine andere Antwort auf dieselbe Frage. Entworfen hat das niemand. Es ist die Summe vernünftiger lokaler Entscheidungen, und es liest sich für die Kundschaft als eine aus Teilen zusammengesetzte Plattform.
Design verbringt seine Zeit mit dem, was es schon gibt. Ein Team ohne Komponentenebene spezifiziert sich jede Iteration eine. Diese Arbeit zählt niemand, weil sie nie als Projekt auftaucht. Sie taucht auf als: Design ist langsam.
Und es gibt keine Zahl, mit der sich streiten ließe. Das ist der Teil, der die Rechnung offen hält. Der Preis verteilt sich über die Geschwindigkeit jedes Teams und die Roadmap jedes Quartals, bleibt also unsichtbar, bis jemand ihn in die Währung übersetzt, die das Unternehmen ohnehin benutzt. Mit dieser Übersetzung fängt die Arbeit an, und genau sie lassen die meisten Systeme aus.
Bei der FTI Group wurde die Alternative gemessen: Das Designsystem der Gruppe hatte sich binnen zwei Monaten mehr als bezahlt gemacht, und genau diese Zahl ist der Grund, warum es seine Finanzierung durch ein schwieriges Jahr behielt. Bei Conrad Electronic lautet die Rechnung: sieben Teams, eine Komponentenrechnung.
Eine Anmerkung zur öffentlichen Beleglage, weil es verlockend ist, sie zu leihen: Es gibt kaum welche. Die viel zitierten Prozentzahlen zu Einsparungen durch Designsysteme führen auf eine Handvoll Anbieter-Blogs zurück, die einander zitieren, und der einzige kontrollierte Test, den ich finde, arbeitete mit acht Entwicklern an einem einzigen Formular. Eine Zahl zum eigenen System, im eigenen Unternehmen gemessen, ist mehr wert als all das, und nur solche Zahlen stehen auf dieser Seite.
Was jedes Mal gleich ist
Finanzierung vor Tokens. Bei FTI war das Argument die Integrationssteuer über 90 Tochtergesellschaften. Bei Conrad waren es sieben Produktteams, die dieselbe Komponentenebene neu bauen. Andere Rechnung, gleiche Schlussfolgerung, und in beiden Fällen kam das Geld vor der Arbeit.
Eine Zahl, die das Geschäft ohnehin benutzt. Return on Investment, Time to Market, Adoptionsrate. Nicht die Komponentenzahl, die Aufwand misst.
Adoption wird verdient. Teams adaptieren ein System, das einem anderen Team sichtbar Zeit gespart hat. Ein System, das ihnen verordnet wurde, forken sie, und dann gibt es zwei.
Governance aufgeschrieben. Wem es gehört, wer es ändern darf, was passiert, wenn ein Team etwas braucht, das es nicht gibt. Ein System ohne diese Antwort wird zum Engpass, sobald es jemand eilig hat.
Was sich unterscheidet, und warum das zählt
Die beiden sind nicht dasselbe Projekt zweimal. Der Stack ist anders, das Finanzierungsargument ist anders, die Größenordnung ist anders, und das Ergebnis steht an einem anderen Punkt. Genau das ist der nützliche Teil: Die Reihenfolge hielt, während alles, worauf sie angewendet wurde, sich änderte.
Das System bei Conrad muss sich seinen Platz gegen eine Plattform verdienen, die schneller liefern kann als es, und der Fall wurde einem CTO erklärt. Das bei FTI musste sich die Übernahme in einer Föderation verdienen, die es hätte ignorieren können, und der Fall wurde einer Gruppe von Tochtergesellschaften erklärt. Eines ist im ersten Jahr und ehrlich darüber, das andere fertig und gemessen.
Eines zweimal gebaut zu haben, belegt keines der beiden Projekte für sich. Das zweite ging schneller, weil die Reihenfolge schon bekannt war.