Design Tokens klingen nach einem Konzept, das Berater auf Whiteboards malen — abstrakt, akademisch, weit weg von echter Produktentwicklung. Das stimmt nicht. Design Tokens sind Infrastruktur. Wer ohne sie baut, zahlt die Schulden irgendwann doppelt.
Dieser Artikel erklärt, was Design Tokens sind, warum die Drei-Layer-Architektur der einzig vernünftige Ansatz ist, welche Tools den Workflow tragen — und wie HARWAY Experience Tokens als Verbindungsglied zwischen Design und Code nutzt.
Was sind Design Tokens?
Ein Design Token ist ein benanntes Wertepaar. Kein Hexcode. Kein hardcodierter Pixel-Wert. Ein Token. Der Wert dahinter kann sich ändern. Der Name bleibt stabil. Das ist der eigentliche Trick.
Teams, die ohne Tokens bauen, kopieren Farbwerte durch hunderte Dateien. Jedes UI-Update wird zur Suchaktion. Jeder Entwickler hat eine leicht andere Version von "Grau". Irgendwann hat die App fünf verschiedene Schattierungen von #666 und niemand weiß mehr, welche die offizielle ist.
Design Tokens lösen dieses Problem an der Wurzel: ein Name, eine Wahrheit, eine Source.
Die W3C Community Group hat einen offiziellen Standard für Design Tokens definiert. Das Konzept selbst ist nicht neu — Salesforce, Spotify und Atlassian arbeiten seit Jahren damit. Was sich geändert hat: Die Tools sind reif. Figma Variables, Style Dictionary 4.0, Tokens Studio — die Infrastruktur ist da. Es gibt keine gute Ausrede mehr, es nicht zu tun.
Die Drei-Layer Token-Architektur
Wer anfängt, Design Tokens einzusetzen, macht oft denselben Fehler: Alle Tokens landen auf einer Ebene. color-blue, color-blue-hover, button-background, nav-link-color — alles durcheinander. Nach drei Monaten ist das Token-System so unübersichtlich wie das Problem, das es lösen sollte.
Die Lösung ist eine klare Hierarchie. Drei Layer. Jeder hat eine spezifische Aufgabe.
Layer 1: Base Tokens (Primitives)
Base Tokens sind die rohen Werte. Kein Kontext. Keine Semantik. Einfach Werte. Sie bilden die Palette und werden niemals direkt im Code verwendet — nur als Referenz für Layer 2. Das ist kein optionales Detail. Es ist die Regel, die das System stabil hält.
Layer 2: Semantic / Context Tokens
Hier passiert die Bedeutungszuweisung. Semantic Tokens referenzieren Base Tokens und geben ihnen einen Purpose. Der Unterschied: color-blue-500 ist eine Farbe. color-action-primary ist eine Entscheidung. Wenn sich das Brand von Blau auf Grün ändert, wird nur eine Zeile geändert — im Base Layer. Alle Semantic Tokens folgen automatisch.
Semantic Tokens sind der Schlüssel für Dark Mode oder Multi-Branding. Zwei Theme-Dateien mit denselben Token-Namen, aber unterschiedlichen Base-Referenzen. Der Code muss sich nicht ändern.
Layer 3: Component Tokens
Component Tokens sind komponentenspezifisch. Sie referenzieren Semantic Tokens und beschreiben exakt das Verhalten einer einzelnen Komponente. Das Prinzip: Base → Semantic → Component. Immer in diese Richtung. Nie überspringen. Nie rückwärts.
Wer diesen Ansatz konsequent umsetzt, hat ein System, das mit dem Produkt skaliert. Wer einen der Layer weglässt, spart zwei Wochen Aufbauzeit — und verliert Monate bei der Pflege.
Naming Conventions: Struktur vor Kreativität
Token-Namen sind Verträge. Design sagt, was gemeint ist. Entwicklung interpretiert es. Das Token ist die gemeinsame Sprache. Das bewährte Pattern: {category}-{context}-{variant}-{state}. Kategorien: color, spacing, typography, border, shadow, motion. Context: brand, text, background, action, layout, component.
Was nicht geht: kreative Namen, die niemand versteht. cool-blue, primary-new-2, button-fix-temp — alles Kandidaten für technische Schulden. Token-Namen müssen in drei Jahren noch lesbar sein.
Token-Architektur und AI
Design Tokens sind nicht nur nützlich für Konsistenz und Skalierbarkeit — sie sind die Grundlage für AI-gestützte Produktentwicklung. AI-Tools wie Claude Code brauchen strukturierten Kontext. Einen Designdump aus Figma versteht ein Sprachmodell schlechter als ein strukturiertes Token-System mit klaren Namenskonventionen.
Bei HARWAY Experience übergeben wir unseren Token-Export als Teil des Kontexts, bevor AI-generierter Code geschrieben wird. Statt dem Modell zu sagen "mach das blau wie im Figma-Screenshot" sagen wir: "Das primäre Action-Element nutzt color-action-primary. Hier ist die Token-Datei."
Design Tokens sind also kein Legacy-Konzept aus der prä-KI-Ära. Sie werden durch AI-Tooling wertvoller, nicht obsolet. Wer jetzt ein sauberes Token-System aufbaut, legt die Grundlage für die nächste Generation von Workflows.
Implementierung: Der 4-Wochen-Workflow
Woche 1 — Audit und Inventory: Export aller aktuell verwendeten Werte aus Codebase und Figma. Clustering — welche Werte gehören zusammen? Definieren der Base Palette. Entscheidung: Welche Werte sind intentional unterschiedlich, welche sind Fehler?
Woche 2 — Semantic Layer definieren: Mapping Base → Semantic. Dark Mode / Multi-Theme-Anforderungen klären. Figma Variables aufsetzen, die die Semantic Tokens spiegeln.
Woche 3 — Component Tokens und Tool-Integration: Für Top-10-Kernkomponenten Component Tokens definieren. Style Dictionary konfigurieren. CI/CD-Pipeline aufsetzen: Token-Export → Style Dictionary Transform → Output in jeweilige Plattform.
Woche 4 — Migration und Adoption: Bestehende Komponenten schrittweise auf Token-Referenzen migrieren. Linting-Regeln einführen. Team-Onboarding und Governance dokumentieren.
Tools: Was funktioniert
Figma Variables: seit 2023 nativ in Figma integriert. Unterstützt die Drei-Layer-Architektur direkt — Collections für Base und Semantic Tokens, Modes für Theme-Switching. Design und Token-Definitionen in derselben Datei.
Style Dictionary: das Werkzeug für den Token-Transform. Style Dictionary v4.0 liest Token-Dateien und generiert Platform-spezifische Outputs: CSS Custom Properties für Web, Swift für iOS, Kotlin für Android.
Tokens Studio: das Plugin, das Figma-Designs mit externen Token-Definitionen synchronisiert. Unterstützt JSON-Token-Dateien, GitHub-Integration und den W3C-Token-Standard.
Tailwind Config: die letzte Meile für Web-Projekte. Die tailwind.config.js kann CSS Custom Properties referenzieren — Token-Änderungen aus Style Dictionary landen automatisch in der Tailwind-Utility-Klasse. Der Stack: Figma Variables → Tokens Studio → Style Dictionary → CSS Custom Properties → Tailwind Config → Komponenten. Einmal eingerichtet, ist der Flow vollautomatisch.
Der HARWAY Experience Ansatz
Wenn ein neues Projekt beginnt, definieren wir zuerst das Token-System. Nicht die Komponenten. Nicht die Screens. Das Token-System. Alles andere folgt daraus. Token-Definitionen erzwingen Architekturentscheidungen, die später nur mit großem Aufwand korrigierbar sind.
Für Rapid-Prototyping-Projekte nutzen wir ein vordefiniertes Token-Starter-Kit, das wir auf jedes Projekt adaptieren. Das ist ein Teil des Warum, dass wir einen funktionalen Prototyp in Stunden, nicht Wochen liefern. Wer tiefer in unsere Token-Architektur-Methodik einsteigen will: Im Token Architecture Workshop zeigen wir, wie wir von Null zu einem voll funktionalen Three-Layer-System kommen.
Design Tokens sind keine Meinung. Sie sind Infrastruktur — genauso wie ein Datenbank-Schema oder ein API-Vertrag. Die Drei-Layer-Architektur löst das strukturell. Nicht perfekt, aber reproduzierbar. Und reproduzierbar ist in der Produktentwicklung fast immer besser als gelegentlich perfekt.
Häufig gestellte Fragen
Ja — genau dann ist der Einstieg am einfachsten. Wer ohne bestehende Komponentenbibliothek startet, kann das Token-System ohne Migration aufbauen. Tokens first, Komponenten danach.
