Was sind Design Tokens?

Design Tokens sind Design-Entscheidungen, die als benannte Daten gespeichert werden. Jeder Token verbindet einen Namen mit einem Wert — brand-600 enthält genau ein Blau, space-4 genau einen Abstand — und die Tokens leben in einer werkzeugneutralen Datei, aus der jedes Zielformat generiert wird: CSS für das Web, Variablen für Figma, Ressourcen für nativen Code.

Diese Definition verdichtet drei Ideen, und jede trägt einen Teil des Gewichts: Ein Token ist eine Entscheidung mit einem Namen, Tokens werden über Referenzen zusammengesetzt, und das zusammengesetzte System wird an jeden Konsumenten exportiert. Dieser Artikel — das Eröffnungsstück unseres Design-Tokens-Leitfadens — baut die Definition Schritt für Schritt auf.

Was bedeutet „eine Design-Entscheidung mit einem Namen”?

Jedes Produkt sammelt Design-Entscheidungen an: Das Marken-Blau ist dieser Hex-Wert, der Fließtext ist 16px groß, Karten bekommen so viel Padding. Was variiert, ist der Ort, an dem diese Entscheidungen leben. In vielen Teams stecken sie im Gedächtnis einer Person, in einem Foliensatz oder in einem PDF-Styleguide — Orte, die ein Mensch lesen, aber nichts ausführen kann. Ein Token überführt die Entscheidung in Daten:

"brand-600": { "$value": "#2563eb", "$type": "color" }

Der Name ist der Griff der Entscheidung; der Wert ist ihre aktuelle Antwort. Sobald eine Entscheidung zu Daten wird, können Werkzeuge tun, was Werkzeuge tun: sie validieren, zwei Versionen davon vergleichen, Code daraus generieren, jede Stelle finden, an der sie verwendet wird. Ein PDF, das „primäres Blau, für Buttons verwenden” sagt, braucht einen menschlichen Interpreten; eine Token-Datei formuliert dieselbe Entscheidung in einer Form, auf die ein Build-Schritt reagieren kann.

Wie werden Tokens zu einem System?

Durch Referenzen. Der Wert eines Tokens kann der Name eines anderen Tokens sein, und dieser eine Mechanismus verwandelt eine flache Liste von Konstanten in zusammengesetzte Entscheidungen. Die verbreitete Konvention ist geschichtet: Semantische Tokens benennen Aufgaben und verweisen auf primitive Tokens, die Werte benennen —

"background": { "$value": "{neutral.50}",  "$type": "color" },
"accent":     { "$value": "{brand.600}",   "$type": "color" }

background → neutral-50 und accent → brand-600 sind eigenständige Entscheidungen, getrennt davon, was neutral-50 und brand-600 gerade speichern. „Der Akzent ist die Markenfarbe” und „die Markenfarbe ist dieses Blau” können sich jetzt unabhängig voneinander ändern: Ein Rebrand bearbeitet die zweite Aussage, ein Theme richtet die erste neu aus, und keines von beiden rührt die Komponenten an, die accent konsumieren.

Wie gelangen Tokens in Code und Design-Werkzeuge?

Durch Export. Die Tokens-Datei selbst ist bewusst neutral — JSON, das keinem einzelnen Werkzeug gehört — und jeder Konsument erhält eine generierte Ansicht davon: Custom Properties für Stylesheets, einen Theme-Block für Tailwind, Figma Variables für die Design-Datei, Schlüssel-Wert-Ressourcen für native Plattformen. Eine Quelle, mehrere Darstellungen, überall dieselben Namen.

Scale Composer arbeitet durchgängig so: Es leitet Schrift, Abstände und Farbrampen sowie semantische Rollen für helles und dunkles Theme aus einer einzigen gemeinsamen Skala ab, und alles Abgeleitete verlässt es als eine DTCG-Tokens-Datei zusammen mit CSS Custom Properties, einem Tailwind-v4-@theme-Block und Figma Variables — der Hex-Wert direkt neben den OKLCH-Werten. Öffne ein generiertes Token-System in Scale Composer — auf der einen Seite die Abschnitte der Datei, daneben dieselben Namen, gerendert als CSS-, Tailwind- und Figma-Exporte.

Wie sieht derselbe Button mit und ohne Tokens aus?

Zuerst die Styleguide-Sprache, so wie ein PDF es formulieren würde:

Primäre Buttons verwenden das Marken-Blau (#2563EB) als Hintergrund, mit weißem Text.

Danach die Token-Sprache:

{
  "color":    { "brand": { "600": { "$value": "#2563eb", "$type": "color" } } },
  "semantic": { "accent": { "$value": "{color.brand.600}", "$type": "color" } },
  "button":   { "background": { "$value": "{semantic.accent}", "$type": "color" } }
}

Der Inhalt ist derselbe, aber die Token-Version trägt eine Spur in sich. Frag, was der Hintergrund des Buttons ist, und die Datei antwortet in Sprüngen: button.background → semantic.accent → brand-600 → #2563eb, was oklch(0.546 0.215 262.9) ist. Jeder Sprung ist eine Entscheidung, die sich ändern kann, ohne die anderen zu stören — richte accent für ein Theme neu aus, ändere für einen Rebrand, was brand-600 speichert, löse button.background von accent an dem Tag, an dem der Button ihm wirklich nicht mehr folgen soll. Der PDF-Satz enthält eine verschmolzene Entscheidung; die Spur enthält drei voneinander trennbare.

Woher kommt der Begriff?

Zwei Sätze Geschichte: Salesforce prägte „design tokens” um 2014, als sein Design-System Web- und native Plattformen aus einem einzigen Satz von Entscheidungen bedienen musste, und baute Werkzeuge, die eine einzelne Token-Datei in das Format jeder Plattform übersetzten. Der Begriff wuchs über seinen Ursprung hinaus — heute pflegt die Design Tokens Community Group (designtokens.org) ein gemeinsames Austauschformat, auf das sich Design-Werkzeuge und Build-Pipelines weitgehend geeinigt haben.

Warum hat sich die Branche auf Design Tokens geeinigt?

Wegen Drift: Design-Dateien und ausgelieferter Code sind sich uneinig über Werte, die eigentlich identisch sein sollten. Drift hat keine Prozesslösung — Designer und Entwickler zu bitten, zwei Listen synchron zu halten, behandelt ein strukturelles Problem als Disziplinproblem, und die Listen laufen bis zur nächsten Deadline wieder auseinander. Die intuitive Fassung ist fast arithmetisch: Zwei Kopien von irgendetwas, gepflegt von verschiedenen Händen, driften auseinander; mehr Kopien driften schneller. Tokens ändern die Form des Problems, sodass nichts mehr zu synchronisieren bleibt — eine Kopie ist die Quelle, und die übrigen N−1 sind generierte Ansichten davon. Die Design-Datei und das Stylesheet stimmen überein, weil keine von beiden von Hand gepflegt wird; beide werden aus denselben Entscheidungen gelesen.

Was sind Design Tokens nicht?

Nicht bloß Variablen. Variablen sind der Speichermechanismus; Tokens sind Variablen plus die Disziplin — rollenbasierte Namen, Schichten, Referenzen —, die die gespeicherten Entscheidungen navigierbar macht. Ein --blue kann alles enthalten, was sein Autor getippt hat; ein Token-System ist so strukturiert, dass ein Leser erkennen kann, wofür ein Wert da ist und was von ihm abhängt.

Nicht nur für große Teams. Multi-Plattform-Organisationen haben das Problem zuerst benannt, aber ein einzelner Designer, der eine kleine Website neu brandet, steht vor derselben Drift im kleineren Maßstab: dieselben Werte, dupliziert über eine Design-Datei und ein Stylesheet, die leise auseinanderlaufen.

Kein Figma-Feature. Figma Variables sind ein Konsument von Tokens — ein Ort, an dem eine generierte Ansicht landet — nicht der Ort, an dem Tokens definiert werden. Einen einzelnen Konsumenten als Quelle zu behandeln, steckt die Entscheidungen wieder in ein einzelnes Werkzeug zurück — genau die Situation, die Tokens beenden sollen.

Verfolge eine Entscheidung von Anfang bis Ende

Eine Definition setzt sich, sobald du selbst einer echten Kette von Sprüngen gefolgt bist. Öffne die semantischen Rollen in Scale Composer und verfolge einen Token — wähle accent, folge ihm hinab bis zum primitiven Schritt, auf den er verweist, und dem dort gespeicherten Wert, ändere dann die Ausgangsfarbe und beobachte, wie die Entscheidung darüber stabil bleibt, während sich die Antwort darunter ändert.