Figma- und Code-Abstände synchron halten

Figma und Code bleiben bei den Abständen synchron, wenn keine Seite ihre eigene Liste pflegt: Eine generierte Skala wird an beide exportiert — als Figma Variables für die Design-Datei, als CSS Custom Properties oder Tailwind-Theme für die Codebasis — sodass Designer und Entwickler dieselben Werte aus derselben Quelle lesen. Plugins, Redline-Reviews und Lint-Regeln bekämpfen das Symptom; eine einzige Quelle beseitigt die Ursache.

Ohne diese Quelle folgt das Auseinanderdriften einem vorhersehbaren Drehbuch. Designer pflegen eine Abstandsliste in Figma; Entwickler pflegen eine andere in CSS. Niemand entscheidet sich bewusst fürs Divergieren — ein Abstand wird auf 20 geschoben, um eine überfüllte Card zu retten, eine 22 wird auf 24 gerundet, „um im Raster zu bleiben“ — und ein Jahr später ist ein Redline eine Verhandlung: Sind das nun 20 oder 24? Die ehrliche Antwort lautet oft „22 in der Datei, 20 in Produktion“.

Dieser Artikel behandelt, woher das Driften kommt, was Figma Variables sind, den Export-Workflow, mit dem eine Skala beide Seiten versorgt, und ein Audit für bestehende Produkte — die Design-zu-Code-Hälfte eines vollständigen Abstands-Systems.

Warum driften Figma- und Code-Abstandswerte auseinander?

Weil zwei Listen von Hand gepflegt werden, unter voneinander unabhängigem Druck. Die Design-Datei wird bearbeitet, um visuelle Probleme Frame für Frame zu beheben; das Stylesheet wird bearbeitet, um Layout-Bugs zu beheben und Inhalte unterzubringen. Jede Änderung ist lokal, nachvollziehbar und für die andere Seite unsichtbar. Keine einzelne Änderung ist ein Fehler — die Divergenz ist die Summe vieler korrekter Entscheidungen, die gegen zwei verschiedene Wahrheitsquellen getroffen wurden.

Man hört das Driften in Handoff-Gesprächen. Ein synchrones Team streitet darüber, welche Stufe ein Abstand sein sollte („das ist ein Abschnittswechsel, nimm die große Stufe“); ein gedriftetes Team streitet darüber, welchen Wert etwas hat („die Datei sagt 22, der Build sagt 20“). Wenn Messen die Bedeutung ersetzt, haben sich die Listen längst getrennt.

Was sind Figma Variables?

Figma Variables sind benannte Werte — eine Zahl wie space/3 = 16 — die anstelle roher Zahlen an Auto-Layout-Abstände und Padding gebunden werden können; Figmas Einführung in Variables erklärt die Mechanik. Binde den Abstand eines Frames an space/3, und der Frame folgt der Variable: Ändere die Variable einmal, und jeder gebundene Frame aktualisiert sich. Es ist das Design-Datei-Äquivalent einer CSS Custom Property — eine Referenz dort, wo früher eine Zahl stand.

Eine ehrliche Einschränkung: Variables machen die Design-Seite fähig, Abstands-Tokens zu lesen, aber eine von Hand getippte Sammlung von Variables ist immer noch eine von Hand gepflegte Liste. Die Synchronität entsteht daraus, diese Sammlung aus derselben Abstandsskala zu generieren, die auch der Code liest — nicht aus dem Feature selbst.

Wie versorgt eine Skala sowohl Design als auch Code?

Drei Schritte:

1. Generieren. Eine Skala aus drei Zahlen — Basis 16, Ratio 2, zwei Zwischenstufen pro Verdopplung — ergibt die Stufen 8, 11, 16, 23, 32, 45, 64.
2. In beide Richtungen exportieren. Dieselben Stufen gehen als Figma Variables in die Design-Datei und als CSS Custom Properties oder Tailwind-v4-@theme-Block in die Codebasis, mit DTCG-Tokens als neutralem Austauschformat.
3. Binden und referenzieren. Der Designer bindet Auto-Layout-Abstände und Padding an die Variables; der Entwickler referenziert die Custom Properties. Keine Seite tippt je wieder einen Pixelwert.

Öffne diese Skala mit dem Figma-Variables-Export im Blick — die sieben Stufen und die Namen, die sie in beide Umgebungen tragen.

Von hier an ist eine Abstandsänderung ein Upstream-Ereignis: Passe Basis oder Ratio einmal an, exportiere beide Seiten neu, und die Änderung kommt in der Design-Datei und im Build als dieselben Zahlen an. Die Redline-Verhandlung verschwindet, weil es lokal nichts mehr zu verhandeln gibt.

Wie misst du Abstands-Drift in einem bestehenden Produkt?

Inventarisiere die unterschiedlichen Abstandswerte auf jeder Seite und vergleiche. Im Code: Durchsuche die Stylesheets per grep nach margin-, padding- und gap-Werten und zähle die eindeutigen Ergebnisse; in Figma: Stichprobe die Abstände und das Padding über deine Kern-Screens. Ein typisches unsynchronisiertes Audit sieht ungefähr so aus: 41 unterschiedliche Werte in CSS, 13 in Figma, 9 davon geteilt. Die Zahl der Abweichungen ist die Drift, in einer einzigen Zahl — und das Audit ist zugleich der Migrationsplan: Ordne jeden bestehenden Wert seiner nächstgelegenen Skalenstufe zu (22 → 23; eine einsame 20 wird zur Ermessensfrage zwischen 16 und 23), und konvergiere dann Seite an Seite statt in einem einzigen Rewrite.

Garantiert das Synchronisieren der Werte konsistente Abstände?

Nein — und es lohnt sich, genau zu sein, was die Synchronität einbringt. Geteilte Exporte lösen die Werte: Beide Seiten sind sich jetzt einig, was existiert. Welche Stufe wohin gehört — Card-Padding versus Abschnittsabstand versus Icon-Abstand — ist Anwendungsdisziplin, und die bleibt menschliches Urteil auf beiden Seiten des Handoffs. Ein Designer kann die falsche Variable an einen Abstand binden, und sie wird getreu und konsistent auch im Code falsch sein.

Was die geteilte Quelle ändert: Die falsche Wahl wird sichtbar und benennbar. „Das sollte space-4 sein, nicht space-5“ ist ein Gespräch, das zwei Leute in einem Kommentar-Thread klären können, wo „sind das 20 oder 24?“ Archäologie war. Werte von der Maschine, Rollen durch Urteil — das ist die realistische Aufteilung.

Den Parity-Export einrichten

Beginne bei der Skala statt bei einer der beiden Listen: Generiere die Stufen, stelle dann die zwei Exporte nebeneinander — dieselben sieben Werte, einmal als Figma Variables und einmal als Tailwind-@theme-Block gerendert — und ändere die Ratio, um zuzusehen, wie sich beide gemeinsam aktualisieren. Diese gleichzeitige Bewegung ist das ganze Argument für eine einzige Quelle, sichtbar auf einem Bildschirm: öffne den Parity-Export in Scale Composer.