Ausgangslage
Atlas Systems ist ein Softwareunternehmen mit zwölf Produktteams. Jedes Team hatte seine eigene Button-Komponente, eigene Farben und eigene Vorstellungen davon, wie ein Formular aussieht. Das Ergebnis war nicht nur inkonsistent – es war langsam. Vier verschiedene UI-Bibliotheken landeten im Bundle, und die wichtigste Produktseite brauchte auf einem durchschnittlichen Laptop mehr als vier Sekunden bis zur Interaktion.
Die Geschäftsführung wollte ein „Design-System“. Die Teams wollten keine weitere Vorschrift. Der eigentliche Auftrag war deshalb: eine gemeinsame Grundlage schaffen, die Entscheidungen vereinfacht, ohne die Produktteams auszubremsen.
Meine Rolle
Ich war als Frontend Architect für die technische Strategie, die Tokens, die Komponenten-API und die Migration verantwortlich. Ein Designer und eine Entwicklerin aus dem Produktteam arbeiteten fest mit; die übrigen Teams waren über eine wöchentliche Sprechstunde eingebunden.
Vorgehen
1. Erst messen, dann vereinheitlichen.
Wir haben die Bundles von vier Produkten analysiert und die größten Überschneidungen identifiziert. Überraschend war, dass nicht die Komponenten das Problem waren, sondern die duplizierten Utility-Klassen und vier verschiedene Icon-Pakete. Die erste Version des Systems bestand deshalb aus Tokens, Icons und einer kleinen Zahl von Primitive-Komponenten – nicht aus 80 neuen Komponenten.
2. Tokens als Vertrag.
Farben, Abstände, Typografie, Radien und Schatten wurden als CSS Custom Properties definiert und über Tailwind konsumiert. Die Tokens bekamen semantische Namen (surface, text-muted, border-strong), keine Farbnamen. Dadurch konnten Teams ihr Layout behalten und trotzdem dieselbe visuelle Sprache sprechen.
3. Komponenten mit klaren Grenzen.
Jede Komponente hat eine kleine, dokumentierte API, Zustände für Fokus, Fehler, Laden und Deaktiviert sowie Tests für Tastaturbedienung. Wir haben bewusst keine „Alleskönner“-Komponenten gebaut. Wenn ein Team etwas Spezielles brauchte, sollte es das Spezielle bauen – auf Basis der Primitive, nicht als Variante der Universal-Komponente.
4. Migration als Produkt, nicht als Projekt.
Statt eine Big-Bang-Migration zu verlangen, gab es einen Codemod für die häufigsten Fälle und eine wöchentliche Sprechstunde. Jedes Team konnte selbst entscheiden, wann es migriert. Der Anreiz war konkret: kleinere Bundles, weniger Bugs, schnellere Reviews. Nach fünf Monaten waren alle zwölf Teams migriert, ohne dass ein Team seine Roadmap stoppen musste.
Ergebnis
- Das JavaScript-Bundle der größten Produktseite schrumpfte um 42 Prozent.
- Der Lighthouse-Performance-Score stieg von 62 auf 96.
- Zwölf Teams nutzten die gemeinsamen Tokens und Primitive.
- Die Zahl der UI-Bugs in Reviews ging spürbar zurück, weil Zustände und Tastaturverhalten zentral getestet wurden.
Was ich mitgenommen habe
Ein Design-System ist kein Komponentenlager. Es ist ein Set von Entscheidungen, das teamspezifische Arbeit einfacher macht. Die technische Arbeit war wichtig, aber der Unterschied entstand durch die Migration: Wir haben die Teams nicht gezwungen, sondern ihnen einen messbaren Vorteil gegeben. Gute Systeme gewinnen durch Adoption, nicht durch Vollständigkeit.