Bild: Mit KI generiert

Design Tokens in Figma werden in professionellen Designteams seit Jahren diskutiert. Was sich zuletzt verändert hat, ist die Infrastruktur drumherum: Die Spezifikation der W3C Design Tokens Community Group hat bis 2025 einen Reifegrad erreicht, auf den zahlreiche Tool-Anbieter ihre Implementierungen aufbauen. Figma Variables sind die native Umsetzung dieses Konzepts im Tool. Und ein neuer Kontext hat das Thema zusätzlich in den Vordergrund gerückt: KI-generierter Code produziert per Default häufig generische Werte statt Markenwerte – und Design Tokens gehören zu den zuverlässigsten Möglichkeiten, diese Konsistenz über Design und Code hinweg sicherzustellen.

Wer heute Browser Apps und SaaS-Interfaces entwickelt, braucht ein Token-System nicht, weil es professionell aussieht, sondern weil Interfaces ohne eine konsistente Token-Architektur immer schwieriger zu warten und weiterzuentwickeln sind. Farbabweichungen zwischen Screens, inkonsistente Abstände oder ein Dark-Mode-Update, das Hunderte von Layers manuell anfassen müsste, sind typische Symptome eines fehlenden Designsystems.

In diesem Artikel erfährst du, warum Figma Variables die native Implementierung von Design Tokens sind, wie die Drei-Ebenen-Hierarchie aus Primitive, Semantic und Component Tokens aufgebaut wird, welche Benennungskonventionen langfristig skalieren und warum Token-Systeme 2026 auch für KI-gestützte Entwicklung zunehmend an Bedeutung gewinnen.

 

Design Tokens in Figma: Variables sind die native Umsetzung von Design Tokens

Eine häufige Verwirrung zuerst: Figma Variables sind keine Alternative zu Design Tokens, sondern Figmas native Implementierung dieses Konzepts. Design Tokens existieren unabhängig von Figma – beispielsweise als JSON-Dateien, CSS Custom Properties oder in Tools wie Style Dictionary. Eine Figma Variable ist der technische Behälter, mit dem dieses Konzept innerhalb von Figma umgesetzt wird.

Was das in der Praxis bedeutet: Ein Token-Change in einer Figma-Datei kann sich über Tools wie Style Dictionary auf iOS, Android und Web ausbreiten, ohne dass Werte manuell aktualisiert werden müssen. Genau darin liegt das eigentliche Wertversprechen: nicht nur Ordnung innerhalb einer Figma-Datei, sondern eine Single Source of Truth, die Design und Code miteinander verbindet.

Figma unterstützt vier Variable-Typen, die gemeinsam ein vollständiges Token-System ermöglichen:

• Color: Für Farben in Fills, Strokes und Effekten – Grundlage für Theming und Dark Mode.
• Number: Für Spacing, Sizing, Border Radius und weitere numerische Eigenschaften – Grundlage für Density Modes und Layout-Systeme.
• String: Für Textinhalte und Labels – hilfreich für Lokalisierung oder variable Inhalte innerhalb von Figma.
• Boolean: Für Sichtbarkeit, Zustände und einfache bedingte Logik in Prototypen.

Wer ausschließlich Color Variables nutzt, schöpft nur einen Teil des Potenzials des Systems aus.

 

Die Drei-Ebenen-Hierarchie: Warum ein Layer allein nicht reicht

Das häufigste Problem vieler Token-Systeme ist nicht die Benennung, sondern ihre flache Struktur: Komponenten greifen direkt auf Farb- oder Abstandswerte zu. Solche Systeme funktionieren in kleinen Projekten oft gut, stoßen aber spätestens beim zweiten Theme oder einem Rebranding an ihre Grenzen.

Ein produktionsreifes System besteht aus drei Ebenen.

Primitive Tokens

Primitive Tokens sind rohe Werte ohne fachliche Bedeutung. Sie definieren lediglich, was existiert: blue-600, spacing-16, radius-4.

Jede Farbe der Brand-Palette, jeder Abstandswert und jede Schriftgröße beginnt als Primitive Token. Diese Tokens dienen ausschließlich als Referenz für andere Ebenen und werden in der Regel nicht direkt auf UI-Elemente angewendet. Nach dem initialen Setup bleibt diese Collection meist langfristig stabil.

Semantic Tokens

Semantic Tokens bilden den wichtigsten Layer und werden in vielen Projekten dennoch übersprungen.

Sie benennen Primitive Tokens nach ihrer Funktion statt nach ihrem Aussehen:

• color/text/primary
• color/text/disabled
• spacing/layout/page
• radius/control
• elevation/card

Semantische Tokens beschreiben den Einsatzzweck eines Wertes und nicht dessen konkrete Ausprägung.

Der entscheidende Vorteil zeigt sich beispielsweise beim Dark Mode: Ändert sich die Zuordnung hinter color/text/primary, übernehmen alle Komponenten automatisch den neuen Wert, ohne angepasst werden zu müssen. Komponenten referenzieren ausschließlich semantische Tokens – niemals Primitive Tokens direkt.

Component Tokens

Component Tokens bilden eine optionale dritte Ebene.

Sie kommen vor allem dann zum Einsatz, wenn einzelne Komponenten unabhängig vom restlichen System steuerbar bleiben sollen:

• button/primary/background
• button/primary/text
• table/header/background

Dadurch lässt sich beispielsweise die Hintergrundfarbe sämtlicher Primary Buttons ändern, ohne gleichzeitig alle anderen Elemente anzupassen, die denselben semantischen Farb-Token verwenden.

Für viele SaaS-Produkte reichen Primitive- und Semantic-Tokens dauerhaft aus. Component Tokens werden häufig erst eingeführt, wenn Designsysteme wachsen oder mehrere Produktteams gemeinsam daran arbeiten.

 

Benennungskonventionen: Was 2026 als Standard gilt

Tokens in Figma werden typischerweise nach einem Kategorie/Rolle/Variante-Muster benannt. So könnte ein Farb-Token für eine primäre Aktion color/action/primary heißen, und ein deaktiviertes Button-Label color/text/disabled.

Diese Regel hat eine direkte Konsequenz, die über Ästhetik hinausgeht:

text-secondary überlebt ein Rebranding. gray-text nicht.

Ein Token, das nach seinem Aussehen benannt ist, muss bei jedem Rebranding manuell überprüft werden, ob der Name noch stimmt. Ein Token, das nach seiner Rolle benannt ist, muss nie umbenannt werden — nur der Wert dahinter ändert sich.

Die Spezifikation der W3C Design Tokens Community Group hat sich bis 2025 als gemeinsame Grundlage vieler Toolchains etabliert. Die $value- und $type-Syntax ist inzwischen der De-facto-Standard für den Export aus Figma. Was das bedeutet: Eine Token-Datei aus Figma kann von Style Dictionary konsumiert, in Tailwind-Config transformiert und von der CI-Pipeline gelesen werden — ohne Custom-Glue-Code. Diese Interoperabilität war vor 2025 nicht selbstverständlich.

 

Modes: Dark Mode, Multi-Brand und Density ohne Komponentenduplizierung

Modes sind der Layer, der den Token-Ansatz von einem Ordnungssystem zu einem echten Effizienzgewinn macht. Jede Figma Variable Collection unterstützt mehrere Modes — jeder Mode ist im Wesentlichen eine Spalte in der Variables-Tabelle. text-primary bleibt im Light Mode und im Dark Mode derselbe Token-Name, zeigt aber auf unterschiedliche Werte: im Light Mode auf gray-900, im Dark Mode auf gray-100.

Das eliminiert einen der größten Aufwände in SaaS-Projekten: Keine separaten Komponenten-Sets für Light und Dark. Keine manuelle Pflege paralleler Figma-Dateien. Ein Mode-Switch in einem Frame aktualisiert alle Token-Werte in diesem Kontext sofort.

Modes sind nicht auf Light/Dark beschränkt. Drei weitere Anwendungsfälle, die in Browser App und SaaS-Kontext besonders relevant sind:

• Multi-Brand: Jede Marke bekommt einen eigenen Mode, der Primitive-Werte überschreibt. Farben und Typografie unterscheiden sich pro Brand, Komponentenlogik bleibt geteilt
• Density: Ein CompactMode mit reduzierten Spacing-Values neben einem ComfortableMode — der Unterschied zwischen einer dichten Datentabelle und einem großzügigeren Dashboard-Layout, ohne Komponenten neu zu bauen
• Plattform: iOS-spezifische Corner-Radius-Werte neben Web-Werten, weil beide Plattformen unterschiedliche Konventionen haben

 

Design Tokens und KI-generierter Code: Der 2026-Kontext

Dieser Aspekt ist neu und erklärt, warum das Suchinteresse für Design Tokens gerade so stark wächst.

In 2026 wird ein Großteil des UI-Codes von KI geschrieben oder assistiert. Das Problem: KI-Modelle sind auf das gesamte Internet trainiert, sodass sie auf generische Defaults zurückgreifen. Wenn Claude gebeten wird, eine Card-Komponente zu bauen, wählt es vernünftige Standardwerte — aber nicht die Markenwerte des Projekts.

Design Tokens lösen dieses Problem auf zwei Wegen. Wenn Tokens als CSS-Variablen oder Tailwind-Klassen im Codebase existieren, referenziert KI-generierter Code diese automatisch statt hardcodierter Werte. Das Ergebnis: Vibe-Coding-Output, der brand-konsistent ist statt generisch.

Der praktische Workflow, der sich 2026 etabliert hat: Tokens in Figma definieren, per Style Dictionary exportieren, als CSS Custom Properties in den Codebase integrieren. KI-Tools, die Code generieren, referenzieren dann var(--color-action-primary) statt #6366F1 — und die generierte UI sieht aus wie das eigene Produkt, nicht wie eine Demo.

Diese Verbindung ist direkt relevant für alle, die KI im Designprozess strukturiert einsetzen wollen: Ein Token-System ist die Infrastruktur, die Context Engineering auf Code-Ebene fortsetzt.

 

Take Away Message

Design Tokens in Figma sind 2026 keine optionale Disziplin für große Teams. Sie sind die Grundlage, auf der Browser Apps und SaaS-Interfaces skalieren — über Dark Mode, Multi-Brand und Density hinaus, bis hin zur Konsistenz von KI-generiertem Code. Die Drei-Ebenen-Hierarchie aus Primitive, Semantic und Component Tokens, kombiniert mit rollenbasierter Benennung und durchdachten Modes, ist der Punkt, an dem eine Figma-Datei aufhört, eine Sammlung von Screens zu sein, und anfängt, ein System zu sein. Den Aufwand lohnt sich einmal investieren — danach zahlt er sich bei jeder Iteration aus.