Design Tokens einfach erklärt:
Die Brücke zwischen Design und Code.

Was sind Design Tokens?

Ein Design Token ist eine kleine, plattformunabhängige Information, die eine Gestaltungsentscheidung beschreibt. Ein Token besitzt mindestens einen Namen und einen Wert. Häufig kommen Typ, Beschreibung, Referenzen und Metadaten hinzu. Tokens können Farben, Abstände, Schriftgrößen, Radien, Schatten, Dauer oder andere wiederkehrende Eigenschaften abbilden.

Der entscheidende Unterschied zu einer einfachen CSS-Variable liegt in der Abstraktion. Eine CSS-Variable ist eine konkrete technische Umsetzung für das Web. Ein Design Token kann dagegen aus einer gemeinsamen Quelle in CSS, iOS, Android, Dokumentation oder Designwerkzeuge übersetzt werden.

Die Design Tokens Community Group des W3C arbeitet an einem herstellerunabhängigen Format, mit dem solche Informationen zwischen Werkzeugen ausgetauscht werden können. Die stabile Spezifikation von 2025 schafft dafür eine gemeinsame technische Grundlage.

Drei Ebenen machen Tokens verständlich.

Ein belastbares Token-System trennt Rohwerte von ihrer Bedeutung und von konkreten Komponenten. Die genaue Benennung variiert zwischen Organisationen, das Prinzip bleibt jedoch ähnlich.

Primitive oder globale Tokens

Primitive Tokens bilden die verfügbaren Grundwerte ab: eine Farbskala, Schriftfamilien, Größen oder ein Abstandsmaß. Namen wie blue.600, space.300 oder font.size.500 beschreiben den Wert, aber noch nicht seine Aufgabe.

Semantische Tokens

Semantische Tokens benennen eine Funktion: color.text.primary, color.surface.raised oder space.section. Ihr Wert verweist meist auf ein primitives Token. Ändert sich ein Theme, kann die Bedeutung gleich bleiben, während die zugrunde liegende Farbe wechselt.

Komponenten-Tokens

Komponenten-Tokens werden verwendet, wenn eine konkrete Komponente eine bewusst eigene Entscheidung braucht, zum Beispiel button.primary.background.default. Sie bieten Präzision, können ein System aber schnell aufblähen. Deshalb sollten sie nur entstehen, wenn semantische Tokens die Anforderung nicht sinnvoll ausdrücken.

Diese Ebenen ermöglichen kontrollierte Veränderung. Ein neuer Markenfarbwert wird an einer primitiven Stelle angepasst. Ein Darkmode ordnet semantische Rollen anders zu. Eine besondere Button-Variante kann lokal reagieren, ohne alle Oberflächen zu beeinflussen.

Wie Design Tokens Design und Code verbinden.

Tokens sind nur dann wertvoll, wenn Teams dieselben Entscheidungen tatsächlich verwenden. Eine JSON-Datei allein schafft noch keine gemeinsame Sprache. Entscheidend ist ein Workflow, in dem Namen, Werte und Änderungen zwischen Designbibliothek, Code und Dokumentation synchron bleiben.

1. Eine verantwortliche QuelleEs muss klar sein, wo Tokens gepflegt und freigegeben werden.
2. Gemeinsame BenennungDesigner und Entwickler verwenden dieselben verständlichen Rollen statt werkzeugspezifischer Begriffe.
3. Automatische TransformationAus der Quelle entstehen Formate wie CSS Custom Properties, Swift, XML oder Dokumentation.
4. VersionierungÄnderungen sind nachvollziehbar, testbar und bei Bedarf als Breaking Change markiert.
5. Visuelle PrüfungAutomatisierte und manuelle Tests zeigen, welche Komponenten durch eine Änderung beeinflusst werden.
6. DokumentationBeschreibungen und Beispiele erklären den vorgesehenen Einsatz und bekannte Grenzen.

Für kleine Websites kann eine gut strukturierte CSS-Datei ausreichen. Der Aufwand für eine zentrale Token-Pipeline lohnt sich vor allem, wenn mehrere Produkte, Plattformen oder Teams dieselbe visuelle Sprache teilen.

Darkmode, Markenvarianten und Barrierefreiheit.

Theme-Fähigkeit ist einer der sichtbarsten Vorteile semantischer Tokens. Eine Oberfläche kann ihre Farbwerte ändern, während Komponenten weiterhin auf Rollen wie Text, Fläche, Rahmen und Aktion zugreifen. Das verhindert, dass jede Komponente eigene Darkmode-Sonderfälle erhält.

Auch mehrere Marken oder Produktlinien lassen sich so strukturieren. Die Komponentenlogik bleibt gemeinsam, während definierte Markenebenen Typografie, Farbe oder Radius anpassen. Das funktioniert allerdings nur, wenn Varianten systematisch geplant sind. Ein Token-System repariert keine unklaren Markenregeln.

Barrierefreiheit als Eigenschaft des Systems

Tokens können Kontrastentscheidungen sichtbar und überprüfbar machen. Textfarben sollten nicht unabhängig von ihren vorgesehenen Flächen definiert werden. Fokuszustände, Fehlermeldungen und deaktivierte Elemente brauchen ebenfalls ausreichende Wahrnehmbarkeit. Wichtig bleibt: Ein einzelner Farbwert ist nicht automatisch barrierefrei. Der Kontrast entsteht immer in einer Kombination.

Auch Bewegungsdauer, Fokusrahmen, Mindestgrößen und responsive Typografie können als systematische Entscheidungen dokumentiert werden. Tokens helfen dabei, gute Grundlagen zu verbreiten – die tatsächliche Komponente muss sie dennoch korrekt anwenden.

Design Tokens sinnvoll einführen.

1. Bestehende Werte inventarisieren

Ein Audit zeigt Farben, Größen und Abstände, die bereits im Produkt vorkommen. Ähnliche Werte werden gruppiert, aber nicht vorschnell zusammengelegt. Manchmal sehen zwei Werte ähnlich aus, erfüllen jedoch bewusst unterschiedliche Funktionen.

2. Mit einem begrenzten Bereich beginnen

Farben und Abstände sind häufig ein guter Start. Danach können Typografie, Radien, Schatten und Bewegung folgen. Ein kleines, verständliches System lässt sich besser testen als eine vollständige Taxonomie, die noch niemand im Alltag verwendet hat.

3. Semantik aus realen Anwendungen ableiten

Namen sollten aus Produktrollen entstehen: Text, Hintergrund, Aktion, Status, Fokus oder Trennung. Zu abstrakte Namen sind schwer anzuwenden, zu konkrete Namen verhindern Wiederverwendung. Ein Pilot mit echten Komponenten zeigt, ob die Ebene stimmt.

4. Migration planen

Bestehende Produkte werden selten in einem Schritt umgestellt. Sinnvoll ist eine schrittweise Migration entlang häufig genutzter Komponenten. Alte Werte werden markiert, neue Tokens dokumentiert und visuelle Änderungen kontrolliert veröffentlicht.

5. Verantwortung festlegen

Tokens betreffen Marke, Design und Technik. Änderungen brauchen deshalb einen transparenten Prozess. Wer darf neue Tokens anlegen? Wie werden Namen geprüft? Wie erfahren Teams von einer Anpassung? Ohne diese Antworten entstehen schnell wieder lokale Varianten.

Typische Fehler bei Design Tokens.

• Jeden Wert tokenisieren: Einmalige Layoutwerte brauchen nicht automatisch einen globalen Namen.
• Namen nach Aussehen wählen: greyText wird unverständlich, sobald das Theme eine andere Farbe benötigt.
• Zu früh zu viele Ebenen bauen: Komplexität sollte aus realem Bedarf wachsen.
• Figma und Code getrennt pflegen: Zwei Quellen erzeugen früher oder später Widersprüche.
• Änderungen ohne Auswirkungsprüfung: Ein globales Token kann viele Komponenten und Kontraste verändern.
• Tokens mit einem Design System verwechseln: Sie sind eine Grundlage, ersetzen aber keine Komponenten, Regeln oder Zusammenarbeit.

Design Tokens entfalten ihren Wert nicht durch technische Eleganz allein. Sie müssen Entscheidungen verständlicher machen, Wiederholung reduzieren und Veränderung kontrollierbar machen. Wenn ein Team länger über Token-Namen diskutiert, als es durch das System gewinnt, ist die Architektur wahrscheinlich zu kompliziert.

Ein kleines Token-System als Beispiel.

Angenommen, ein Produkt verwendet eine rote Markenfarbe, mehrere Grautöne und zwei Hintergrundebenen. Direkt in Komponenten eingetragene Hex-Werte würden zwar funktionieren, aber keine Bedeutung vermitteln. Eine dreistufige Struktur macht die Abhängigkeiten sichtbar.

Primitive Ebene

Die primitive Palette enthält neutrale Rohwerte wie red.600, grey.950, grey.700, grey.100 und white. Diese Namen sagen noch nichts darüber aus, ob eine Farbe für Text, Rahmen oder Aktionen gedacht ist.

Semantische Ebene

Darauf verweisen Rollen wie color.text.primary, color.text.muted, color.background.canvas, color.background.surface, color.border.subtle und color.action.primary. Komponenten verwenden möglichst diese Rollen. Im Darkmode können sie auf andere primitive Werte zeigen, ohne ihre Bedeutung zu verlieren.

Komponentenebene

Ein primärer Button kann für Hintergrund, Text, Rahmen und Fokus auf semantische Tokens verweisen. Nur wenn der Button eine begründete Ausnahme braucht, entsteht ein eigenes Komponenten-Token. Dadurch bleibt die Architektur nachvollziehbar und verhindert hunderte unnötige Namen.

Abstände und Typografie

Dasselbe Prinzip gilt außerhalb von Farben. Eine Abstandsreihe kann primitive Größen bereitstellen, während space.component.gap oder space.section.block ihre Aufgabe benennen. Typografie-Tokens können Schriftfamilie, Größe, Gewicht und Zeilenhöhe zu Rollen wie Überschrift, Fließtext oder Beschriftung kombinieren.

Das Beispiel zeigt auch eine Grenze: Nicht jeder Wert muss semantisch abstrahiert werden. Ein ungewöhnlicher Abstand in einer einzigen Illustration ist wahrscheinlich kein systemweiter Token. Wiederholung und strategische Bedeutung entscheiden über die Aufnahme.

Häufige Fragen zu Design Tokens.