Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Vom Design-System ins Live-Frontend, ohne Handoff-Verlust
Ein Design-System ist nicht dasselbe wie ein Live-Frontend, und genau in der Lücke zwischen beidem entsteht der sichtbarste Drift eines Produkts. Design-Tokens, die in einer Quelldatei sauber definiert sind, werden im Code zu rohen Hex-Werten, sobald ein Entwickler das passende Token nicht findet. Komponenten-Varianten, die im Design-File sauber existieren, schaffen es nie in die Komponente, die tatsächlich live geht, weil die zehnte Variante mehr kostet, als der Termin erlaubt. Zustände, die ein echtes Interface ständig braucht, Laden, Leer und Fehler, werden fast nie designt, also improvisiert, wer gerade den Screen baut, etwas Plausibles und macht weiter. Das ist keine Nachlässigkeit. Es ist das, was passiert, wenn Design-System und Live-Frontend wie zwei getrennte Artefakte behandelt werden, verbunden nur durch einen Review-Kommentar, statt als ein System mit einer einzigen Quelle der Wahrheit. Hier ist, wo diese Lücke tatsächlich entsteht, und wie sie sich strukturell schließen lässt.
Drei Stellen, an denen der Handoff tatsächlich reißt
Fragt man eine Designerin und einen Entwickler getrennt, wo ein Design-System aufhört zu funktionieren, unterscheiden sich die Details, aber das Muster wiederholt sich über Teams hinweg. Erstens überleben Tokens den Handoff nur so lange, wie eine Komponente nichts braucht, was außerhalb der Token-Datei existiert. Ein Entwickler unter Termindruck schreibt `#5B4FE9` direkt in eine Komponente, statt einen neuen Token anzufragen, und dieser Hardcode lebt jetzt in Produktion, unsichtbar für das Design-System und immun gegen das, worauf der Token im nächsten Quartal geändert wird. Zweitens sind Varianten billig zu zeichnen und teuer zu bauen. Ein Design-File kann einen deaktivierten Zustand, eine kompakte Dichte, eine rechts-nach-links-Spiegelung und eine Dark-Mode-Version desselben Buttons ohne viel Zusatzaufwand enthalten. Alle vier tatsächlich zu implementieren bedeutet vier zusätzliche Code-Pfade und vier zusätzliche Chancen auf eine Regression, also werden nur die Varianten gebaut, die ein erstes Ticket verlangt, und der Rest lebt im Design-File als Absicht, nicht als funktionierende Software. Drittens, und am meisten unterschätzt, sind die Zustände, in denen ein Interface die meiste reale Zeit verbringt, genau die, die niemand designt.
Tokens, die den Handoff überleben, und die, die es nicht tun
Die Lösung für die Token-Hälfte dieses Problems existiert bereits als offene Spezifikation, auch wenn die Verbreitung noch uneinheitlich ist. Die W3C Design Tokens Community Group arbeitet an einem gemeinsamen JSON-Format für Design-Tokens, damit ein Token, der einmal in einem Design-Tool definiert wurde, exportiert und von einer Codebasis konsumiert werden kann, ohne dass jemand Hex-Werte von Hand abtippt. Style Dictionary, das quelloffene Build-Tool, das ursprünglich von Amazon veröffentlicht wurde, nimmt Tokens in genau diesem strukturierten Format und übersetzt sie in das, was eine Plattform jeweils braucht: CSS-Custom-Properties, ein Swift-Enum, eine Android-XML-Ressource. Figmas eigenes Variables-Feature und der zugehörige Dev-Mode-Inspector existieren genau dafür, die Inspektionslücke zwischen dem zu schließen, was eine Designerin sieht, und dem, was ein Entwickler ohne Raten in Code kopieren kann. Keines dieser Tools löst den Handoff für sich allein. Eine Token-Pipeline hält nur, wenn jeder Token, den eine Designerin auswählen kann, auf einen Token verweist, den ein Entwickler namentlich referenzieren kann, und wenn das Anlegen eines neuen Tokens ein Fünf-Minuten-Pull-Request ist, statt ein Ticket, das ein Sprint lang im Backlog liegt.
Varianten, die es nur im Design-File gibt
Ein Component-Library-Review ist ein nützliches Ritual, aber er erkennt Drift immer erst im Nachhinein, wenn eine Variante bereits ohne die im Design-File spezifizierten Zustände live gegangen ist. Der dauerhaftere Fix ist, Varianten-Abdeckung als Eigenschaft des Komponenten-Vertrags selbst zu behandeln, einmal definiert im Schema, das sowohl Design-Tool als auch Codebasis lesen, statt jedes Mal aus dem Gedächtnis neu abgeleitet, wenn jemand ein Design-File öffnet. Der Vertrag einer Button-Komponente sollte explizit festlegen, welche Kombinationen aus Zustand, Größe und Dichte unterstützt werden, und eine Komponente, die Disabled unterstützt, sollte tatsächlich eine deaktivierte visuelle Darstellung rendern, statt stillschweigend auf den Standardzustand zurückzufallen, weil niemand es verdrahtet hat. Dabei geht es weniger um Prozessdisziplin und mehr darum, die nicht unterstützte Kombination unmöglich zu machen, aus Versehen zu shippen. Wenn die Prop-Typen einer Komponente nur die Varianten erlauben, die tatsächlich implementiert wurden, kann eine Designerin im Design-Tool keine Kombination auswählen, die im Code nicht existiert, was eine ganze Kategorie an Handoff-Reviews aus dem Gespräch entfernt, bevor es überhaupt beginnt. Die Alternative, eine gemeinsam gepflegte Tabelle, welche Varianten fertig sind, funktioniert genau so lange, wie jemand sie von Hand aktuell hält.
Die Zustände, die niemand designt: Laden, Leer und Fehler
Öffnet die meisten Design-Files eines bestehenden Produkts, und zählt, wie viele Screens den Leer-Zustand, das Lade-Skeleton oder den konkreten Fehler zeigen, den eine Nutzerin sieht, wenn eine Anfrage in ein Timeout läuft. Die Zahl liegt fast immer nahe null, dabei trifft eine Nutzerin ständig auf einen dieser drei Zustände: bei einer langsamen Verbindung, beim ersten Besuch, bevor überhaupt Daten existieren, bei einer Suche, die nichts zurückgibt, bei einer Zahlung, die fehlschlägt. Weil diese Zustände nicht designt sind, erfindet sie, wer gerade am nächsten am Code sitzt, wenn das Ticket ansteht, wodurch dasselbe Produkt am Ende drei verschiedene Lade-Darstellungen und zwei verschiedene Leer-Zustands-Illustrationen hat, keine davon gegen dieselbe visuelle Sprache wie der Rest des Interfaces geprüft. Laden, Leer und Fehler als vollwertige Zustände im Komponenten-Schema zu behandeln, mit derselben Design-Sorgfalt wie den Standardzustand, schließt diese Lücke an der Quelle, statt sie Screen für Screen nach dem Launch zu flicken. Eine praktische Regel: Keine Komponente geht in Produktion, bevor ihr Lade-, Leer- und Fehlerzustand im selben Design-File existiert wie ihr Standardzustand, geprüft mit derselben Sorgfalt.
Die Lücke strukturell schließen statt per Review-Ping-Pong
Keiner der oben genannten Fixes hängt davon ab, mehr Designerinnen einzustellen oder Engineering mit einem schwereren Review-Prozess auszubremsen. Der gemeinsame Nenner ist, die Entscheidung von einem Gespräch, das nach dem Bau einer Komponente stattfindet, hin zu einer Vorgabe zu verschieben, die durchgesetzt wird, bevor überhaupt etwas live gehen kann. Ein Design-System, das nur in einem Design-Tool lebt, ist Dokumentation. Ein Design-System, das den tatsächlichen Komponenten-Vertrag, die tatsächlichen Prop-Typen und die tatsächlichen Token-Referenzen erzeugt, die eine Codebasis konsumiert, ist Infrastruktur, und Infrastruktur driftet nicht so wie Dokumentation, weil es keinen manuellen Schritt gibt, an dem Drift entstehen kann. Das ist auch der Grund, warum Ping-Pong-Reviews zwischen Design und Engineering die Lücke selten dauerhaft schließen, selbst wenn beide Seiten gewissenhaft arbeiten: Ein Review-Kommentar behebt eine Instanz eines Problems, an einer Komponente, in einem Sprint, und dieselbe Kategorie an Problemen taucht bei der nächsten Komponente wieder auf, gebaut von jemandem, der nicht in diesem Review-Thread war. Ein gemeinsamer, maschinenlesbarer Vertrag zwischen Tokens, Varianten und Pflicht-Zuständen behebt die Kategorie, nicht die Instanz, und das ist die einzige Version dieses Fixes, die sich tatsächlich nicht wiederholt.
Fünf Schritte, um alles zusammenzuschalten
Nichts davon erfordert, das Design-Tool oder das Frontend-Framework auszutauschen, das ein Team bereits nutzt. Es erfordert eine bewusste Reihenfolge, angewendet auf jeweils eine Komponenten-Kategorie.
- Auditiert die bestehende Token-Datei gegen die produktive Codebasis und markiert jeden Hardcode, der ein Token dupliziert oder ersetzen sollte, als fehlenden Token, nicht als akzeptable Ausnahme.
- Definiert die vollständige Varianten-Matrix für jede Komponente, Zustand, Größe, Dichte und Schreibrichtung, im Schema der Komponente, nicht in einer Design-File-Beschriftung, damit eine nicht unterstützte Kombination in keinem der beiden Tools ausgewählt werden kann.
- Nehmt Laden, Leer und Fehler in die Definition von Fertig für jede datenrendernde Komponente auf, geprüft mit derselben visuellen Sorgfalt wie der Standardzustand, bevor die Komponente als abgeschlossen gilt.
- Gebt jedem übersetzbaren und jedem token-gesteuerten Prop eine explizite Quelle im Schema, damit ein Entwickler nie einen Grund hat, einen Wert hart zu codieren, nur weil der Token schwer zu finden war.
- Führt neue Token-Anfragen über einen schnellen Pfad, idealerweise einen Pull-Request am selben Tag, damit das Anlegen eines Tokens nie langsamer ist als das Hardcoden eines Werts.
Geht diese fünf Schritte der Reihe nach durch, und das meiste, was sich als Design-Review-Uneinigkeit zeigt, entpuppt sich als eine fehlende Schema-Entscheidung.
Wie das in eine größere Frontend-Architektur passt
Wir versuchen nicht, Figma, Storybook oder welche Komponenten-Entwicklungsumgebung ein Design- und Engineering-Team auch immer schon nutzt, zu ersetzen, und eine Plattform, die das versprechen würde, würde das falsche Problem lösen. Was wir unter der Agentic Frontend Management Platform bauen, ist die Schicht, an der die Tokens, Varianten und Pflicht-Zustände eines Design-Systems zum tatsächlichen Vertrag werden, aus dem ein Live-Frontend rendert, zentral kuratiert über Brand Consistency und visuell komponiert im Composable Visual Page Builder, sodass ein UX- oder UI-Designer nicht auf einen Engineering-Sprint warten muss, um eine Variante korrekt gerendert zu sehen, und ein Entwickler nicht raten muss, welchen Hex-Wert ein Design-File eigentlich gemeint hat. Unser UX- und UI-Agent prüft neue Komponenten außerdem im selben Review gegen Accessibility-Anforderungen, sodass Barrierefreiheit kein zusätzlicher Handoff-Verlust obendrauf wird.
Häufig gestellte Fragen
Ersetzt Laioutr Figma oder Storybook? Nein. Laioutr sitzt an dem Punkt, an dem die Tokens und Varianten eines Design-Systems zum tatsächlichen Frontend werden, das eine Nutzerin sieht, neben welchen Design- und Dokumentations-Tools ein Team auch immer schon nutzt.
Müssen wir unser gesamtes Design-System neu bauen, um das zu fixen? Nein. Die hier beschriebenen Fixes gelten jeweils für eine Komponenten-Kategorie, am besten beginnend mit der Komponente, die aktuell die meisten Hardcodes oder die meisten fehlenden Zustände hat.
Wessen Aufgabe ist es, festzulegen, welche Zustände eine Komponente braucht? Wer den Komponenten-Vertrag verantwortet, meist eine gemeinsame Entscheidung von Design-System-Ownership und Frontend-Engineering, einmal getroffen, wenn die Komponente definiert wird, nicht pro Feature neu verhandelt.
Verbessert das Schließen dieser Lücke auch die Barrierefreiheit? Oft ja, als Nebeneffekt. Eine Komponente mit einem sauber definierten Disabled- oder Fehlerzustand ist auch leichter barrierefrei zu machen, weil die Zustände bereits existieren, um die richtige Semantik daran zu hängen.
Nächste Schritte
Wenn euer Team denselben Handoff-Streit bei jeder neuen Komponente wiederholt, bucht eine 30-minütige Demo. Wir schauen uns euer Token-Setup an und wo die Schema-Schicht zwischen Design und Frontend nachziehen muss.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich damit, wie Design-Systeme den Kontakt mit einem echten Live-Frontend tatsächlich überleben.