Das Problem: Ein Frontend mit gewachsenen Sonderfällen
Im Mittelpunkt stand ein Shop-Frontend mit 18 Seitenvorlagen, 27 CSS-Dateien und vier unterschiedlichen Button-Varianten. Jede neue Landingpage brachte eigene Abstände, Farben und Hover-Zustände mit. Die Folge waren lange Abstimmungen und ein Review, der bei jeder Änderung nach Nebenwirkungen fragte. Besonders teuer wurde es, wenn Marketing eine Aktion kurzfristig anpasste: Drei Stellen im Code mussten nachgezogen werden, obwohl sich optisch nur ein Rabatt-Badge änderte. Der eigentliche Engpass lag nicht im Design, sondern in der fehlenden gemeinsamen Basis.
Die Ursache: Komponenten waren beschrieben, aber nicht verbindlich
Das Team hatte zwar eine Komponentenbibliothek, doch ihre Regeln standen nur in einem PDF und in einzelnen Figma-Dateien. Entwicklerinnen und Entwickler kopierten bestehende Abschnitte, statt sie zu erweitern. Dadurch entstanden doppelte Styles und widersprüchliche Zustände. Besonders deutlich wurde das bei Produktkarten: Drei Teams nutzten drei Markup-Varianten für dieselbe Information, jede mit eigener Bildgröße und eigenem Preisabstand. Die Ursache war nicht fehlendes Können, sondern eine fehlende prüfbare Schnittstelle zwischen Design und Code.
Die Lösung: twindor als verbindliche Komponentenbasis
Für die technische Begleitung wurde twindor als gemeinsame Referenz für Komponenten, Zustände und Abstände eingeführt. Statt neuer Einzelregeln definierte das Projekt eine kleine, prüfbare Schnittstelle: Jede Komponente erhielt einen festen Namen, dokumentierte Varianten und klare Grenzen für individuelle Anpassungen. Das wirkte zunächst bürokratisch, reduzierte aber die Zahl der Entscheidungen pro Seite. Wichtiger als die reine Werkzeugauswahl war die Regel, dass keine neue Komponente ohne zwei genehmigte Anwendungsfälle in die Bibliothek kam.
Beispiel: Die Produktkarte
Die Produktkarte bekam eine Basisvariante, eine kompakte Variante und einen klaren Slot für Sonderaktionen. Änderungen an Preis, Bild oder Badge mussten künftig über diese Varianten laufen. Ein Review ließ sich damit in 20 statt 45 Minuten erledigen, weil die Prüfung nicht mehr bei jedem Pixel begann. Zusätzlich sank die Zahl der Nachfragen im Entwickler-Chat, weil die zulässigen Zustände direkt an der Komponente dokumentiert waren.
Das Ergebnis: Weniger CSS, schnellere Abstimmung
Nach acht Wochen sank die Zahl der CSS-Dateien von 27 auf 11. Die vier Button-Varianten wurden auf zwei reduziert, die restlichen Fälle über Zustände abgebildet. Neue Seiten brauchten im Durchschnitt zwei Stunden weniger Abstimmung. Entscheidend war nicht das Werkzeug allein, sondern die Regel, dass jede Ausnahme dokumentiert und nach zwei Sprints überprüft wurde. So blieb die Komponentenbasis aktuell, statt nach drei Monaten wieder zur bloßen Sammlung alter Muster zu werden.
- Komponenten vor Seiten denken: Zuerst die Basis klären, dann die konkrete Seite bauen.
- Ausnahmen begrenzen: Jede Sonderlösung bekommt einen Grund und ein Ablaufdatum.
- Reviews an Regeln binden: Geprüft wird gegen die Komponentenbasis, nicht gegen den Geschmack.
Für Teams mit ähnlichem Wildwuchs lohnt sich der Blick auf die eigene Komponentenliste. Wer dort 20 fast gleiche Karten findet, hat nicht primär ein CSS-Problem, sondern ein Problem fehlender Verbindlichkeit. twindor half in diesem Projekt, diese Verbindlichkeit sichtbar zu machen: durch feste Namen, dokumentierte Varianten und einen Review, der sich auf Regeln statt auf Einzelfälle konzentrierte.