Figma to Code: Warum das Ergebnis visuell korrekt, aber strukturell falsch ist

Jede Generation von Design-to-Code-Tooling kommt der Pixelgenauigkeit näher, aber nicht der Nutzbarkeit. Der Grund dafür ist struktureller Natur und liegt nicht an der Qualität des Modells. Ein Frame kodiert das Erscheinungsbild. Code benötigt eine Intention, und diese Intention war nie in der Datei enthalten.

Aktualisiert 2026-07-27

Was ein Frame tatsächlich enthält

Ein Figma-Frame ist ein Baum aus Formen mit Positionen, Füllungen, Konturen, Textabschnitten und Layout-Constraints. Das ist eine vollständige Beschreibung dessen, wie etwas in einer bestimmten Größe aussieht. Es ist keine Beschreibung dessen, was etwas ist.

In der DateiMuss abgeleitet werden
StrukturEine Gruppe von Rechtecken und Text an diesen KoordinatenDass diese Gruppe eine Card ist und dass es dieselbe Card ist, die auf neun anderen Screens verwendet wird
FarbeFüllung ist #6b7280Ob es sich um gedämpften Text, einen Rahmen, einen deaktivierten Zustand oder einen Platzhalter handelt
Abstände32px zwischen diesen zwei ElementenOb 32 ein Skalenschritt, ein Einzelfall oder das Ergebnis eines manuellen Verschiebens ist
ResponsivitätConstraints und alle existierenden Breakpoint-FramesWas bei jeder Breite dazwischen passiert
SemantikText mit größerer Schriftgröße und stärkerem SchriftschnittOb es ein h1, ein h2 oder lediglich formatierter Text ist, der gar keine Überschrift darstellt
Was ein Konverter lesen kann und was er erraten muss

Jede Zeile in der rechten Spalte ist eine Entscheidung, die der Konverter ohne Informationen treffen muss. Er wird jede einzelne plausibel und unabhängig treffen, weshalb das Ergebnis auf den ersten Blick überzeugend, in der Wartung jedoch unmöglich ist.

Ein Frame kodiert das Aussehen. Code benötigt Identität und Intention. Der Konverter versagt nicht – die Information war schlichtweg nie in der Datei vorhanden.

Die Kosten generierten Codes

Wird das Ergebnis unverändert übernommen, folgen vier spezifische Probleme – und all diese treten erst nach dem Merge des Codes auf, nicht bereits während des Reviews.

  1. 1

    Keine Wiederverwendung von Komponenten

    Dieselbe Karte, die auf fünf Screens konvertiert wird, wird zu fünf unabhängigen Implementierungen. Es gibt keine Verknüpfung, sodass eine Änderung an der Karte fünf Änderungen erfordert – und jemand wird nur vier davon finden.

  2. 2

    Überall Literalwerte

    Konverter geben #6b7280 aus, weil dies im Fill-Wert steht. Die Token-Ebene wird komplett umgangen, was bedeutet, dass das erstellte Designsystem auf diesen Screens nur noch dekorativen Charakter hat.

  3. 3

    Absolutes oder fragiles Layout

    Positionsdaten werden zu Positionierungen. Das Layout entspricht exakt der Breite des Frames, bricht aber bei jeder anderen Breite ein – und dieser Effekt ist auf den Geräten am schlimmsten, die am wenigsten getestet wurden.

  4. 4

    Keine Semantik

    Großer, fetter Text wird zu einem gestylten div. Screenreader erhalten eine Seite ohne Überschriftenstruktur, Tastaturbenutzer finden keine Orientierungspunkte, und niemand bemerkt es bis zum Audit.

Der zweite Punkt ist der folgenschwerste und im Review am wenigsten sichtbar. Sobald generierte Screens Literalwerte für Farben enthalten, besitzt die Codebasis zwei Farbsysteme: die Tokens und das, was die Designdatei an diesem Tag vorgegeben hat. Ein CI-Check, der bei Hex-Werten außerhalb der Token-Datei fehlschlägt, fängt dies direkt an der Tür ab.

Mapping schlägt Generierung

Der produktive Perspektivwechsel besteht darin, nicht mehr vom Tool zu verlangen, Code zu schreiben, sondern ihm zu sagen, welcher Code bereits existiert. Figma Code Connect tut genau das: Es verknüpft eine Design-Komponente mit der tatsächlichen Code-Komponente, sodass der Dev Mode die echte Komponente und deren Props anzeigt statt generiertes CSS.

Dadurch verschiebt sich das Problem von der Generierung hin zum Lookup – und Lookup ist ein Problem, das korrekt gelöst werden kann.

GenerierenMappen
ErzeugtNeues Markup, das den Frame annähertEinen Verweis auf die bereits gewartete Komponente
WiederverwendungKeine – jede Konvertierung ist neuVollständig, systembedingt
TokensUmgangen; Literalwerte werden ausgegebenBeibehalten; die Komponente nutzt sie bereits
BarrierefreiheitWas auch immer der Konverter abgeleitet hatWas auch immer die Komponente bereits leistet
EinrichtungsaufwandKeinerEin Mapping pro Komponente, wird bei Änderungen an Komponenten aktualisiert
Scheitert, wennImmer, schleichendEin Design etwas verwendet, das im Code noch nicht existiert
Zwei Wege von der Designdatei zum Code.

Die letzte Zeile zeigt die ehrlichen Kosten, und diese sind real: Mapping funktioniert nur für Komponenten, die existieren. Ein wirklich neues Design muss weiterhin gebaut werden. Aber das ist die korrekte Arbeitsteilung – ein Mensch oder ein Agent baut die neue Komponente einmal, und jede weitere Verwendung ist ein Verweis statt einer erneuten Generierung.

Das Ziel des Mappings sollte konkret definiert sein. Ein Handoff ist abgeschlossen, wenn die Code-Seite so aussieht – benannte Rollen mit realen Werten – und nicht wie eine Liste von Hex-Werten, die aus einem Frame extrahiert wurden:

Preview unavailable here. Browse complete kits in the kit gallery.

Die Strategie der Namensparität

Unter dem Komponenten-Mapping liegt eine kostengünstigere Änderung, die einen überraschend großen Teil der Lücke schließt und keinerlei Tooling erfordert: Verwenden Sie an beiden Stellen dieselben Namen.

Salesforce's SLDS 2 ist das klarste veröffentlichte Beispiel. Seine Figma-Library verwendet dieselben semantischen Styling-Hook-Namen wie das CSS – die eigenen Beispiele des Teams sind radius-border-4 und font-scale-4 – sodass Designs eins zu eins auf den Live-Code abgebildet werden können. Das erklärte Ziel ist ein gemeinsames Vokabular, das Design und Entwicklung überbrückt.

Das Ergebnis ist, dass eine ganze Kategorie von Handoff-Bugs verschwindet. Wenn ein Designer font-scale-4 sagt und ein Entwickler font-scale-4 tippt, gibt es keinen Übersetzungsschritt, sodass keine Bedeutung verloren gehen kann. Vergleichen Sie das mit einem Figma-Style namens "Heading / Large", der auf eine CSS-Variable namens --text-2xl abgebildet wird: Jeder Handoff ist ein Suchvorgang, und jeder Suchvorgang kann fehlschlagen.

Nicht übereinstimmendÜbereinstimmend
HandoffEin Übersetzungsschritt pro EigenschaftDen Namen kopieren
Überprüfen„Ist das das richtige Grau?“ erfordert das Öffnen beider ToolsDer Name ist entweder richtig oder er ist es nicht
Ein Agent, der beide liestZwei Vokabulare, keine explizite Beziehung, stilles RatenEin Vokabular
Wo Namensdiskrepanzen Kosten verursachen.

Wenn Sie nur eine Sache aus diesem Artikel umsetzen, dann benennen Sie Ihre Figma-Variablen so um, dass sie exakt mit Ihren CSS-Custom-Properties übereinstimmen. Es kostet einen Nachmittag, benötigt kein Plugin und eliminiert eine permanente Steuer auf jeden Handoff. Flache, kleingeschriebene, durch Bindestriche getrennte Namen überstehen beide Tools problemlos – mehr über Benennung für Portabilität.

Wenn das Designsystem in Figma lebt

Viele Teams verfügen über eine umfassende Figma-Library und eine Codebasis, die diese nur teilweise widerspiegelt. Der Instinkt ist, ein Tool zu finden, das die Lücke automatisch schließt. Es gibt eine günstigere Methode, die besser funktioniert.

Eine Figma-Library enthält die Entscheidungen – die Skalierung, die Rollen, das Komponentenset, den Spacing-Rhythmus. Diese Entscheidungen lassen sich perfekt als Text übertragen, und Text ist das Format, mit dem sowohl ein Entwickler als auch ein Coding-Agent arbeiten können. Die Extraktion in eine Token-Datei plus ein schriftliches Briefing dauert einen Arbeitstag und macht jede nachfolgende Konvertierung überflüssig, da die Code-Seite nun über dieselben Informationen verfügt wie die Design-Seite.

Wir haben 299 DESIGN.md-Dateien untersucht, die geschrieben wurden, um genau diese Informationen an KI-Agenten zu übermitteln, und die meisten erfüllen dies nicht: 86 % geben Farben als rohe Hex-Werte ohne semantische Rolle an, 76 % geben keine Verbote an, 69 % definieren keinen Dark Mode und 44 % geben nirgendwo einen konkreten Größenwert an. Ein Briefing, das korrekt aus einer echten Figma-Library extrahiert wurde, schlägt fast alle von ihnen – Sie kennen die Zahlen bereits.

  1. 1

    Exportieren Sie die Variablen als Tokens mit Rollen

    Nicht die rohe Palette. Die Rollen: Welche Farbe ist für Muted Text, welche für einen Border, welche für einen Disabled State. Wenn Ihre Figma-Variablen nach Farbton benannt sind, ist dies der Moment, sie an beiden Stellen gleichzeitig nach Rollen umzubenennen.

  2. 2

    Schreiben Sie die Skalierungen als Zahlen auf

    Schriftgrößen, Spacing-Schritte, Radien. Die Library enthält diese bereits; die Code-Seite hat meist nur eine Teilmenge plus Improvisation.

  3. 3

    Schreiben Sie auf, was die Library nicht tut

    Die Verbote sind in der Library implizit enthalten – keine Schatten irgendwo, keine Strichstärke über 600 – und sie sind das wertvollste Element, das explizit gemacht werden muss, da sie für jede automatisierte Extraktion unsichtbar sind.

  4. 4

    Mappen Sie die Komponenten, die bereits im Code existieren

    Erst jetzt lohnt sich der Einsatz von Tools, und zwar nur für Komponenten auf beiden Seiten. Alles, was nicht gemappt ist, ist ein Build-Aufwand, und zu wissen, was was ist, ist an sich schon nützlich.

Identity Forge Kits sind dieses Artefakt in vorinstallierter Form: 28 semantische Farbrole für Light und Dark, Typografie- und Spacing-Skalen, Motive sowie explizite Do's und Don'ts, exportierbar als CSS-Variablen, Tailwind @theme, als shadcn/ui Registry-Item oder DTCG/W3C JSON. Kits durchstöbern oder lesen Sie, wie man ein Briefing schreibt.

Was man von aktuellen Tools erwarten kann

Kalibrierte Erwartungen, nach Aufgabe:

Realistisches Ergebnis
Ein Wegwerf-Prototyp aus einem MockupGut. Strukturelle Schulden spielen keine Rolle bei Code, den man löschen wird
Extraktion von Maßen und WertenGut und unterschätzt. Die Inspektion im Dev Mode ist der langweilige, zuverlässige Gewinn
Ein neuer Screen unter Verwendung bestehender KomponentenGut mit konfiguriertem Mapping. Schlecht ohne dieses
Produktionsreifes Markup aus einem komplexen FrameSchlecht. Visuell nah dran, strukturell falsch, und die Bereinigung dauert meist länger als das Schreiben selbst
Konvertierung eines gesamten DesignsystemsKein Konvertierungsproblem. Stattdessen die Entscheidungen als Text extrahieren
Wo Design-to-Code-Tools ihren Platz verdienen.

Die zweite Zeile verdient mehr Anerkennung, als sie bekommt. Eine zuverlässige Inspektion — exakte Werte, echte Token-Namen, tatsächliche Komponenten-Props — beseitigt eine echte tägliche Reibung und behauptet nie, mehr zu leisten, als sie tatsächlich tut.

Kann KI Figma-Designs in Production-Code konvertieren?

Sie kann Code erzeugen, der wie der Frame aussieht. Ob dies Production-Code ist, hängt von der Struktur ab, und Struktur ist genau das, was ein Frame nicht enthält — Komponenten-Identität, semantische Rollen, responsivem Verhalten zwischen Breakpoints. Erwarten Sie ein visuell nahes, aber strukturell falsches Ergebnis und planen Sie Zeit für die Bereinigung ein.

Was ist Figma Code Connect?

Eine Funktion, die Design-Komponenten mit den tatsächlichen Code-Komponenten verknüpft, sodass der Dev Mode die echte Komponente und deren Props anstelle von generiertem CSS anzeigt. Dies verschiebt das Problem von der Generierung neuen Markups hin zur Referenzierung von bereits gewartetem Code, wodurch Wiederverwendbarkeit, Tokens und Accessibility-Arbeit erhalten bleiben.

Warum verwendet der Design-to-Code-Output hartkodierte Farben?

Weil die Füllung im Frame ein Wert ist und der Konverter keine Möglichkeit hat zu wissen, welche semantische Rolle dieser Wert spielt. Die Abstimmung der Figma-Variablennamen auf die CSS-Token-Namen gibt dem Tooling eine Referenz anstelle eines Hex-Codes.

Wie bringe ich mein Figma-Designsystem in den Code?

Nicht durch das Konvertieren von Screens. Exportieren Sie die Variablen als semantische Tokens mit zugewiesenen Rollen, halten Sie die Skalen als Zahlen fest, dokumentieren Sie, was die Library nicht leisten soll, und mappen Sie erst dann die Komponenten, die auf beiden Seiten existieren. Das ist ein Arbeitstag, der eine fortlaufende Konvertierung unnötig macht.

Sollten Designer und Entwickler dieselben Token-Namen verwenden?

Ja, und dies ist die Änderung mit dem höchsten Ertrag im Verhältnis zum Aufwand. Wenn ein Designer font-scale-4 sagt und ein Entwickler font-scale-4 tippt, gibt es keinen Übersetzungsschritt und somit keinen Raum für Bedeutungsverluste. Salesforce hat die Figma-Library von SLDS 2 genau auf dieser Parität aufgebaut.