Was bedeutet Design zu Code?

Design zu Code beschreibt den Weg von Entscheidungen, die in einem Werkzeug wie Figma getroffen wurden, zu lauffähigem Frontend-Code. Die tragfähige Variante überträgt Design-Tokens, statt Markup aus einer Zeichenfläche zu erzeugen: Tokens bleiben gültig, wenn sich die Oberfläche ändert, generiertes Markup nicht.

Zwei Ansätze, die verwechselt werden

Code aus einer Zeichenfläche erzeugen. Du richtest ein Werkzeug auf einen Figma-Frame und bekommst JSX oder HTML zurück. Das macht sich in einer Demo hervorragend und enttäuscht in der Produktion: Die Ausgabe hat keinerlei Bezug zu deiner Komponentenbibliothek, die Verschachtelung spiegelt wider, wie die Designerin ihre Ebenen gruppiert hat, und sobald sich das Design ändert, generierst du neu und verlierst jede Anpassung.

Die Entscheidungen übertragen. Du bewegst stattdessen die Tokens - Farbe, Abstände, Typografie, Radius - und lässt Entwickler Komponenten bauen, die darauf verweisen. In der Demo weniger beeindruckend. Es ist der Weg, der überlebt: Tokens bleiben gültig, wenn sich das Layout ändert, und der Code bleibt Code, den ein Mensch geschrieben hat und pflegen kann.

Fast jedes Team, das den ersten Ansatz probiert, landet beim zweiten.

Warum der Handoff weiter scheitert

Das Scheitern liegt nicht im Moment der Übergabe. Es liegt in allem danach.

Eine Designerin ändert eine Farbe in Figma. Diese Änderung muss ein Stylesheet erreichen. Es gibt keinen automatischen Weg, also läuft sie über eine Nachricht in einem Kanal, die jemand liest - oder nicht. Multipliziere das mit jeder Änderung über ein Jahr.

Beide Seiten arbeiten korrekt. Die Verbindung dazwischen ist ein Mensch, der daran denkt.

Die Einschränkung der Figma-API

Wichtig zu wissen, bevor man Werkzeuge in diesem Feld bewertet: Der REST-API-Endpunkt von Figma zum Lesen von Variablen ist ausschließlich in Enterprise-Tarifen verfügbar.

Das heißt: Ein Werkzeug, das Figma-Variablen über die REST-API synchronisiert, funktioniert in einer Demo auf einem Enterprise-Konto und tut auf dem Professional-Tarif, den die meisten Teams haben, gar nichts. Plugins sind davon nicht betroffen, weil sie Variablen von innerhalb der Datei über die Plugin-API lesen. Wenn du Sync-Werkzeuge vergleichst, frage, welches was benutzt.

Wie eine funktionierende Schleife aussieht

  1. Designentscheidungen leben als Tokens, an einer Stelle, die beide Seiten referenzieren.
  2. Eine Änderung auf der Designseite kommt als Diff an, nicht als Überschreibung.
  3. Ein Mensch mit Schreibrechten prüft sie und wendet sie an.
  4. Ein Pull Request geht gegen das Repository auf und durchläuft das normale Code-Review.
  5. KI-Agenten lesen dieselben Tokens live, sodass erzeugter Code innerhalb des Systems landet und nicht daneben.

Der Review-Schritt in der Mitte ist keine Reibung, die man wegoptimieren sollte. Ein Werkzeug, das die Tokens eines Teams stillschweigend umschreibt, kostet mehr Vertrauen, als die Automatisierung einbringt.

Wo Flash DSM hier steht

Flash DSM nutzt ein Figma-Plugin als Transport und funktioniert damit in jedem Figma-Tarif. Ein Publish wird zu einem prüfbaren Token-Diff, und ein freigegebenes Diff kann als Pull Request aufgehen.