Wie Entwickler Tokens tatsächlich konsumieren

Entwickler konsumieren design tokens als generierte Sichten auf eine einzige Datei: CSS custom properties für einfache Stylesheets, ein Tailwind-Theme, dessen Utility-Klassen aus den Token-Namen generiert werden, und Figma Variables, die auf der Design-Seite dieselben Namen tragen. Die Übergabe hält, wenn diese Datei als Schnittstelle zwischen Design und Entwicklung behandelt wird — die Namen sind die API, die Werte sind die Implementierung.

Das meiste, was über Tokens geschrieben wird, sitzt auf dem Design-Stuhl: wie man benennt, wie man schichtet, was man exportiert. Dieser Beitrag sitzt stattdessen auf dem Stuhl der Entwicklung — was tatsächlich ankommt, wenn eine Token-Datei in einem Repository landet, was sich in der täglichen Arbeit ändert, und wogegen du als Entwickler zu Recht Einspruch erheben darfst. Die Grundlagen findest du in unserem Leitfaden zu design tokens.

In welchen Formaten kommen Tokens an?

Selten als reine Quelldatei. Die Quelle ist werkzeugneutrales JSON; Konsumenten bekommen generierte Sichten darauf, und drei davon decken den Großteil der Web-Arbeit ab.

CSS custom properties — der Weg ohne Tooling. Das generierte Stylesheet deklariert eine Property pro Token, und Komponenten konsumieren sie mit var():

:root {
  --color-accent: oklch(0.546 0.215 262.9); /* #2563eb */
  --space-3: 16px;
}

.button {
  background: var(--color-accent);
  padding-inline: var(--space-3);
}

Kein Build-Schritt, kein Framework — ein <link>-Tag ist die gesamte Integration, weshalb dieser Weg in fast jedem Token-Setup existiert, ganz gleich was sonst noch zum Einsatz kommt.

Tailwind v4 @theme — Utilities aus Token-Namen generiert. Tailwind v4 leitet seine Utility-Klassen aus Theme-Variablen ab, sodass die Token-Datei zum Utility-Vokabular wird:

@theme {
  --color-brand-600: oklch(0.546 0.215 262.9);
  --spacing-3: 16px;
}

bg-brand-600 existiert jetzt als Klasse, weil das Token existiert. Der Utility-Satz ist eine Projektion der Token-Namen, keine parallele Liste, die jemand synchron halten muss.

Figma Variables — dieselben Namen auf der Design-Seite. Nur eine Zeile, denn es geht um die Namen und nicht um die Mechanik: Woran die Designerin eine Füllung bindet und was die Entwicklerin in ein Stylesheet tippt, lösen sich zum selben Eintrag auf.

Scale Composer generiert all das aus derselben Quelle — einer kanonischen DTCG-Datei, mit CSS custom properties, einem Tailwind-v4-@theme-Block und Figma Variables daneben exportiert, hex neben den OKLCH-Werten mitgeführt. Öffne die entwicklerseitigen Exporte in Scale Composer — dieselben Token-Namen als jedes Konsumenten-Format gerendert, nebeneinander.

Die Export-Ansicht von Scale Composer: ein Satz Token-Namen gleichzeitig gerendert als CSS custom properties, ein Tailwind-v4-Theme-Block und Figma Variables

Was ändert sich in der täglichen Arbeit, wenn Tokens ankommen?

Drei Verschiebungen, ungefähr in der Reihenfolge, in der sie auftreten.

Reviews streiten über Rollen statt über Werte. „Das sollte text-secondary sein” ist ein Argument, das jemand gewinnen kann — die Rolle passt zur Absicht oder nicht. „Dieses Grau sieht falsch aus” ist eine Frage von Sehvermögen und Monitor-Kalibrierung. Zu beobachten, wie Review-Kommentare von Werten zu Namen wandern, ist eines der klarsten Signale dafür, dass die Übergabe funktioniert.

Neue Screens komponieren statt erfinden. Eine Entwicklerin, die einen Screen baut, wählt aus vorhandenen Namen — background, text-primary, space-5 — so wie sie aus einer Bibliotheks-API wählt, statt mit jedem Mockup einen frischen Satz hex-Codes zu bekommen.

Von Hand kopierte Werte sterben aus. Der alte Fehlermodus — #2563eb aus einem Inspector-Panel kopieren und an einem müden Freitag #2564ec eintippen — verliert seinen Lebensraum: Werte gelangen durch die Datei hinein oder gar nicht.

Das intuitive Warum: Ein Name trägt die Absicht über die Übergabe hinweg, ein roher Wert streift sie ab. Eine Reviewerin kann text-secondary daran prüfen, wofür der Text da ist; kein Reviewer kann aus der Zahl allein rekonstruieren, was #64748b bedeuten sollte.

Warum die Token-Datei als Schnittstelle behandeln?

Weil zwei Teams von entgegengesetzten Seiten davon abhängen — genau die Situation, für die Schnittstellen-Verträge existieren, dieselbe Disziplin, die Software an jeder API-Grenze anwendet. Konkret:

Die Namen sind die API. Ein Umbenennen ist ein Breaking Change: jedes var(--color-accent) und jede Figma-Bindung ist ein Aufrufer. Umbenennungen verdienen ein Deprecation-Fenster — der alte Name als Alias erhalten, der auf den neuen zeigt — kein stiller Tausch.
Die Werte sind die Implementierung. Sie dürfen sich frei ändern; das ist der Sinn der Anordnung. Eine Neujustierung, die ändert, was brand-600 speichert, sollte ausgeliefert werden, ohne dass ein Konsument eine Zeile bearbeitet.
Ergänzungen sind nicht brechend. Ein neues Token kann jederzeit landen; noch konsumiert es nichts.
Entfernungen brauchen Migration. Ein Token, das gelöscht wird, während Aufrufer es noch referenzieren, schlägt fehl wie jeder entfernte Endpunkt — an den Aufrufstellen, zum ungünstigsten Zeitpunkt.

Wogegen solltest du Einspruch erheben?

Drei Dinge, jedes eine Vertragsverletzung in Spec-Kleidung.

Rohe Werte in Specs. Ein Mockup mit der Anmerkung „verwende #2563eb” verdient die Frage welches Token ist das? Lautet die Antwort brand-600, sollte die Spec das sagen. Gibt es keine Antwort, greift der nächste Punkt.

Einzelwerte ohne Token-Zuhause. Ein Wert, der an genau einer Aufrufstelle existiert, ist eine Entscheidung, die niemand festgehalten hat. Der Einspruch ist nicht „nein” — das Design mag durchaus richtig sein — sondern „das landet zuerst in der Token-Datei, dann konsumiere ich es von dort”.

Verweise auf Tokens, die es noch nicht gibt. Eine Spec, die text-muted nennt, während die Datei keine solche Rolle enthält, ist ein Aufruf gegen einen nicht ausgelieferten Endpunkt. Definiere es zuerst — eine einzeilige, nicht brechende Ergänzung nach den obigen Regeln — und baue dann dagegen.

Was produziert dieselbe Spec im Review?

Eine Card-Komponente, zweimal spezifiziert.

Wert-Stil: Titel 20px in #1e293b, 24px unter dem Bild, auf einer #f8fafc-Card. Der umsetzende PR reproduziert vier rohe Werte, und das Review muss jeden davon rückwärts erschließen: Sind 20px text-lg oder eine neue Größe? Ist #1e293b unsere primäre Textfarbe oder knapp daneben? Sind 24 ein Abstands-Schritt oder eine Schätzung? Vier archäologische Fragen pro Komponente, üblicherweise durch Raten beantwortet.

Token-Stil: Titel text-lg in text-primary, space-5 unter dem Bild, auf einer surface-Card. Der PR schreibt sich von selbst:

.card-title {
  font-size: var(--text-lg);
  color: var(--color-text-primary);
  margin-top: var(--space-5);
}

Das Review hat jetzt eine Frage pro Zeile — ist das die richtige Rolle für die Absicht? — und das ist eine Design-Frage, die eine Reviewerin tatsächlich beantworten kann. Der Diff liest sich auch aus der Zukunft gut: Wenn text-lg nächstes Jahr neu justiert wird, folgt diese Komponente, ohne überhaupt in irgendeinem Diff aufzutauchen.

Prüfe den Vertrag deiner eigenen Übergabe

Die Schnittstellen-Sichtweise verwandelt die Qualität der Übergabe in zwei testbare Fragen: Könnte sich ein Wert ändern, ohne dass ein Konsument etwas bearbeitet, und würde ein Umbenennen Aufrufer brechen, die du auflisten kannst? Öffne einen Token-Satz und prüfe beides von der Konsumenten-Seite — wähle eine Rolle, sieh, wie der Name sich über jedes Export-Format wiederholt, ändere dann seinen Wert und beobachte, wie die API hält, während die Implementierung sich bewegt.