Design Tokens: Der Praxisleitfaden

Design Tokens sind Design-Entscheidungen, als Daten gespeichert — benannte Werte für Farbe, Typografie, Abstände und Radius, die in einer einzigen Datei leben und in jedes Werkzeug exportieren, das sie braucht: CSS, Tailwind, Figma, nativer Code. Sie sind die Schicht, die ein Designsystem ehrlich hält: Wenn Design-Dateien und Stylesheets dieselbe Quelle lesen, können sie nicht auseinanderdriften. Dieser Hub sammelt unsere Leitfäden zum Format, zur Benennung und zum Workflow; die Ein-Bildschirm-Version ist eine Token-Quelle, gerendert als vier Exporte.

Die Idee in einem Zug

Ein Token ersetzt einen Wert durch eine Referenz. Statt dass #2563eb in vierzig Stylesheets und dreißig Figma-Füllungen auftaucht, erscheint brand-600 überall und wird an genau einer Stelle zum Wert aufgelöst. Der intuitive Gewinn: Ein Name trägt Absicht, wo ein Wert es nicht kann — #2563eb sagt nichts darüber, wann man ihn verwenden soll, brand-600 schon. Und eine Änderung hinter einem Namen wird einmal gemacht, einmal geprüft und überall dort, wo der Name auftaucht, vertraut. Jede schwierige Frage der Token-Arbeit — Benennung, Schichtung, Theming, Migration — ist eine Variation davon, diesen einen Zug im großen Maßstab zu vollziehen, und die Leitfäden hier nehmen sie der Reihe nach vor. Was sind Design Tokens ist die Einführung im Erdgeschoss; Design Tokens vs. CSS-Variablen entwirrt die Unterscheidung, die die Terminologie verwischt — Custom Properties sind ein Export einer Token-Datei, nicht die Sache selbst.

Das Format, das sich durchgesetzt hat

Das DTCG-Format — das JSON der W3C-Community-Group — ist das, was Tokens einem Standard am nächsten kommt: $value und $type pro Token, Referenzen zwischen Tokens, zusammengesetzte Typen für Typografie und Schatten. Unsere Leitfäden behandeln das Lesen, das Schreiben und die Round-Trip-Disziplin, die es erlaubt, eine Token-Datei von Werkzeugen bearbeiten zu lassen, ohne zu verlieren, was Menschen hinzugefügt haben: Das DTCG-Format erklärt geht eine echte Datei Zeile für Zeile durch, Bestehende Tokens importieren behandelt den Round-Trip selbst, und Style Dictionary vs. direkter Export wägt ab, wann eine Transform-Pipeline ihren Platz gegenüber dem direkten Schreiben der Exporte verdient.

Benennung und Schichten — wo Token-Systeme stehen oder fallen

Die meisten Token-Systeme scheitern sozial, bevor sie technisch scheitern: Namen, die niemand vorhersagen kann, Schichten, die niemand respektiert. Die tragende Entscheidung ist die Aufteilung in primitive, semantische und Komponenten-Schichten — Primitive halten Werte (brand-600), Semantiken halten Rollen (text-primary), Komponenten nutzen die Rollen — denn genau diese Indirektion lässt einen Rebrand oder einen Theme-Wechsel die Rollen neu ausrichten, ohne eine einzige Komponente anzufassen. Namenskonventionen machen die Schichten lesbar, und Fünf Token-Anti-Pattern katalogisiert die Wege, auf denen sie in der Praxis erodieren. Von dort übernehmen die Workflow-Leitfäden: Eine Single Source of Truth beschreibt den Kreislauf von Anfang bis Ende, Token-Änderungen in git prüfen macht Design-Entscheidungen diffbar wie jeden anderen Code, und Wie Entwickler Tokens tatsächlich nutzen ist der Realitätscheck von der Empfängerseite. Für Organisationen, die noch einen PDF-Styleguide pflegen, legt Design Tokens vs. Styleguide dar, was jedes kann, was das andere nicht kann.

Wo Tokens auf den Rest des Systems treffen

Tokens tragen die Werte, die andere Systeme festlegen: die Skalenmathematik aus Schriftgrößenskalen und Abständen, die abgeleiteten Rollen aus Farbskalen, die Theme-Paare aus Dark Mode. Die Token-Schicht ist der Ort, an dem all das auslieferbar wird — weshalb sich dieser Hub am besten nach den anderen liest und von ihnen allen referenziert wird. Es ist auch die Schicht, die Scale Composer schreibt: Jede Skalen-Entscheidung, die dort getroffen wird — Farbe, Typografie, Abstände, Raster —, landet in einer einzigen DTCG-Datei, bereit für die Exporte, die dieser Hub beschreibt.

Leitfäden in diesem Hub

• Bestehende Tokens importieren, ohne etwas zu verlieren

  Wie du Design Tokens importierst, ohne handgebaute Arbeit zu verlieren: der Round-Trip-Vertrag, ein Fünf-Minuten-Fixpunkt-Test und was du prüfen solltest, bevor du einem Tool vertraust.

• Das DTCG-Token-Format erklärt

  Das DTCG-Format erklärt: $value und $type auf jedem Token, Gruppen, Referenzen und zusammengesetzte Typen — plus, was eine echte generierte design tokens-Datei enthält.

• Design Tokens vs CSS-Variablen: Was ist der Unterschied?

  Design Tokens vs CSS-Variablen: Tokens sind die tool-neutrale Quelle, Custom Properties ein generierter Export. Wie sie zusammenhängen und wann Variablen genügen.

• Design Tokens vs. Styleguide

  Design Tokens vs. Styleguide: Der Styleguide trägt Absicht und Verwendung für Menschen, Tokens tragen die Werte für Maschinen — und wie beide ohne Drift zusammenspielen.

• Eine Quelle der Wahrheit: Der Token-Workflow

  Design Tokens als einzige Quelle der Wahrheit: der fünfstufige Token-Workflow — entscheiden, exportieren, committen, konsumieren, ändern — und der Fehler, den jeder übersprungene Schritt zurückholt.

• Fünf Token-Anti-Patterns

  design tokens Best Practices, aus Fehlern gelernt: fünf Anti-Patterns — Wildwuchs, übersprungene Ebenen, Notausgänge, Namen nach Aussehen und Write-only-Dateien.

• Namenskonventionen für Design Tokens

  Namenskonventionen für Design Tokens: die category-concept-variant-state-Anatomie, fünf Regeln, die Rebrands überstehen, und die Mikro-Entscheidungen, die man einmal klärt.

• Primitive, semantische und Component-Tokens: Die drei Token-Ebenen

  Semantische design tokens liegen zwischen Primitiven und Components. Wie die Drei-Ebenen-Architektur Rebrands, Themes und Ausnahmen zu Änderungen in nur einer Ebene macht.

• Style Dictionary vs. direkter Export

  Style Dictionary vs. direkter Export: was dir eine Token-Transform-Pipeline bringt, wann eingebaute Exporte reichen und wie eine standardisierte DTCG-Datei beide Wege offen hält.

• Token-Änderungen in Git prüfen

  Design Tokens unter Versionskontrolle: warum Token-Änderungen in Git gehören, wie du einen sechs Zeilen langen Token-Diff liest und die Prüf-Checkliste, die stille Design-Änderungen aufdeckt.

• Was sind Design Tokens?

  Was sind Design Tokens? Benannte Design-Entscheidungen — brand-600 enthält genau ein Blau — über Referenzen zusammengesetzt und nach CSS, Figma und nativen Code exportiert.

• Wie Entwickler Tokens tatsächlich konsumieren

  Die Übergabe von design tokens aus Sicht der Entwicklung: CSS custom properties, Tailwind-Themes, Figma Variables — und warum die Token-Datei wie eine API behandelt werden sollte.

Die einzige Quelle spüren

Das Argument für Tokens verdichtet sich zu einer einzigen Interaktion: ändere einen Skalen-Parameter und sieh zu, wie jeder Export sich aktualisiert — DTCG, CSS Custom Properties, Tailwind-Theme und Figma Variables bewegen sich gemeinsam, weil alle vier aus denselben Entscheidungen gelesen werden. Diese Gleichzeitigkeit ist es, was eine Token-Schicht erkauft; alles andere ist Implementierung.