Variables, Themes und CSS-Integration ohne manuelle Übertragung
Wer Farben, Abstände und Typografie manuell zwischen Figma und Tailwind CSS synchronisiert, schafft Inkonsistenzen und Mehrarbeit. Design Tokens als Single Source of Truth verbinden Figma Variables direkt mit Tailwind CSS v4 – automatisch, skalierbar und Multi-Theme-fähig.
Inhaltsverzeichnis
- 1. Das Problem: Figma und Tailwind sprechen verschiedene Sprachen
- 2. Was Design Tokens wirklich sind – und was nicht
- 3. Figma Variables als Token-Quelle einrichten
- 4. Token-Export aus Figma: Plugins und Formate
- 5. Style Dictionary: Tokens transformieren und ausgeben
- 6. CSS Custom Properties in Tailwind CSS v4 registrieren
- 7. Multi-Theme-Support mit Tailwind CSS und CSS Layers
- 8. Pipeline automatisieren: CI/CD und Watch-Mode
- 9. Direktvergleich: Manuelle Pflege vs. Token-Workflow
- 10. Zusammenfassung
- 11. FAQ
1. Das Problem: Figma und Tailwind sprechen verschiedene Sprachen
In fast jedem Webprojekt, das mit Figma und Tailwind CSS arbeitet, entsteht früher oder später dasselbe Szenario: Der Designer ändert die Primärfarbe von #0369a1 auf #0284c7, und der Entwickler muss die Tailwind CSS-Konfiguration manuell nachziehen. Dieser manuelle Schritt ist fehleranfällig, langsam und skaliert nicht – spätestens dann nicht, wenn mehrere Designer und mehrere Entwickler gleichzeitig an einem wachsenden Design System arbeiten.
Das eigentliche Problem ist nicht die Farbe selbst, sondern der fehlende Mechanismus, der sicherstellt, dass Designentscheidungen automatisch und konsistent in Code überführt werden. Design Tokens lösen genau dieses Problem. Sie sind die gemeinsame Sprache zwischen Figma und Tailwind CSS – eine maschinenlesbare Schicht aus benannten Designwerten, die von beiden Seiten gelesen und verarbeitet werden kann. Wer diesen Workflow einmal eingerichtet hat, eliminiert eine ganze Klasse von Synchronisierungsfehlern aus seinem Entwicklungsprozess.
2. Was Design Tokens wirklich sind – und was nicht
Design Tokens sind benannte Abstraktionen über Designentscheidungen: Farben, Abstände, Schriftgrößen, Radien, Schatten und Animationszeiten. Der entscheidende Unterschied zu einer einfachen Variable: Ein Design Token trägt semantische Bedeutung. Statt #0369a1 heißt es color.action.primary.default. Der Wert kann sich ändern, ohne dass alle Verweise im Code aktualisiert werden müssen – nur der Token-Wert ändert sich, und der neue Wert propagiert automatisch durch das gesamte System.
Design Tokens sind keine Tailwind CSS-Klassen und keine Figma-Styles allein. Sie existieren als technologieneutrales Format – typischerweise als JSON oder YAML – das als Quelle für mehrere Ausgabeformate dient: CSS Custom Properties für Browser, Swift-Konstanten für iOS, XML-Resources für Android. In einer Tailwind CSS-Umgebung werden aus diesem Format CSS Custom Properties generiert, die dann direkt in der Tailwind CSS-Konfiguration referenziert werden. Die Tokens sind die Single Source of Truth; Figma und Tailwind CSS sind lediglich Konsumenten.
Die W3C Design Tokens Community Group hat 2024 einen formalen Standard für das Token-Format verabschiedet. Figma hat seine Variables-API daran ausgerichtet, und Style Dictionary unterstützt das Format nativ. Wer jetzt auf diesen Standard setzt, ist gut positioniert für die Zukunft der Design-System-Toolchain.
3. Figma Variables als Token-Quelle einrichten
Figma Variables, eingeführt mit Figma 2023, sind die native Implementierung von Design Tokens in Figma. Sie unterstützen vier Typen: Color, Number, String und Boolean. Für einen Design Token-Workflow mit Tailwind CSS sind die ersten zwei am wichtigsten. Die empfohlene Struktur folgt einer zweistufigen Architektur: Primitive Tokens definieren rohe Werte ohne Semantik (blue-600, space-4), während Semantic Tokens auf Primitive Tokens referenzieren und Bedeutung tragen (action-primary referenziert blue-600).
In Figma richtet man Collections für diese Ebenen ein: eine Collection namens "Primitives" mit allen Rohwerten und eine Collection "Semantic" mit allen bedeutungstragenden Aliases. Innerhalb jeder Collection können Modes definiert werden – Light und Dark für das Color Scheme, oder Brand-A und Brand-B für Multi-Brand-Setups. Diese Modes entsprechen später den Tailwind CSS-Themes. Jede Variable erhält einen hierarchischen Namen mit Slash-Trenner: color/action/primary/default, der später zu color-action-primary-default als CSS Custom Property wird.
/* Figma Variables → exported as W3C Design Token JSON */
/* tokens/primitives.json — raw values without semantic meaning */
{
"color": {
"blue": {
"100": { "$value": "#e0f2fe", "$type": "color" },
"600": { "$value": "#0284c7", "$type": "color" },
"900": { "$value": "#0c4a6e", "$type": "color" }
},
"neutral": {
"0": { "$value": "#ffffff", "$type": "color" },
"100": { "$value": "#f8fafc", "$type": "color" },
"900": { "$value": "#0f172a", "$type": "color" }
}
},
"space": {
"1": { "$value": "4px", "$type": "dimension" },
"4": { "$value": "16px", "$type": "dimension" },
"8": { "$value": "32px", "$type": "dimension" }
}
}
4. Token-Export aus Figma: Plugins und Formate
Figma bietet keine native Export-Funktion für Variables im W3C-Token-Format. Dafür existieren mehrere Plugins: "Variables to JSON" und "Tokens Studio for Figma" (ehemals Figma Tokens) sind die am weitesten verbreiteten. Tokens Studio bietet darüber hinaus eine bidirektionale Synchronisation mit GitHub, GitLab oder einem eigenen Token-Repository. Das bedeutet: Designer pushen Token-Änderungen direkt aus Figma in ein Git-Repository, und die CI-Pipeline verarbeitet sie automatisch zu CSS.
Für Teams ohne Tokens Studio reicht ein einfaches Plugin, das die Variables als JSON exportiert. Das resultierende JSON sollte dann versioniert im Projekt-Repository liegen, idealerweise unter tokens/. Wichtig beim Export: Die Referenzen zwischen Semantic und Primitive Tokens müssen erhalten bleiben, damit Style Dictionary die Alias-Auflösung korrekt durchführen kann. Exportiere nicht als flache Werteliste, sondern als hierarchisches JSON mit Referenzen ({ "$value": "{color.blue.600}" }).
5. Style Dictionary: Tokens transformieren und ausgeben
Style Dictionary von Amazon ist das Standard-Tool zum Transformieren von Design Tokens in plattformspezifische Ausgaben. Es liest das Token-JSON, löst Referenzen auf, wendet konfigurierbare Transforms an und schreibt Ausgabedateien. Für einen Tailwind CSS-Workflow ist die relevante Ausgabe eine CSS-Datei mit Custom Properties. Style Dictionary v4 unterstützt das W3C-Token-Format nativ und bietet eine moderne, konfigurationsbasierte API.
Die Konfiguration von Style Dictionary definiert, welche Token-Dateien gelesen werden, welche Transforms angewendet werden (z.B. Farben ins hex-Format konvertieren, Dimensionen in rem umrechnen) und welche Ausgabedateien erzeugt werden. Für Tailwind CSS v4 ist die ideale Ausgabe eine CSS-Datei, die im @layer theme Block eingebunden wird. Jede CSS Custom Property entspricht einem Design Token und ist direkt in Tailwind CSS-Utilities referenzierbar.
// style-dictionary.config.mjs — Token transformation pipeline for Tailwind CSS
import StyleDictionary from 'style-dictionary';
const sd = new StyleDictionary({
source: ['tokens/**/*.json'],
platforms: {
css: {
transformGroup: 'css',
prefix: 'ds',
buildPath: 'src/styles/tokens/',
files: [
{
// Output: CSS custom properties for Tailwind CSS integration
destination: 'primitives.css',
format: 'css/variables',
filter: token => token.filePath.includes('primitives'),
options: {
selector: ':root',
outputReferences: false,
}
},
{
destination: 'semantic.css',
format: 'css/variables',
filter: token => token.filePath.includes('semantic'),
options: {
// Preserve references so output reflects token hierarchy
selector: ':root',
outputReferences: true,
}
}
]
}
}
});
await sd.buildAllPlatforms();
// Result: --ds-color-action-primary-default: var(--ds-color-blue-600);
6. CSS Custom Properties in Tailwind CSS v4 registrieren
Tailwind CSS v4 hat einen fundamentalen Paradigmenwechsel vollzogen: Die Konfiguration findet nicht mehr in tailwind.config.js statt, sondern direkt in CSS via @theme. Das macht die Integration von Design Tokens als CSS Custom Properties wesentlich eleganter als in v3. Man importiert die von Style Dictionary generierten CSS-Dateien und registriert die Custom Properties als Tailwind-Theme-Werte mit dem --color-*, --spacing-* oder --radius-*-Pattern.
Der Mechanismus: Tailwind CSS v4 scannt den @theme-Block und erzeugt automatisch Utility-Klassen für alle definierten Variablen. Eine Variable --color-action-primary: var(--ds-color-action-primary-default) im @theme-Block erzeugt die Klassen bg-action-primary, text-action-primary, border-action-primary und alle anderen farbbezogenen Utilities. Das bedeutet: Der Designer ändert eine Farbe in Figma, die Token-Pipeline läuft, und sofort stehen aktualisierte Tailwind CSS-Klassen zur Verfügung – ohne eine Zeile Konfiguration manuell zu ändern.
/* src/styles/main.css — Tailwind CSS v4 entry with Design Token integration */
@import "tailwindcss";
/* Import Style Dictionary output — auto-generated from Figma Variables */
@import "./tokens/primitives.css";
@import "./tokens/semantic.css";
/* Register tokens as Tailwind CSS theme values */
@theme {
/* Map semantic tokens → Tailwind CSS utility names */
--color-primary: var(--ds-color-action-primary-default);
--color-primary-hover: var(--ds-color-action-primary-hover);
--color-secondary: var(--ds-color-action-secondary-default);
--color-surface: var(--ds-color-surface-default);
--color-on-surface: var(--ds-color-on-surface-primary);
/* Spacing tokens → Tailwind spacing scale */
--spacing-xs: var(--ds-space-1);
--spacing-sm: var(--ds-space-2);
--spacing-md: var(--ds-space-4);
--spacing-lg: var(--ds-space-8);
--spacing-xl: var(--ds-space-16);
/* Border radius tokens */
--radius-sm: var(--ds-radius-small);
--radius-md: var(--ds-radius-medium);
--radius-lg: var(--ds-radius-large);
--radius-full: var(--ds-radius-full);
}
/* Usage in HTML: class="bg-primary text-on-surface rounded-md p-md" */
7. Multi-Theme-Support mit Tailwind CSS und CSS Layers
Einer der größten Vorteile eines sauberen Design Token-Workflows mit Tailwind CSS ist die elegante Unterstützung mehrerer Themes. Dark Mode ist das einfachste Beispiel, aber der Mechanismus skaliert auf beliebig viele Themes: Brand A und Brand B, White-Label-Setups, saisonale Themes oder Barrierefreiheitsmodi mit erhöhtem Kontrast. Die Voraussetzung ist, dass alle Theme-abhängigen Werte als CSS Custom Properties definiert sind – was durch den Design Token-Workflow automatisch der Fall ist.
Figma Variables Modes exportiert Style Dictionary als separate Ausgabedateien. Der Light-Mode definiert die Custom Properties auf :root, der Dark-Mode überschreibt sie auf [data-theme="dark"] oder .dark. Tailwind CSS v4 bietet dafür die @variant dark-Direktive, die auf die vom Theme gewählte Strategie reagiert. Das Wechseln des Themes zur Laufzeit erfordert lediglich das Ändern eines Attributs oder einer Klasse am Root-Element – alle Tailwind CSS-Utilities greifen sofort auf die neuen Token-Werte zu.
8. Pipeline automatisieren: CI/CD und Watch-Mode
Der volle Nutzen des Design Token-Workflows entfaltet sich erst durch Automatisierung. In der lokalen Entwicklung überwacht ein Watch-Prozess die Token-JSON-Dateien und führt Style Dictionary bei Änderungen automatisch aus. Das Skript npm run tokens:watch kombiniert Style Dictionary im Watch-Modus mit dem Tailwind CSS-Build, sodass eine Token-Änderung innerhalb von Sekunden als aktualisierte CSS-Datei im Browser sichtbar ist.
In der CI/CD-Pipeline wird npm run tokens:build als erster Schritt vor dem CSS-Build ausgeführt. So ist sichergestellt, dass jeder Build stets aus den aktuellen Token-Werten erzeugt wird. Wenn Tokens Studio mit GitHub synchronisiert ist, löst ein PR des Designers, der Token-Werte ändert, automatisch die Build-Pipeline aus. Der Entwickler sieht im PR-Preview die visuellen Auswirkungen der Token-Änderung – ohne manuellen Eingriff. Diese vollständige Automatisierung ist das Ziel des gesamten Design Token-Workflows.
9. Direktvergleich: Manuelle Pflege vs. Token-Workflow
Der Unterschied zwischen manueller Farbpflege und einem automatisierten Design Token-Workflow mit Tailwind CSS zeigt sich besonders deutlich, wenn Designänderungen in die Produktion überführt werden müssen.
| Aspekt | Manuelle Pflege | Design Token Workflow | Vorteil |
|---|---|---|---|
| Farbänderung | Manuell in tailwind.config.js | Figma → Token-Export → CI | Kein manueller Schritt im Code |
| Dark Mode | Duplizierte Klassen | CSS Custom Properties + Modes | Eine Definition, mehrere Themes |
| Multi-Brand | Mehrere Tailwind-Configs | Token-Modes als CSS-Layer | Zentral gepflegt, beliebig skalierbar |
| Konsistenz | Abweichungen möglich | Single Source of Truth | Figma und Code immer synchron |
| Onboarding | Kenntnis der Config nötig | Tokens selbst dokumentierend | Semantische Namen erklären sich selbst |
Die Investition in den Design Token-Workflow lohnt sich ab dem zweiten Theming-Projekt. Wer einmal die Token-Pipeline aufgesetzt hat, kann jedes neue Projekt damit starten und spart bei jeder Designänderung Zeit, die bisher für manuelle Synchronisierung aufgewendet wurde. Teams, die Tokens Studio und Tailwind CSS v4 kombinieren, berichten von bis zu 80 % weniger Aufwand bei der Umsetzung von Design-System-Änderungen.
Mironsoft
Design Systems, Tailwind CSS und Figma-zu-Code-Workflows
Design Token Pipeline für euer Projekt aufsetzen?
Wir richten den vollständigen Figma-zu-Tailwind-CSS-Workflow ein: Variables, Style Dictionary, automatisierter Build und Multi-Theme-Support – damit Designänderungen nie wieder manuell in Code übertragen werden müssen.
Token-Audit
Analyse bestehender Figma Files und Tailwind-Konfigurationen auf Token-Potenzial
Pipeline Setup
Figma Variables, Style Dictionary, Tailwind CSS v4 und CI-Integration aufsetzen
Multi-Theme
Dark Mode, Brand-Themes und Accessibility-Modi als Token-Modes implementieren
10. Zusammenfassung
Der Tailwind CSS-Figma-Design-Token-Workflow eliminiert manuelle Synchronisierung zwischen Design und Code. Figma Variables werden als W3C-konforme Token exportiert, von Style Dictionary in CSS Custom Properties transformiert und direkt in Tailwind CSS v4 als Theme-Werte registriert. Das Ergebnis: Jede Änderung in Figma propagiert automatisch durch die gesamte Frontendcodebasis, ohne dass ein Entwickler eine Konfigurationsdatei anfassen muss.
Die Schlüsselkomponenten sind: Figma Variables mit einer Primitive/Semantic-Struktur, ein Token-Export-Plugin, Style Dictionary für die Transformation, Tailwind CSS v4 mit @theme-Integration und eine automatisierte Build-Pipeline. Multi-Theme-Support – von Dark Mode bis Multi-Brand – ist in diesem Workflow kein Sonderfall, sondern eine natürliche Konsequenz der CSS Custom Properties-Architektur. Teams, die diesen Workflow einführen, berichten von signifikant reduzierten Reibungsverlusten zwischen Design und Entwicklung.
Design Token Workflow mit Tailwind CSS — Das Wichtigste auf einen Blick
Token-Struktur
Primitive Tokens (Rohwerte) + Semantic Tokens (Bedeutung) in Figma Variables – zweistufige Architektur als Single Source of Truth.
Style Dictionary
Transformiert W3C-Token-JSON zu CSS Custom Properties. Löst Referenzen auf, rechnet Einheiten um, unterstützt mehrere Ausgabeformate parallel.
Tailwind CSS v4
CSS Custom Properties im @theme-Block registrieren – erzeugt automatisch alle Utility-Klassen. Kein manuelles tailwind.config.js mehr.
Multi-Theme
Figma Variable Modes → separate CSS-Dateien → Theme-Selector ([data-theme]). Dark Mode und Multi-Brand ohne Utility-Duplikation.