Sieben Teams, vier Zielgruppen, eine Plattform
Eine B2B-Technikplattform ist kein Produkt mit einer Nutzergruppe. Ein professioneller Einkäufer sucht und vergleicht. Eine Beschaffungsabteilung braucht Freigaben, Budgets und eine nachvollziehbare Spur. Ein Account-Administrator verwaltet, wer im eigenen Unternehmen was bestellen darf. Der Kundenservice arbeitet auf denselben Oberflächen von der anderen Seite, unter Zeitdruck, um etwas zu reparieren.
Sieben Produktteams bedienen diese vier Gruppen, und jedes Team hat für die eigene recht. Sich selbst überlassen kommen sie auf sieben vernünftige Antworten auf dieselbe Frage, und wer zwischen ihnen wechselt, und das sind alle vier, bezahlt die Differenz. Ein Designsystem ist der Weg, auf dem eine Plattform aufhört, ihren Kundinnen und Kunden das eigene Organigramm in Rechnung zu stellen.
Dafür ist Fuse da. Die Zahl der Komponenten ist das Mittel.
Abgestimmt über drei Bereiche, die mir nicht unterstellt sind
Das System überspannt Product, Engineering und IT. Keiner dieser Bereiche berichtet an mich, was die Abstimmung zur eigentlichen Arbeit macht und die Komponentenbibliothek zum leichten Teil.
Getragen hat es, weil jeder Bereich das bekam, was er für ein Ja braucht. Product brauchte Teams, die schneller werden, also einen Rollout in einer Reihenfolge, in der kein Team anhalten und refactoren muss. Engineering brauchte den Komponentencode als eigenen, prüfbar und debuggbar, ohne Anbieter im kritischen Pfad. Die IT brauchte das System innerhalb des bestehenden Stacks und seiner Sicherheits- und Barrierefreiheitspflichten und nirgendwo daneben. Sponsoring und Budget auf Vorstandsebene waren gesichert, bevor irgendetwas davon gefragt wurde, denn ein Gespräch darüber, wie ein System eingeführt wird, ist ein anderes als das darüber, ob es finanziert wird.
Ein System, in Figma und im Repository
Fuse liegt auf shadcn-vue, womit der Komponentencode in Conrads eigenem Repository liegt. Er kann geprüft, gethemed und repariert werden, ohne auf ein Vendor-Release zu warten.
Designseite und Codeseite sind ein System, keine zwei Artefakte, die einander ähneln. Ein in Figma geändertes Token hat ein benanntes Gegenstück im Repository, eine Komponente hat je Seite eine Definition, und der Workflow weiter unten ist dafür gebaut, Drift dazwischen zu finden. Zwei Quellen der Wahrheit sind der übliche Fehlerfall, und genau er lässt eine Plattform zusammengestückelt wirken.
Der Preis des Besitzes ist real und gehört klar gesagt: Das Team besitzt Pflegeaufwand, den es hätte mieten können. Für einen Händler mit langem Katalogausläufer und Barrierefreiheitspflichten, die für den gesamten Katalog gelten, ist dieser Besitz das günstigere Risiko. Der Releasezyklus eines Anbieters ist eine Abhängigkeit mitten in einer rechtlichen Verpflichtung.
Was drin ist, beginnend unter den Komponenten
Zwei Fundamente wurden ersetzt, bevor die erste Komponente entstand, denn ein System erbt das, worauf es steht.
Die Schrift. Die Marke lief auf Conrad Basis, einer lizenzierten Schrift aus dem Printbereich. Auf einer digitalen Plattform bedeutet das laufende Lizenzkosten und Plätze, die verwaltet werden wollen, für Buchstabenformen, die für ein anderes Medium gezeichnet wurden. Ersetzt wurde sie durch Inter, eine Schrift für Bildschirme. Die Lizenzkosten entfielen, und jedes Team hat dieselbe Schrift in Figma, im Repository und in allem, was Partner für die Marke bauen.
Die Icons. Es gab einen kleinen, von Hand gezeichneten Satz, uneinheitlich in Strichstärke, Raster und Bildsprache, und jedes Team, das ein fehlendes Icon brauchte, zeichnete sich eines. Das System ist auf Font Awesome gewechselt: eine Bibliothek, eine Strichstärke, ein Raster, und etwas zum Greifen für den Fall, den niemand vorhergesehen hat. Das Zeichnen hörte auf, und die Diskussion darüber auch.
Beides führt niemand vor, und beides ist der Grund, warum eine Plattform als eine Plattform gelesen wird, bevor die erste Komponente geladen ist.
Darauf: 35 Komponenten, mit einem Komponenten-Workshop, damit Beiträge einen Ort haben, und CI/CD, damit sie geprüft werden, bevor sie ankommen. Sieben Produktteams sind im Scope.
Contribution Governance, schriftlich
Den Rollout-Plan habe ich für den CTO geschrieben: Architektur, Besetzung und Contribution Governance.
Das Governance-Modell beantwortet die drei Fragen, mit denen ein Team tatsächlich ankommt. Wem das System gehört, damit es eine benannte Gruppe gibt, die dafür geradesteht. Wer es ändern darf, nämlich jedes Produktteam, über einen Vorschlag, der in den Komponenten-Workshop und durch CI/CD geht, bevor er in irgendeinem fremden Build landet. Und was passiert, wenn ein Team etwas braucht, das es nicht gibt, nämlich eine dokumentierte lokale Variante mit Review-Datum, damit das Team in derselben Woche weiterarbeitet und das System daraus lernt, ohne dass ein Fork zurückbleibt.
Ohne diese drei Antworten wird ein System zum Engpass, sobald es jemand eilig hat, und der erste Fork folgt innerhalb eines Quartals. Mit ihnen hat ein Team, das anderer Meinung ist, einen Weg, der im System endet.
KI auf den Pflegeaufwand gerichtet
Ich habe einen KI-gestützten Workflow gebaut, der Figma mit Claude Code verbindet: Komponentennutzung gegen das System prüfen, Drift zwischen Entworfenem und Gebautem finden und die Teile der Dokumentation erzeugen, die mühsam genug sind, um sonst zu veralten. Jede Änderung ist kontrolliert und prüfbar.
Er zielt auf den Pflegeaufwand, denn dort gehen die Stunden eines Designsystems tatsächlich hin. Diese Seite läuft auf demselben Workflow.
Entscheidungen
Vier Stellen, an denen das Designargument verändert hat, was passieren sollte.
Erst als Produkt finanzieren, dann bauen. Geplant: mit Komponenten anfangen und Wert zeigen, so wie die meisten Systeme beginnen. Argumentiert: Ein System ohne Sponsor, Budget und Mandat wird zum Nebenprojekt, das drei Designerinnen und Designer in ihrer eigenen Zeit pflegen, und dieses Risiko hatte ich beim Bau von Sunscreen aus der Nähe gesehen. Der Business Case gehörte in die Währung, die das Unternehmen ohnehin benutzt: sieben Teams, die dieselbe Komponentenrechnung zahlen. Passiert: Sponsoring und Budget auf Vorstandsebene standen vor dem ersten Token. Das Rollout-Gespräch drehte sich um das Wie, nie um das Ob.
Die Marken-Schrift ersetzen und nicht fürs Web lizenzieren. Geplant: die Print-Lizenz auf die digitale Plattform ausweiten, weil die Marke bereits darum herum definiert war. Argumentiert: Die Schrift war für Papier gezeichnet und pro Platz bepreist, die Plattform würde also dauerhaft für Buchstabenformen zahlen, die nie für einen Bildschirm gemacht wurden, und jeder Partner müsste sich ebenfalls einkaufen. Eine Marke ist an mehr erkennbar als an einer Schrift. Passiert: Inter in Figma, im Repository und in Partnermaterial. Die laufenden Lizenzkosten sind weg, und die Marke liest sich überall gleich.
Die Komponentenebene besitzen statt sie zu mieten. Geplant: eine Komponentenbibliothek übernehmen und ihren Releasezyklus mit ihr. Argumentiert: Die Pflicht gilt für jede Seite eines langen Katalogs, und keine Anbieter-Roadmap priorisiert den Ausläufer eines fremden Produkts. Mieten heißt, den Releaseplan eines anderen Unternehmens zwischen sich und eine rechtliche Frist zu stellen. Passiert: shadcn-vue, die Komponenten liefern also aus dem Repository aus, aus dem das Team ohnehin deployt, und eine Korrektur braucht niemandes Erlaubnis.
Die KI auf den Pflegeaufwand richten. Geplant: der naheliegende Einsatz, Komponenten schneller erzeugen. Argumentiert: Die Stunden eines Designsystems gehen in Drift, Audits und Dokumentation, die veraltet. Mehr Komponenten zu erzeugen vergrößert den Stapel, den ein System konsistent halten muss. Passiert: ein Workflow von Figma zu Claude Code, der Nutzung gegen das System prüft, Drift zwischen Entworfenem und Gebautem findet und die mühsame Dokumentation entwirft. Jede Änderung ist prüfbar.
Wo es steht, einschließlich des Teils, der nicht fertig ist
Fuse ist live und im ersten Jahr, und das ist der ehrliche Stand. Die Zahl, an der es am Ende gemessen wird, ist die, die das System bei FTI nach einem Jahr zeigen konnte, und die hat es noch nicht.
Die Designebene ist vollständig: Fundamente, Komponenten, Tokens, der Workshop, das Governance-Modell und der Rollout-Plan. Der Engineering-Strang braucht eine eigene verantwortliche Person, um die Einführung im selben Tempo zu tragen, und diese Lücke liegt bei der Führung auf dem Tisch, früh und laut benannt. Eine Ressourcenlücke früh zu benennen ist günstiger, als sie im zweiten Jahr zu entdecken, und ein System, das der Kapazität zur Einführung davonläuft, ist ein Fork mit Anlauf.
Was es hat, ist das, wofür bei FTI ein Jahr Überzeugungsarbeit nötig war: einen Sponsor, ein Budget, ein Governance-Modell und einen Rollout-Plan, den der CTO gelesen hat.