Wenn ich ein Designsystem aus Figma in echte React‑Komponenten überführe, geht es mir nicht nur darum, Pixel zu reproduzieren. Ich will ein wartbares, wiederverwendbares System, das EntwicklerInnen und DesignerInnen gleichermaßen Freude macht. In diesem Artikel teile ich meinen pragmatischen Workflow, die Werkzeuge, die ich regelmäßig benutze, und die Fallstricke, auf die du achten solltest – inklusive konkreter Schritte zum Export von Design Tokens, Komponentenstrukturen und Integration in ein React‑Projekt.

Warum Designsysteme aus Figma nicht einfach “exportiert” werden

Viele erwarten, es gäbe einen Knopf “Export to React” und alles ist sauber. In der Realität liegt der Wert eines Designsystems nicht nur in Statics, sondern in der Semantik: Tokens, Varianten, Komponentenhierarchie, API‑Design der Komponenten (Props), Accessibility‑Verhalten, responsive Regeln und Tests. Figma ist großartig für visuelle Konsistenz; den Rest müssen wir bewusst modellieren.

Was ich zuerst exportiere: Design Tokens

Design Tokens sind die Grundlage. Sie definieren Farben, Abstände, Typografie, Radius, Schatten usw. und sind die abstrakte Ebene, die zwischen Figma und Code vermittelt.

Mein Workflow für Tokens:

  • In Figma: Styles für Farben, Text, Effekte und Grids sauber benennen (z. B. color/primary/500, font/heading/24).
  • Verwende ein Plugin wie Figma Tokens (von Jan Six) oder Tokens Studio, um Tokens in einer JSON‑Struktur zu pflegen.
  • Export: JSON/SCSS/JS — ich exportiere meist JSON, weil es in Toolchains wie Style Dictionary oder einem eigenen Skript einfach weiterverarbeitet werden kann.

    • Warum Style Dictionary? Es übersetzt Tokens in mehrere Plattformformate (CSS Variables, JS, iOS, Android). Das macht den reinen Export aus Figma portabel und reproduzierbar.

    Mapping: Tokens → CSS / CSS‑in‑JS / Tailwind

    Nachdem die Tokens im Projekt sind, musst du entscheiden, wie du sie verwendest:

  • CSS‑Variablen: gut für globales Theming und thematische Wechsel (Dark Mode).
  • CSS‑in‑JS (Styled Components, Emotion): erlaubt dynamische Props‑Bindung; ich nutze es, wenn Komponenten komplexe Variants haben.
  • Utility‑First (Tailwind): funktioniert, wenn du Tokens in Tailwind konfigurierst (tailwind.config.js) — aber das kann die Komponenten‑API verwässern.

    • Ich erstelle in der Regel eine Datei tokens.ts, die die Tokens als TypeScript‑Objekt exportiert. So habe ich Typensicherheit innerhalb der Komponenten.

    Komponentenstruktur aus Figma ableiten

    Bevor ich Code schreibe, strukturiere ich die Komponentenbibliothek nach Funktion:

  • atoms/ – Buttons, Inputs, Icons
  • molecules/ – InputGroup, CardHeader
  • organisms/ – Formular, DataTable
  • templates/ – Seitenlayouts
  • stories/ – Storybook‑Stories

    • Die Struktur mappe ich in Figma: Komponentenbibliothek sauber in Pages oder Haupt‑Frames gliedern, Naming Conventions einhalten (z. B. Button/Primary, Button/Secondary). So lassen sich Varianten leichter erkennen und automatisiert verarbeiten.

    Automatische Generierung von Komponenten

    Vollautomatisch perfekte React‑Komponenten zu erzeugen ist schwierig. Ich verwende Tools, die mir die repetitive Basisarbeit abnehmen:

  • Anima oder Figma‑to‑React Plugins: liefern schnellen JSX‑Output für einfache Interfaces.
  • Figma Tokens + Style Dictionary: wandeln Tokens in Variablen/JS um.
  • Storybook: ich importiere generierte Komponenten als Startpunkt und verfeinere sie dann manuell.

    • Die typische Pipeline: Tokens exportieren → Boilerplate‑Komponenten generieren → Komponenten manuell veredeln (Props, Accessibility, Tests) → Storybook dokumentieren.

    Wie ich Varianten in React übersetze

    Figma Variants sind Gold wert, weil sie UI‑Zustände in einer Gruppe konsistent abbilden. Ich übersetze Variants in React meist so:

  • Varianten als Props implementieren, z. B. <Button variant="primary" size="sm" />.
  • Intern mappe ich die Prop‑Kombinationen auf Klassen oder Styled‑Component‑Variations, nicht auf Inline‑Styles.

    • Wichtig: Grenzen der Varianten. Figma erlaubt beliebige Kombinationen; im Code solltest du nur die Kombinationen zulassen, die UI/UX wirklich benötigen. Typisierung (TypeScript) hilft, falsche Kombinationen zu verhindern.

    Accessibility, Interaktion und Behavior

    Design allein ist nicht ausreichend. In Figma kann ich Hover‑States und Focus zeigen, aber das Verhalten muss im Code implementiert werden:

  • Keyboard‑Navigation: focus states, role, aria‑attributes
  • Animationen: prefer reduced motion beachten
  • Formulare: Validierungen und Fehlerzustände

    • Ich schreibe Accessibility‑Checks direkt in die Komponente und ergänze Storybook‑Stories mit Accessibility Addons, damit Designer und EntwicklerInnen Verhaltensweisen in der Storybook‑Umgebung testen können.

    Testing und Dokumentation

    Ohne Tests verwässern Designintegrität und Refactoring‑Sicherheit. Meine Teststrategie:

  • Unit Tests für Komponenten‑Logik (React Testing Library + Jest)
  • Visual Regression Tests (Chromatic, Percy oder Loki), um Layout‑Drifts zwischen Figma‑Specs und Implementierung zu erkennen
  • Storybook als lebende Dokumentation: jede Komponente hat Stories, Variation und Beschreibung von Props

    • Storybook macht außerdem das Hand‑off zwischen DesignerInnen und EntwicklerInnen viel einfacher – man referenziert Stories beim Review.

    CI/CD und Sync mit Figma

    Ich habe gute Erfahrungen mit automatisierten Jobs gemacht:

  • Pre‑commit Hook: Validiert Tokens/Format
  • CI Pipeline: baut Storybook, führt Visual Tests aus
  • Deploy: Storybook wird bei Master‑Merge öffentlich gehostet (Netlify, Vercel)

    • Zusätzlich setze ich ein Watcher‑Skript auf, das Token‑Exports aus einem getrackten Figma‑Token‑Repo entgegennimmt und automatisch Style Dictionary laufen lässt. So sind UI‑Tokens immer synchron.

    Praktische Tipps aus der Praxis

  • Benennungskonventionen sind kein Nice‑to‑Have: investiere Zeit in konsistente Namen in Figma (BEM‑ähnlich oder designsystem‑spezifisch).
  • Keep it small: Exportiere zuerst die Basis‑Atoms. Wenn die stabil sind, baust du Molecules und Organisms darauf auf.
  • Use TypeScript: Typensicherheit verhindert viele API‑Fehler bei Props und Varianten.
  • Automatisiere wiederkehrende Aufgaben, aber plane manuelle Reviews ein — UI‑Nuancen brauchen menschliches Augenmaß.
  • Design‑Token‑Versionierung: behandle Tokens wie API‑Contracts. Breaking Changes müssen geplant werden.

    • Toolvergleich (kurz)

    Tool Stärken Schwächen
    Figma Tokens Flexibler Token‑Editor, JSON‑Export Benötigt Pipeline für Platform‑Builds
    Style Dictionary Plattformübergreifend, gut für Token‑Transformation Konfiguration kann komplex werden
    Anima / Figma‑to‑React Schnelle JSX‑Exports Generierter Code oft unzureichend für Produktion
    Storybook Dokumentation + Visual Tests Braucht Pflege und Stories schreiben Zeit

    Ein kurzes Beispiel: Button‑Token → React

    So könnte ein minimaler Flow aussehen:

  • Figma: Colors → color/primary/500
  • Figma Tokens → Export JSON → style-dictionary → token JS → tokens.ts
  • Button.tsx
  • const Button = ({ variant = 'primary', children }) => <button className={styles[variant]}>{children}</button>

    • Natürlich würde ich Styled Components oder CSS Modules bevorzugen, Props typisieren und Accessibility‑Attributes ergänzen. Aber der Kern bleibt: Token → stilistische Variablen → Komponenten‑API.

    Wenn du willst, kann ich dir einen Starter‑Repo‑Plan mit Scripts für Figma Tokens + Style Dictionary + Storybook zusammenstellen. Sag mir, welche Technologien du bevorzugst (CSS Modules, Emotion, Tailwind) — dann passe ich das Beispiel an.