Design Tokens: Wie echte Design-Systeme konsistent bleiben
Was Design Tokens sind, das Drei-Stufen-Modell echter Systeme (Shopify Polaris, IBM Carbon, GitHub Primer), wie man sie benennt, Theming für Dark Mode und wann Tokens übertrieben sind.
Design Tokens: Wie echte Design-Systeme konsistent bleiben
Ein Hex-Code ist ein Wert. Ein Token ist eine Entscheidung mit einem Namen. Design-Systeme bestehen aus Entscheidungen, nicht aus Werten.
Genau darum geht es. #0EA5E9 in vierzehn Figma-Komponenten hardcoden, dann nach Dark Mode gefragt werden, und schon steht man vor einer Woche voller Suchen-und-Ersetzen. Nenn es color-interactive-primary, und du änderst einen einzigen Wert, während sich jede Oberfläche aktualisiert. Das ist kein Zauber, nur benannte Entscheidungen.
Was ein Design Token eigentlich ist
Ein Design Token ist eine benannte Variable, die eine Designentscheidung speichert. Sie kann eine Farbe, einen Abstandswert, eine Schriftgröße, einen Border-Radius, einen Schatten oder eine Dauer enthalten. Der Name ist der Vertrag. Der Wert hinter dem Namen kann sich ändern, ohne dass etwas, das den Token verwendet, kaputtgeht.
Der klassische Ansatz ohne Tokens beginnt damit, dass ein Designer #1D4ED8 für primäre Buttons wählt, ihn in der Button-Komponente hardcodet und diesen Hex-Wert dann in die Karte, das Badge und den Link kopiert. Sechs Monate später aktualisiert die Marke. Jetzt hat man ein Wartungsproblem, das mit jeder gelieferten Komponente wächst.
Tokens kehren das um. Du benennst die Entscheidung (color-action-default), weist den Wert einmal zu, und alles, was auf den Token verweist, bleibt synchron. Der Wert ist ein Implementierungsdetail. Der Name ist das System.
Die drei Stufen, die Tokens zum Laufen bringen
Rohe Tokens sind nur Variablen. Was ein Token-System wirklich nützlich macht, ist Hierarchie. Jedes Produktionssystem, das es wert ist, studiert zu werden, verwendet drei Stufen.
| Stufe | Auch bekannt als | Was sie speichert | Beispiel |
|---|---|---|---|
| Primitiv | Global, Base | Rohe Werte, keine Bedeutung | color.blue.500 = #3B82F6 |
| Semantisch | Alias, Rolle | Benannte Rollen, auf Primitive gemappt | color.interactive.default = color.blue.500 |
| Komponente | Spezifisch | Komponentenspezifische Entscheidungen | button.background.default = color.interactive.default |
Primitive sind deine Palette. Jedes Blau, jeder Abstandsschritt und jeder Radius lebt hier als benannter Wert ohne Meinung darüber, wo er verwendet wird. Primitive werden nicht direkt in Komponenten konsumiert.
Semantische Tokens mappen Rollen auf Primitive. Der Token color-surface-default könnte im Light Mode auf Nahezu-Weiß und im Dark Mode auf Nahezu-Schwarz zeigen, und die Komponente weiß nie, welchen Rohwert sie bekommt. Sie kennt nur die Rolle.
Komponenten-Tokens sind am spezifischsten. Sie existieren, wenn eine Komponente eine Entscheidung braucht, die sich absichtlich vom semantischen Standard unterscheidet. Ein Danger-Button zeigt seinen Hintergrund auf eine Critical-Feedback-Rolle statt auf die standardmäßige interaktive. Die meisten Komponenten brauchen keine eigenen Tokens; sie konsumieren semantische direkt.
Warum Tokens hardcoded Werte schlagen
Geschwindigkeit bei Änderungen ist das offensichtliche Argument, aber nicht das eigentliche. Das eigentliche Argument ist Präzision.
Wenn ein Designer eine Datei voller roher Hex-Codes übergibt, hat der Entwickler keine Ahnung, welche davon absichtlich und welche versehentlich sind. Ist #1A1A2E der Hintergrund, oder hat jemand die falsche Ebene gezogen? Tokens beseitigen die Mehrdeutigkeit. Ein semantischer Token-Name ist Dokumentation, die mit dem Wert mitreist.
Tokens sind 2026 auch der Übergabe-Vertrag zwischen Design-Tools und Code. Figma-Variablen mappen direkt auf CSS Custom Properties. Ein in einer Figma-Datei definierter Token kann exportiert, committet und im Code konsumiert werden, ohne einen einzigen manuellen Schritt. Die Lücke zwischen Design und Implementierung schließt sich, wenn beide Seiten dieselben Token-Namen sprechen.
Für Teams, die Accessibility-Arbeit leisten, fügen Tokens eine weitere Sicherheitsschicht hinzu. Du prüfst die semantische Palette an einem Ort und garantierst, dass color-text-default immer 4,5:1-Kontrast gegen color-surface-default erreicht, egal welches Theme aktiv ist.
Wie echte Design-Systeme ihre Tokens strukturieren
Drei Systeme lohnt es sich zu kennen: Shopify Polaris, IBM Carbon und GitHub Primer. Sie behandeln das Drei-Stufen-Modell unterschiedlich, und die Unterschiede sind lehrreich.
Shopify Polaris hält Primitive in einer Farbskala (color-sky-100 bis color-sky-900) und mapped sie auf semantische Rollen wie --p-color-bg-fill-active. Komponenten-Tokens sind spärlich, daher konsumieren die meisten Komponenten semantische Tokens. Die Konvention ist Rolle-dann-Status, was sich im Code natürlich liest, denn man weiß, wofür bg-fill-disabled steht, ohne weiteren Kontext.
Live ansehen auf polaris.shopify.com
IBM Carbon geht tief auf semantische Schichten ein. Sein Farbset enthält explizite Feedback-Tokens wie support-error und support-success, interaktive Status-Tokens und Layer-Tokens für verschachtelte Oberflächen (eine Komponente auf einem Panel auf einer Seite braucht jeweils einen anderen Oberflächenwert). Es ist komplexer, aber IBM liefert Enterprise-Software, wo jeder verschachtelte Status zählt.
Live ansehen auf carbondesignsystem.com
GitHub Primer stellt seine primitive Schicht als "Primitives" und seine semantische Schicht als "Functional Tokens" bereit, öffentlich dokumentiert auf primer.style. Primers Theming ermöglicht es GitHub, Light, Dark, Light High Contrast und Dark Dimmed aus einem einzigen Komponenten-Set zu liefern. Jedes Theme ist eine andere Wertzuweisung zu denselben Token-Namen.
Das Muster über alle drei hinweg ist konsistent: Primitive als Skala, semantische Tokens als Rollennamen und Theming als Werttausch auf der semantischen Stufe. Die Komponenten bleiben unberührt.
Brainy hilft Designern, Systeme zu bauen, die skalieren, keine Einmalscreens. Was wir für Creator aufbauen, siehst du unter /creators.
Tokens benennen, ohne den Verstand zu verlieren
Token-Benennung spaltet Teams. Zu generisch und die Namen tragen keine Information. Zu spezifisch und man schreibt einen neuen Token für jede Komponente.
Eine Benennungskonvention, die funktioniert, benennt vier Teile: Kategorie, Rolle, Variante und Status. Du wirst nicht alle vier jedes Mal verwenden, aber die Struktur verhindert ad-hoc-Chaos.
| Teil | Was er erfasst | Beispiele |
|---|---|---|
| Kategorie | Die Design-Eigenschaft | color, spacing, radius, shadow, font |
| Rolle | Der semantische Zweck | surface, text, border, interactive, feedback |
| Variante | Sub-Rolle oder Modifikator | primary, secondary, danger, subtle |
| Status | Interaktiver Zustand | default, hover, active, disabled, focus |
Funktionierende Beispiele, geschrieben als CSS Custom Properties, die ein Entwickler tatsächlich konsumiert:
color-surface-defaultsetzt den Standard-Seitenhintergrundcolor-text-subtleist sekundärer Text mit geringerem Kontrastcolor-interactive-primary-hoverist der Hover-Status einer primären Aktionspacing-component-mdist mittleres internes Padding für Komponentenradius-interactiveist der Eckradius für klickbare Elemente
Zwei Regeln sparen die meisten Diskussionen. Niemals den Rohwert im Namen kodieren, denn color-blue-500 sagt nichts über die Rolle aus. Niemals nach Komponente auf der semantischen Stufe benennen, denn button-primary-color in der semantischen Stufe bedeutet, dass die semantische Stufe übersprungen wurde.
Für Schriftsysteme, die skalieren, gilt dieselbe Konvention, und font-size-body-lg schlägt text-18px jedes Mal.
Ein Token-Set, Light und Dark Mode
Dark Mode ist der Bereich, in dem Token-Systeme am sichtbarsten zahlen. Wenn du deine Tokens nach Rolle benannt hast, ist Dark Mode ein Werttausch, kein Redesign.
Der Mechanismus ist unkompliziert. Dein semantischer Token color-surface-default zeigt auf ein Primitiv, das im Light Mode nahezu Weiß und im Dark Mode nahezu Schwarz ist. Die Komponente, die ihn konsumiert, ändert sich nie. Du wechselst Themes, indem du das Wert-Mapping auf der semantischen Stufe tauschst.
CSS Custom Properties machen das mechanisch:
:root {
--color-surface-default: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-surface-default: #0f172a;
--color-text-primary: #f8fafc;
}
Jede Komponente, die var(--color-surface-default) referenziert, reagiert jetzt auf das Theme-Attribut ohne eine einzige zusätzliche Zeile Code. Shopify Polaris, GitHub Primer und IBM Carbon verwenden dieses Muster im Produktionsmaßstab.
Der Fehlermodus ist das Mischen von semantischen und primitiven Tokens in Komponenten. Wenn eine Komponente color-blue-600 direkt statt color-interactive-primary referenziert, hört diese Komponente auf, auf Theming zu reagieren. Eine einzige unbedachte Primitiv-Referenz bricht das gesamte Modell. Lint-Regeln, die den direkten Primitiv-Verbrauch in Komponenten-Code markieren, sind die Setup-Zeit wert.
Zu verstehen, wie Farbentscheidungen ankommen, gibt dir das konzeptionelle Fundament, und Tokens geben dir die Struktur, um bei jedem Theme danach zu handeln.
Wann Design Tokens übertrieben sind
Tokens fügen Indirektion hinzu. Indirektion hat Kosten. Sei ehrlich darüber, wann diese Kosten es wert sind.
| Situation | Tokens? | Grund |
|---|---|---|
| Design-System für 3+ Produkte | Ja | Geteilte Tokens amortisieren sich sofort |
| Ein Produkt, 5+ Designer | Ja | Verhindert Palettendrift im Team |
| Ein Produkt, 1-2 Designer, aktive Iteration | Vielleicht | Nur semantische Stufe, Komponenten-Tokens überspringen |
| Marketing-Website, keine Komponentenbibliothek | Nein | Ein Stylesheet ist schneller zu ändern |
| Prototyp oder MVP unter 3 Monaten | Nein | Nach Stabilisierung des Designs abstrahieren |
| Dark Mode zu einem bestehenden System hinzufügen | Ja | Genau dafür sind Tokens gemacht |
Kleine Teams bewegen sich ohne Tokens schneller. Ein dreiköpfiges Startup, das Product-Market Fit sucht, braucht keine Drei-Stufen-Hierarchie. Wenn du die visuelle Richtung alle zwei Wochen änderst, reicht eine einzige Figma-Style-Bibliothek.
Das Anti-Muster, das es zu vermeiden gilt, ist verfrühte semantische Benennung. Tokens namens color-blue und color-gray fügen Indirektion ohne Bedeutung hinzu. Entweder nach Rolle mit color-surface und color-text benennen, oder bei Primitiven bleiben, bis genügend Komponenten vorhanden sind, um zu wissen, was die Rollen eigentlich sind.
Schlechte Token-Benennung ist schlimmer als keine Tokens. Ein Token namens button-color-for-the-checkout-page auf der semantischen Stufe ist eine Wartungsfalle. Die Benennungsdisziplin ist nicht optional, sie ist der Grund, warum Tokens funktionieren.
FAQ
Ersetzen Design Tokens Figma-Styles?
Nein, aber sie erweitern sie. Figma-Variablen, 2023 veröffentlicht, sind das nächste native Äquivalent innerhalb von Figma, und sie mappen auf Code-Tokens, wenn du Benennungskonventionen auf beiden Seiten teilst. Figma-Styles behandeln Typografie und Füllfarben, während Variablen die vollständige Token-Hierarchie inklusive Status und komponentenspezifischer Entscheidungen handhaben.
Funktionieren Tokens ohne ein Design-System?
Tokens sind am wertvollsten innerhalb eines Design-Systems, aber selbst ein einzelnes Produkt profitiert von semantischer Benennung auf CSS Custom Property-Ebene. Man braucht kein formales System, um aufzuhören, Hex-Werte zu hardcoden.
Welches Tool sollte ich für Token-Management verwenden?
Für kleine Teams reichen Figma-Variablen plus ein JSON-Export. Für größere Teams ist Style Dictionary (Open Source, von Amazon) das Standard-Build-Tool. Es nimmt eine Token-JSON-Struktur und gibt CSS Custom Properties, iOS Swift-Konstanten und Android XML aus. Tokens Studio für Figma ist das beliebte Plugin-Bindeglied zwischen Figma und Style Dictionary.
Wie granular sollten Komponenten-Tokens sein?
Nur so granular wie nötig. Die meisten Komponenten können semantische Tokens direkt konsumieren. Komponentenspezifische Tokens sind sinnvoll, wenn eine Komponente absichtlich von der semantischen Schicht abweicht, wie ein destruktiver Aktions-Button oder ein Banner mit einer ungewöhnlichen Oberfläche. Im Zweifelsfall semantische Tokens konsumieren und Komponenten-Tokens nur erstellen, wenn man sich dabei ertappt, Ausnahmen zu schreiben.
Funktionieren Tokens nur für Farbe, oder auch für Abstände und Typografie?
Tokens funktionieren für alles mit einem diskreten Wert: Farbe, Abstände, Typografie, Border-Radius, Box-Shadow, Motion-Dauer, Motion-Easing und Z-Index. Die reifsten Systeme, wie IBM Carbon und Atlassian Design System, haben Tokens für all das. Mit Farbe und Abstände anfangen, dann andere hinzufügen, wenn das System reift.
Aufhören, Werte zu hardcoden
Der praktische Weg ist nicht kompliziert:
- Primitive als Skala benennen
- Diese Primitive auf semantische Rollen mappen
- Jede Komponente semantische Tokens konsumieren lassen, niemals Primitive
- Token-Werte aus einer einzigen Quelle exportieren (Figma-Variablen, eine JSON-Datei oder ein Design-System-Paket) und Build-Tools sie an CSS, iOS und Android verteilen lassen
Man braucht keine dreimonatige Migration, um anzufangen. Eine Komponente nehmen, ihre Entscheidungen benennen, und den Unterschied spüren, wenn man einen Wert einmal ändert und zuschaut, wie sich alles aktualisiert. Diese Erfahrung ist das Argument.
Für weitere Texte zu Design-Systemen, sieh dir an, was Brainy sonst noch abdeckt: /paper.
Brainy helps designers build systems that scale, not one-off screens. See what we are building for creators.
Get Started
