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 Datei | Muss abgeleitet werden | |
|---|---|---|
| Struktur | Eine Gruppe von Rechtecken und Text an diesen Koordinaten | Dass diese Gruppe eine Card ist und dass es dieselbe Card ist, die auf neun anderen Screens verwendet wird |
| Farbe | Füllung ist #6b7280 | Ob es sich um gedämpften Text, einen Rahmen, einen deaktivierten Zustand oder einen Platzhalter handelt |
| Abstände | 32px zwischen diesen zwei Elementen | Ob 32 ein Skalenschritt, ein Einzelfall oder das Ergebnis eines manuellen Verschiebens ist |
| Responsivität | Constraints und alle existierenden Breakpoint-Frames | Was bei jeder Breite dazwischen passiert |
| Semantik | Text mit größerer Schriftgröße und stärkerem Schriftschnitt | Ob es ein h1, ein h2 oder gestalteter Text ist, der überhaupt keine Überschrift darstellt |
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 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
Keine Wiederverwendung von Komponenten
Dieselbe Card, die auf fünf Screens konvertiert wird, wird zu fünf unabhängigen Implementierungen. Da keine Verknüpfung besteht, bedeutet eine Änderung an der Card fünf einzelne Änderungen – und irgendwer wird nur vier davon finden.
- 2
Überall Literalwerte
Konverter geben
#6b7280aus, weil dies so in der Füllung steht. Die Token-Ebene wird komplett umgangen, was bedeutet, dass das erstellte Designsystem auf diesen Screens nur noch dekorativen Charakter hat. - 3
Absolutes oder fragiles Layout
Positionsdaten werden zu Positionierungen. Das Ergebnis entspricht dem Frame exakt bei dessen Breite, bricht aber bei jeder anderen Breite ein – und dieser Einbruch ist auf den Geräten am schlimmsten, die am wenigsten getestet wurden.
- 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
Die produktive Neuausrichtung 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.
| Generieren | Mappen | |
|---|---|---|
| Erzeugt | Neues Markup, das den Frame annähert | Einen Verweis auf die bereits gewartete Komponente |
| Wiederverwendung | Keine. Jede Konvertierung ist neu | Vollständig, konstruktionsbedingt |
| Tokens | Umgangen; Literale werden ausgegeben | Beibehalten; die Komponente nutzt sie bereits |
| Barrierefreiheit | Was auch immer der Konverter abgeleitet hat | Was auch immer die Komponente bereits leistet |
| Einrichtungsaufwand | Keiner | Ein Mapping pro Komponente, wird bei Änderungen an Komponenten aktualisiert |
| Scheitert, wenn | Immer, schleichend | Ein Design etwas verwendet, das im Code noch nicht existiert |
Die letzte Zeile zeigt die ehrlichen Kosten, und sie sind real: Mapping funktioniert nur für Komponenten, die existieren. Ein wirklich neues Design muss immer noch 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 echten Werten statt einer Liste von Hex-Werten, die aus einem Frame extrahiert wurden:
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 deutlichste veröffentlichte Beispiel. Die 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. 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 dies mit einem Figma-Style namens „Heading / Large“, der auf eine CSS-Variable namens --text-2xl abgebildet wird: Jeder Handoff ist ein Nachschlageprozess, und jeder Nachschlageprozess ist fehleranfällig.
| Nicht übereinstimmend | Übereinstimmend | |
|---|---|---|
| Handoff | Ein Übersetzungsschritt pro Eigenschaft | Namen kopieren |
| Prüfen | „Ist das das richtige Grau?“ erfordert das Öffnen beider Tools | Der Name ist entweder korrekt oder nicht |
| Ein Agent, der beides liest | Zwei Vokabularien, keine definierte Beziehung, stilles Raten | Ein Vokabular |
Wenn Sie eine Sache aus diesem Artikel umsetzen, benennen Sie Ihre Figma-Variablen so um, dass sie exakt Ihren CSS-Custom-Properties entsprechen. Es kostet einen Nachmittag, benötigt kein Plugin und eliminiert eine dauerhafte Belastung bei jedem Handoff. Flache, kleingeschriebene, mit Bindestrichen getrennte Namen funktionieren in beiden Tools: mehr zur Benennung für Portabilität.
Wenn das Designsystem in Figma lebt
Viele Teams verfügen über eine gründliche Figma-Library und eine Codebasis, die diese nur teilweise widerspiegelt. Der Instinkt ist, ein Tool zu finden, das diese Lücke automatisch schließt. Es gibt jedoch einen günstigeren Weg, der besser funktioniert.
Eine Figma-Library enthält die Entscheidungen: die Skalierung, die Rollen, den Komponentensatz, den Spacing-Rhythmus. Diese Entscheidungen lassen sich hervorragend als Text übertragen, und Text ist das Format, mit dem sowohl ein Entwickler als auch ein Coding-Agent arbeiten kann. Die Extraktion in eine Token-Datei plus ein schriftliches Briefing ist eine Tagesarbeit 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 analysiert, die genau diese Informationen an KI-Agenten übermitteln sollten, und die meisten tun dies nicht: 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 76 % nennen keine Verbote, 69 % definieren keinen Dark Mode und 44 % geben nirgendwo einen konkreten Größenwert an. Ein ordnungsgemäß aus einer echten Figma-Library extrahiertes Briefing schlägt fast alle diese Dateien. Die Zahlen liegen Ihnen bereits vor.
- 1
Variablen als Tokens mit Rollen exportieren
Nicht die reine Palette. Die Rollen: Welche Farbe ist gedämpfter Text, welche ist ein Rahmen, welche ein deaktivierter Zustand. Wenn Ihre Figma-Variablen nach Farbton benannt sind, ist dies der Moment, sie an beiden Stellen gleichzeitig nach ihrer Rolle zu benennen.
- 2
Skalierungen als Zahlen aufschreiben
Schriftgrößen, Spacing-Schritte, Radien. Die Library enthält diese bereits; die Code-Seite verfügt meist über eine Teilmenge plus Improvisationen.
- 3
Aufschreiben, was die Library explizit ausschließt
Die Verbote sind in der Library implizit enthalten (keine Schatten, keine Schriftstärken über 600) und sie sind die wertvollsten Informationen, die explizit gemacht werden müssen, da sie für jede automatisierte Extraktion unsichtbar sind.
- 4
Komponenten zuordnen, die bereits im Code existieren
Erst jetzt lohnt sich der Einsatz von Tooling, und auch nur für Komponenten, die auf beiden Seiten existieren. Alles nicht zugeordnete ist ein Neubau, und zu wissen, was was ist, ist an sich bereits nützlich.
Identity Forge Kits sind dieses Artefakt in vorgefertigter Form: 28 semantische Farbrollen für Light und Dark, Typografie- und Spacing-Skalen, Motive sowie explizite Do's und Don'ts, exportierbar als CSS-Variablen, Tailwind @theme, ein shadcn-Registry-Item oder DTCG/W3C JSON. Kits durchstöbern oder lesen Sie, wie man das Briefing schreibt.
Was von aktuellen Tools zu erwarten ist
Kalibrierte Erwartungen, nach Aufgabe:
| Realistisches Ergebnis | |
|---|---|
| Ein Wegwerf-Prototyp aus einem Mockup | Gut. Strukturelle Schulden spielen in Code, den man löschen wird, keine Rolle |
| Extraktion von Maßen und Werten | Gut und unterschätzt. Die Inspektion im Dev Mode ist der langweilige, aber zuverlässige Gewinn |
| Ein neuer Screen unter Verwendung bestehender Komponenten | Gut, wenn das Mapping konfiguriert ist. Schlecht ohne Mapping |
| Produktionsreifes Markup aus einem komplexen Frame | Schlecht. Visuell nah dran, strukturell falsch, und die Bereinigung dauert meist länger als das Neuschreiben |
| Konvertierung eines gesamten Designsystems | Kein Konvertierungsproblem. Stattdessen die Entscheidungen als Text extrahieren |
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, responsives Verhalten zwischen Breakpoints. Erwarten Sie ein visuell nahes, aber strukturell falsches Ergebnis und planen Sie Zeit für das Cleanup 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. Damit verschiebt sich das Problem von der Generierung neuen Markups hin zur Referenzierung von bereits gewartetem Code, wodurch Wiederverwendbarkeit, Tokens und Accessibility-Arbeit erhalten bleiben.
Warum verwendet 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. Erst die Abstimmung der Figma-Variablennamen auf die CSS-Token-Namen gibt dem Tool 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 explizit nicht tut, und mappen Sie erst dann die Komponenten, die auf beiden Seiten existieren. Das ist ein Arbeitstag Aufwand und macht fortlaufende Konvertierungen überflüssig.
Sollten Designer und Entwickler dieselben Token-Namen verwenden?
Ja, und dies ist die effektivste Änderung im Verhältnis zum Aufwand. Wenn ein Designer font-scale-4 sagt und ein Entwickler font-scale-4 tippt, entfällt der Übersetzungsschritt und somit gibt es keinen Raum für Bedeutungsverluste. Salesforce hat die Figma-Library von SLDS 2 genau auf dieser Parität aufgebaut.