Design Tokens
Von: Jonas Wenn Design- und Development-Teams (und KI-Agenten) gemeinsam und effizient Produkte umsetzen sollen, ist ein systematisch organisiertes Design-System Pflicht. Design Tokens sind das Fundament dafür, und seit Oktober 2025 gibt es mit dem W3C-Standard erstmals ein einheitliches Format. Wir fassen zusammen, was Tokens leisten, wie ihr sie strukturiert, benennt und konsistent haltet und wie sie in verschiedenen Systemen zum Einsatz kommen.
Design Tokens systematisieren die Charakteristika eines Designs. Entscheidungen zu Farben, Formen, Abständen, Schriftgrößen oder Animationen werden mittels Tokens dokumentiert und an zentraler Stelle organisiert. Menschen und Maschinen können sie schnell finden, auslesen und die korrekte Verwendung verstehen, was die Konsistenz eines Produkts verbessert und die Umsetzungsgeschwindigkeit erhöht.
Design Tokens bilden das Fundament eines Design Systems und zählen neben Konzepten wie Mobile First, Atomic Design und Progressive Enhancement zu zentralen Konzepten bei der Gestaltung digitaler Produkte. Seit Oktober 2025 existiert ein W3C-Community-Standard, der bereits von zahlreichen Design-Tools unterstützt wird.
Was sind Design Tokens?
In einem digitalen Design-Projekt wie einer Website oder Applikation müssen viele Entscheidungen getroffen werden und die meisten werden aus Gestaltgesetzen abgeleitet und folgen einer visuellen Hierarchie: Größere Elemente sind wichtiger als kleine; kräftigere Farben werden stärker wahrgenommen als blasse; geringe Abstände zwischen Elementen erzeugen Zusammengehörigkeit, größere Abstände schaffen inhaltlich Distanz.
Innerhalb des Projekts wiederholen sich diese Entscheidungen: Welche Farbe hat ein bestimmter Button? Wie groß ist der Abstand zwischen zwei Buttons? Welche Abrundung hat der Button und welche Abrundung das Objekt in dem der Button platziert ist?
Design Tokens geben diesen Werten einen Namen. Statt beispielsweise den Farb-Code #007c86 (petrol) direkt zu verwenden, referenziert ihr einen Token wie button-primary-bg. Der konkrete Wert wird zentral gepflegt und kann sich ändern, ohne dass jede Verwendungsstelle einzeln angepasst werden muss.
Typische Token-Kategorien
Welche Tokens notwendig sind, hängt vom Projekt ab. Die folgenden Kategorien werden am häufigsten verwendet:
- Farben (Colors)
- Schrift (Fonts)
- Abstände (Spacing)
- Abrundungen (Radius)
- Schatten (Shadows / Elevation)
- Animationen (Timing)
- …
Organisation von Design Tokens
Die Token-Struktur sollte in erster Linie zum Projekt und dem Team passen, das am Projekt arbeitet. Teams mit überschaubarem Know-how und kleine Projekte profitieren möglicherweise nicht (zumindest nicht wirtschaftlich) von zu komplex geplanten Strukturen.
Nichtsdestotrotz haben sich bei der Organisation und Benennung von Design Tokens mittlerweile klare Industriestandards entwickelt. Die folgende Vorgehensweise ist sehr verbreitet.
Abstraktionsebenen von Design Tokens
Design Tokens werden in verschiedenen Ebenen (auch Gruppen, Collections) organisiert. Diese Ebenen beziehen sich aufeinander und abstrahieren Tokens dadurch. In der Praxis haben sich folgende Ebenen etabliert:
- Primitive Tokens (auch Base Tokens) definieren die reine Palette. Die Benennung der Tokens orientiert sich am jeweiligen Wert. Z.B.
blue-600,radius-8,spacing-16. Die primitiven Tokens beschreiben was ein Wert ist, nicht wofür er eingesetzt wird. - Semantic Tokens (auch Alias Tokens) geben einem primitiven Wert eine Bedeutung. Sie beschreiben wofür ein Wert verwendet wird:
color-background,color-action,font-size-heading. - Component Tokens verbinden einen semantischen Wert mit dem konkreten UI-Element. Sie beschreiben wo genau ein Wert zum Einsatz kommt:
button-background,card-padding.
Die Ebenen referenzieren einander: blue-600 → color-action → button-background. Das wirkt zunächst nach Overhead, hat aber entscheidende Vorteile. Ändert sich im zuvor beschriebenen Beispiel z.B. der blaue Farbton des gesamten Systems, wird nur ein einziger primitiver Token angepasst (blue-600) und die Änderung vererbt sich durch alle Ebenen. Wenn die generelle Farbe für interaktive Elemente (Action Elemente) verändert werden soll, reicht die Anpassung des semantischen Tokens color-action. Soll hingegen nur der Button eine andere Farbe bekommen, wird nur dessen Component Token button-background geändert.
Die Ebene der semantischen Tokens wird nicht zwingend verwendet oder nur in Teilen. In solchen Fällen werden Primitives direkt auf Component Tokens »gemapped«. Semantische Tokens sollten vor allem dort verwendet werden, wo sog. »Modes« Sinn machen.
Modes (auch Kontext / Themes)
Ab der 2. Abstraktionsebene kommen die sog. Modes ins Spiel. Ein Mode wird dann relevant, wenn der Wert eines Tokens sich in verschiedenen Situationen ändern soll. Farben unterscheiden sich beispielsweise zwischen Light Mode und Dark Mode. Abstände und Schriftgrößen ändern sich häufig in Abhängigkeit zur Viewport-Größe. Im CSS-Code werden die Modes häufig mit Media Queries realisiert.
Benennung
Für die Benennung von Design Tokens gibt es keinen formalen Standard, aber eine gängige Praxis. Der Name eines Tokens setzt sich aus mehreren Segmenten zusammen, die von allgemein nach spezifisch angeordnet werden. Nicht jedes Segment kommt in jedem Token vor und die Reihenfolge weicht je nach System leicht ab.
- Namespace (optional): Ein Präfix für Systeme, Marken oder Themes
- Kategorie: die Art des Wertes, z.B.
color,spacing,font - Komponente: das konkrete UI-Element, z.B.
button,card - Variante: die Ausprägung, z.B.
primary,danger,subtle - Eigenschaft: wofür der Wert steht, z.B.
background,text,border - Zustand: der Interaktionszustand, z.B.
hover,focus,disabled - Skala: die Abstufung, z.B.
100bis900odersm/md/lg
Die Ordnung von allgemein nach spezifisch ist sinnvoll, da zusammengehörige Tokens so beieinander stehen und Ordnerstrukturen bei der Organisation von Tokens (z.B. in Figma) problemlos überführt werden können. In der Praxis werden dann beispielsweise folgende Namen verwendet:
- Primitive Tokens:
color-red-500 - Semantic Tokens:
color-danger - Component Tokens:
button-danger-background-hover,card-padding
Typische Fehler im Zusammenhang mit Design Tokens
Ein häufiger Fehler ist, visuelle Eigenschaften im Namen von nicht-primitiven Tokens zu kodieren. Ein Token wie button-red macht Ärger, sobald der Button nicht mehr rot ist.
Auch plattformspezifische Einheiten in Namen wie spacing-16px sollten vermieden werden. Der Wert 16px gehört in die Token-Definition, nicht in den Namen, da im Code z.B. nicht mit Pixeln, sondern mit der Einheit em gearbeitet wird. Namen müssen Bedeutung kommunizieren, keine Implementierungsdetails.
Lästig wird es auch, wenn die Benennung zu wenig Freiraum für Skalierung bietet. font-tiny oder font-largest machen es schwierig noch sinnvolle Namen oberhalb oder unterhalb der Liste zu finden.
Zuletzt müssen die Ebenen (Collections) so organisiert sein, dass die Tokens, die auf gleiche Modes reagieren, gruppiert sind. Nicht sinnvoll ist es beispielsweise, Farben und Abstände in einer Sammlung zusammenzufassen, da Farben i.d.R. nicht auf Modes wie »small« und »large« reagieren und Abstände nicht auf »Light Mode« und »Dark Mode«.
Beispiel: Eine Card in Light und Dark Mode
Schauen wir uns eine einfache Card mit Überschrift, Text und Button an. Die »Primitive Tokens« bilden die Palette, die »Semantic Tokens« ordnen die Werte einem Kontext zu.
Primitive Tokens (nur für das Beispiel relevante Angaben)
| Token | Wert |
|---|---|
colors/black | #000000 |
colors/white | #FFFFFF |
colors/gray-100 | #eeeeee |
colors/gray-900 | #1A1A2E |
colors/blue-400 | #6699FF |
colors/blue-600 | #0055FF |
spacing/space-2 | 0.5em |
spacing/space-4 | 1em |
Semantic Tokens inkl. Modes
| Token | Light Mode Referenz | Dark Mode Referenz |
|---|---|---|
background | → colors/white | → colors/black |
color-surface | → colors/gray-100 | → colors/gray-900 |
color-on-surface | → colors/gray-900 | → colors/white |
color-action | → colors/blue-600 | → colors/blue-400 |
color-on-action | → colors/white | → colors/white |
Component Tokens
| Token | Referenz |
|---|---|
body | → background |
card-bg | → color-surface |
card-text | → color-on-surface |
card-padding | → spacing/space-4 |
button-bg | → color-action |
button-text | → color-on-action |
button-padding-x | → spacing/space-4 |
button-padding-y | → spacing/space-2 |
Die Card- und Button-Komponente referenzieren jeweils nur *-surface, *-text und padding. Beim Wechsel zwischen Light und Dark Mode wird kein einziger Wert in der Komponente geändert, sondern nur die Zuordnung der Semantic Tokens zu den Primitives getauscht. Die Spacing-Tokens werden in der semantischen Palette übersprungen, da unser Beispiel keinen Mode für Spacings hat.
Wo »leben« Design Tokens?
In der Praxis kommen Design Tokens an verschiedenen Stellen zum Einsatz. Beispielsweise im Design-Tool und im Code. Daher ist es von zentraler Bedeutung, dass Tokens so organisiert sind, dass die verschiedenen Einsatzbereiche kompatibel sind und leicht aktualisiert werden können. In einem Design-Tool wie Figma werden Tokens beispielsweise als Variablen definiert. Im CSS-Code als CSS-Variablen. Als universelles Austausch-Format ist JSON etabliert und im Webstandard definiert.
Auch stellt sich die Frage nach der Single Source Of Truth (SSOT). Wo werden die Tokens zentral dokumentiert und wer »liest« die Tokens nur aus? In direktem Zusammenhang stehen auch Fragen zu Workflow und Verantwortung im Team: Wird im Design-Tool begonnen, im Code oder gar parallel?
Design First-Workflow
In den meisten Projekten ist das Design-Dokument die zentrale Stelle (SSOT) und definiert alle Variablen. Wenn das Projekt technisch umgesetzt wird, lesen Developer oder KI-Agenten die Variablen aus und übertragen sie auf die Code-Basis. Dieser Prozess ist weitestgehend automatisiert. Die Verantwortung liegt vorrangig im Design-Team.
Code First-Workflow
In Teams, die eine starke Frontend-Affinität aufweisen, ist oft der Code die SSOT. Die Tokens sind folglich im CSS oder JSON definiert und werden dort gepflegt. Wenn sie im Design-Tool benötigt werden, importiert man sie mittels Plugin oder KI (MCP).
Bidirektionaler Workflow (synced)
KI-gestützte und automatisierte Projekte erlauben auch das parallele Arbeiten und sog. bidirektionale Workflows. Sobald ein Token in Code oder Design verändert, gelöscht oder hinzugefügt wird, aktualisieren sich die jeweils andere Stellen automatisch.
Design Tokens im Web
Im Web werden Design Tokens typischerweise als CSS Custom Properties (CSS-Variablen) oder als Sass-Variablen umgesetzt. Das funktioniert Framework-unabhängig und eignet sich damit für kleine wie große Projekte gleichermaßen.
Der CSS-Code des zuvor gezeigten Card-Beispiels:
/* Primitive Tokens */
:root {
--color-black: #000000;
--color-white: #FFFFFF;
--color-gray-100: #eeeeee;
--color-gray-900: #1A1A2E;
--color-blue-400: #6699FF;
--color-blue-600: #0055FF;
--spacing-2: 0.5em;
--spacing-4: 1em;
}
/* Semantic Tokens – Light Mode (Default) */
:root {
--background: var(--color-white);
--color-surface: var(--color-gray-100);
--color-on-surface: var(--color-gray-900);
--color-action: var(--color-blue-600);
--color-on-action: var(--color-white);
}
/* Semantic Tokens – Dark Mode */
@media (prefers-color-scheme: dark) {
:root {
--background: var(--color-black);
--color-surface: var(--color-gray-900);
--color-on-surface: var(--color-white);
--color-action: var(--color-blue-400);
--color-on-action: var(--color-white);
}
}
/* Component Tokens */
:root {
--body: var(--background);
--card-bg: var(--color-surface);
--card-text: var(--color-on-surface);
--card-padding: var(--spacing-4);
--button-bg: var(--color-action);
--button-text: var(--color-on-action);
--button-padding-x: var(--spacing-4);
--button-padding-y: var(--spacing-2);
}
/* Components */
body {
background: var(--body);
}
.button {
background: var(--button-bg);
color: var(--button-text);
padding: var(--button-padding-y) var(--button-padding-x);
}
.card {
background: var(--card-bg);
color: var(--card-text);
padding: var(--card-padding);
}Die Komponenten erhalten keinen einzigen konkreten Styling-Wert. Alles wird über Variablen gesteuert. Beim Wechsel in den Dark Mode tauscht der Browser automatisch die Werte.
Design Tokens als W3C-Standard
Das Problem ohne Standard
Bis 2025 gab es kein einheitliches Format, in dem Design Tokens zwischen Tools ausgetauscht werden konnten. In der Praxis sah das so aus: Designer definierten Tokens in Figma oder einem anderen Design-Tool, Developer konvertierten sie in CSS Variablen. Bei Änderungen wurde der Prozess wiederholt.
Bei kleinen Projekten funktioniert das noch. Es wird aber schnell fehleranfällig, sobald mehrere Plattformen, Themes oder Marken im Spiel sind. Änderungen müssen in jedem Tool einzeln nachgezogen werden, und es gibt keine Garantie, dass die Werte überall identisch sind. Plugins und KI-Agenten haben den Prozess zwar deutlich vereinfacht, aber erst der Webstandard sorgt für einheitliche Prozesse.
Der W3C-Community-Standard
Im Oktober 2025 hat die Design Tokens Community Group (DTCG) die erste stabile Version eines offenen, herstellerneutralen Formats veröffentlicht. Die Spezifikation definiert ein JSON-basiertes Austauschformat, mit dem Tokens zwischen unterschiedlichen Tools kompatibel sind. Zu den ab Start beteiligten Organisationen gehören unter anderem Adobe, Google, Microsoft, Salesforce und Figma.
Ein einfaches Beispiel im W3C-Format (DTCG Standard):
{
"colors": {
"blue-600": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [0, 0.33, 1],
"hex": "#0055FF"
}
}
},
"color-action": {
"$type": "color",
"$value": "{colors.blue-600}",
"$description": "Primary interactive color"
}
}
Jeder Token hat einen $type (z.B. color, fontFamily, shadow), einen $value und optionale Metadaten wie $description. Tokens können über die Alias-Syntax {token-name} auf andere Tokens verweisen, was dem Prinzip der zuvor beschriebenen Abstraktionsebenen entspricht.
Die Spezifikation besteht aus drei Modulen: Das »Format Module« definiert die Grundstruktur für alle Token-Typen. Das »Color Module« definiert ein differenziertes Farbformat mit Unterstützung moderner Farbräume wie OKLCH und Display P3. Das »Resolver Module« beschreibt, wie kontextabhängige Varianten (Light/Dark, Marken, Gerätegrößen) organisiert werden, ohne Tokens zu duplizieren.
Konvertierung der W3C Tokens in das Ziel-Format
Tools wie Style Dictionary oder Terrazzo lesen Token-Dateien im W3C-Format (DTCG Standard) ein und generieren daraus den gewünschten plattformspezifischen Output. Im Ergebnis stehen dann z.B. CSS-Variablen für das Web oder Swift-Code für iOS zur Verfügung.
Design Tokens in gängigen Tools und Systemen
Die folgenden Systeme gehen Design Tokens unterschiedlich an, weil sie an verschiedenen Stellen des zuvor beschriebenen Workflows zum Einsatz kommen. Figma und Penpot sind Design-Tools, Tailwind CSS und Open Props liegen auf der CSS-Ebene. WordPress bringt als Plattform ein eigenes, vereinfachtes System mit. Anhand von Material Design zeigen wir abschließend, wie ein vollständiges Design System Tokens durchgängig organisiert.
Design Tokens in Figma
Figma hat mit »Variables« ein eigenes Token-System integriert. Variables können in sog. »Collections« organisiert werden und unterstützen pro Collection unterschiedliche »Modes« – also kontextabhängige Varianten wie Light und Dark. Die Variablen verschiedener Collections können sich auch gegenseitig referenzieren, wodurch die zuvor beschriebenen Abstraktionsebenen möglich sind.
Figma unterstützt nativ den Export und Import von Design Tokens im W3C-Format. Über Plugins, die Figma API oder den Figma MCP können Variablen in verschiedenen Formaten exportiert und in die Entwicklungs-Umgebung integriert werden. Auch der umgekehrte Weg ist möglich – wiederum über Plugins oder Schnittstellen. Figma bietet sich somit für unterschiedliche Workflows an: Design First, Code First oder bidirektional.
Gruppierte Tokens (Composite Tokens), die der Webstandard unterstützt, werden in Figma mittels »Styles« abgebildet. Da Styles allerdings nicht zusammen mit Variablen organisiert sind und folglich anders exportiert werden, ist dieses Feature suboptimal umgesetzt.
Design Tokens in Penpot
Penpot, die Open-Source-Alternative zu Figma, ist sehr Frontend-affin und hat Design Tokens tief im Tool verankert und W3C-konform umgesetzt. Anders als bei Figma wird direkt der Standard genutzt und nicht über eine Zwischenebene aus proprietären Variables oder Styles hergestellt, die dann beim Export konvertiert werden.
Ihr könnt in Penpot alle Abstraktionsebenen und zusammengefasste Tokens abbilden und in sog. »Sets« (Collections) sowie »Themes« (Modes) organisieren. Der Export erfolgt als natives W3C-JSON.
Design Tokens in Tailwind CSS
Tailwind CSS ist ein Token-ähnliches System, das in CSS-Variablen und Utility-Klassen überführt wird. Das Framework stellt eine sehr große Anzahl an primitiven Tokens zur Verfügung, deren Werte überschrieben werden können, um individuelle Anpassungen zu erlauben. Neben reinen Tokens wird allerdings auch das Layout-Verhalten auf gleiche Weise gesteuert, was die Organisation verwässert.
Eine vollwertige semantische Ebene mit Modes (z. B. Light/Dark) bietet Tailwind nicht. Einfache Alias-Tokens lassen sich per Referenzierung anlegen, komplexere Setups können durch Custom Code ergänzt werden. Im Markup werden Light-/Dark-Mode, Breakpoint-abhängige Schriftgrößen etc. über sog. »Variants« (dark:, md: …) angesprochen.
Design Tokens in Open Props
Open Props folgt dem Tokens-Prinzip, allerdings nur auf der Ebene der Primitive Tokens. Die CSS-Bibliothek liefert euch eine fertige Sammlung an CSS-Variablen für Farben, Abstände, Schriftgrößen, Schatten oder Animationen, organisiert in Skalen wie --blue-0 bis --blue-12. Eine Semantic- oder Component-Ebene bringt Open Props nicht mit, diese muss selbst gebaut werden.
Open Props-Tokens können im W3C-Format, als Figma-kompatible JSON-Datei und als Style-Dictionary-Tokens exportiert werden, sodass sich die primitive Ebene direkt in andere Tools übernehmen lässt.
Design Tokens in WordPress
WordPress nutzt bei sog. Block Themes ein Token-ähnliches, vereinfachtes System, das in der theme.json organisiert wird. In dieser zentralen Konfigurationsdatei werden Farben, Schriftgrößen und Abstände definiert, die WordPress automatisch in CSS-Variablen konvertiert. WordPress generiert z.B. Variablen wie --wp--preset--color--blue-400, die im Editor auswählbar und im Code referenzierbar sind.
Die theme.json ist kein vollständiges Äquivalent zum W3C-Standard. Es gibt z.B. keine eingebauten Abstraktionsebenen oder Modes. Ob die Tokens in der theme.json eher als Primitive Tokens oder als Semantic Tokens organisiert werden, ist den Theme-Entwicklern freigestellt. Wir haben uns in unserem Design System für WordPress für primitive Tokens entschieden und abstrahieren diese über »Styled Sections« oder »Blocks«.
Design Tokens in populären Designsystemen
Auch öffentlich dokumentierte Designsysteme sind eine gute Quelle, um die zuvor beschriebenen Konzepte an echten Beispielen nachzuvollziehen und zu vergleichen, wie Dinge im Code und im Design gelöst wurden.
- Material Design von Google zeigt die drei Abstraktionsebenen so sauber wie kaum ein anderes System.
- Atlassian hat viel Arbeit in die Benennung von Tokens gesteckt und die Anatomie eines Token-Namens ausführlich dokumentiert. Der Token Picker bietet einen guten Zugang in ein sehr komplexes System.
Fazit
Design Tokens sind das Fundament, auf dem Konsistenz und Wartbarkeit eines digitalen Produkts aufbauen. In kleinen Projekten funktioniert vieles noch ohne durchdachte Struktur. Die Probleme tauchen erst mit steigender Skalierung auf, wenn mehrere Personen zusammenarbeiten müssen, Komponenten, Modes oder Produkte hinzukommen und jede nachträgliche Korrektur teuer wird. Daher empfehlen wir, die Überlegungen zu Abstraktionsebenen, Benennung und Modes früh anzustellen.
Positiv ist die Entwicklung in zwei Bereichen: Mit dem W3C-Standard existiert erstmals ein herstellerneutrales Austauschformat, und KI-Agenten bzw. Automatismen übernehmen zunehmend die Übersetzung zwischen Design-Tool und Code. Beides zusammen wird den Weg von der Design-Entscheidung bis zum fertigen Code in Zukunft deutlich verkürzen.
Die konzeptionellen Entscheidungen, welche Tokens es gibt und wie diese sinnvoll organisiert sind, nimmt euch niemand ab. Und die Verantwortung für Tokens liegt zukünftig wahrscheinlich stärker beim gesamten Team und nicht nur bei einem Gewerk.
