Design Systems · · 12 Min. Lesezeit
Semantische Tokens: der einzig sinnvolle Weg zu Design Systems im Jahr 2026
Aliase reichen nicht aus. Sie brauchen eine semantische Hierarchie, die Dark Mode, Theming und Multi-Brand übersteht. So bauen Sie sie aus Grundprinzipien auf – nicht aus dem Tooling heraus.
Ich habe Design Systems aus vielen Gründen sterben sehen. Fehlende Governance. Fluktuation im Team. Nur teilweise Übernahme durch die Entwicklung. Aber in den vergangenen zwei Jahren habe ich ein wiederkehrendes Muster bei denen erkannt, die am schnellsten zusammenbrechen: Sie haben flache Tokens, keine Semantik, gebaut, um organisiert auszusehen, ohne es tatsächlich zu sein.
Eine Datei mit 200 CSS-Variablen namens --color-blue-500, --color-blue-600 und so weiter ist kein Design System. Es ist eine Farbpalette unter anderem Namen. Und wenn die Anforderung kommt, Dark Mode, eine zweite Marke oder ein Barrierefreiheits-Theme für Menschen mit Sehbeeinträchtigung zu unterstützen, wird diese Datei zu einem ernsthaften Problem.
Die dreistufige Hierarchie, die funktioniert
Das Modell, das ich in all meinen Enterprise-Projekten verwende, hat drei klar getrennte Ebenen mit eigenen Verantwortlichkeiten und klaren Abhängigkeitsregeln.
Ebene 1 – Primitives. Das sind Rohwerte: exakte Farben, Größen, Schriften, Dauern. Sie tragen keine semantische Bedeutung. Sie sind das Rohvokabular des Systems. Primitive Tokens werden nie direkt in Komponenten verwendet – sie existieren nur, um von der nächsten Ebene referenziert zu werden.
Ebene 2 – Semantische Tokens. Hier passiert die Magie. Semantische Tokens ordnen Primitives Bedeutungen in der Oberfläche zu. Sie beschreiben keine Farbe – sie beschreiben eine Funktion: --color-background-default, --color-text-primary, --color-border-subtle. Im Dark Mode ändert sich der Wert von --color-background-default, aber jede Komponente, die dieses Token verwendet, aktualisiert sich automatisch – ohne eine einzige Komponentendatei anzufassen.
Ebene 3 – Komponenten-Tokens. Spezifisch für eine einzelne Komponente oder ein Muster. --button-primary-background verweist auf --color-action-primary, das wiederum auf das richtige Primitive für das aktive Theme verweist. Diese Ebene ist bei kleinen Systemen optional, wird aber bei Multi-Brand unverzichtbar.
Das Problem mit Aliasen ohne Semantik
Viele Teams implementieren etwas, das wie ein dreistufiges System aussieht, in Wirklichkeit aber nur eine Ebene tief ist. Ein Alias wie --brand-primary: var(--color-blue-600) ist kein semantisches Token – es ist ein Alias. Es beschreibt keine Funktion in der Oberfläche; es gibt einer bestimmten Farbe nur einen kürzeren Namen.
Wenn ich erklären muss, was ein Token tut, ist der Name falsch.
Der Unterschied wird in dem Moment deutlich, in dem Sie versuchen, ein alternatives Theme zu bauen. Wenn ein Button --brand-primary als Hintergrund verwendet, was passiert, wenn die zweite Marke Rot als Primärfarbe nutzt? Das korrekte semantische Token ist --color-action-primary-background: Es beschreibt die Funktion, die Rolle, und kann in jedem Theme jedem Primitive zugeordnet werden, ohne etwas kaputt zu machen.
Eine praktische Namensstruktur
Die Namenskonvention, die ich verwende, folgt diesem Muster: Kategorie – Eigenschaft – Variante – Zustand. Nicht jedes Segment ist immer nötig, aber die Reihenfolge ist immer dieselbe.
--color-background-default– Kategorie: Farbe, Eigenschaft: Hintergrund, Variante: Standard--color-text-on-primary– Text, der auf einem Element mit primärem Hintergrund liegt--color-border-focus– Rahmen im Fokuszustand (für WCAG-Barrierefreiheit)--size-spacing-md– Abstand mittlerer Größe--duration-interaction-fast– Dauer für schnelle Interaktionen
Das leitende Prinzip lautet, dass der Name eines semantischen Tokens für Designer und Entwickler gleichermaßen ohne zusätzlichen Kontext lesbar sein sollte.
Dark Mode, ohne alles zu überschreiben
Der praktische Nutzen einer semantischen Hierarchie zeigt sich am deutlichsten beim Dark Mode. Statt jede einzelne CSS-Variable mit Hunderten von Ausnahmen zu überschreiben, definieren Sie nur die Zuordnung zwischen semantischen Tokens und Primitives neu.
Komponenten ändern sich nicht – sie referenzieren immer dasselbe semantische Token. Das dunkle Theme ist schlicht eine Substitutionsschicht auf Ebene 2, keine Neufassung des Komponenten-CSS. Mit diesem Ansatz umfasst das CSS für das dunkle Theme bei einem System mit 60 Komponenten weniger als 80 Zeilen.
Multi-Brand in der Produktion
Beim Projekt Exein musste ich drei Marken mit sehr unterschiedlichen visuellen Identitäten auf demselben Komponentensystem verwalten. Die Lösung bestand darin, semantische Tokens markenneutral aufzubauen – sie beschreiben Funktionen, keine Identitäten – und für jede Marke eine eigene Theme-Datei zu erstellen.
Ein gut gestaltetes semantisches Token weiß nicht, zu welcher Marke es gehört. Es weiß nur, was es in der Oberfläche tun muss.
Das praktische Ergebnis: Das Hinzufügen einer vierten Marke dauerte weniger als einen halben Tag. Eine Primitives-Datei anlegen, sie den bestehenden semantischen Tokens zuordnen, die WCAG-Kontrastverhältnisse prüfen. Null Änderungen an den Komponenten.
Tooling im Jahr 2026
Token Studio für Figma bleibt die Referenz für die Brücke zwischen Design und Entwicklung. Style Dictionary von Amazon ist das flexibelste Werkzeug, um Tokens als CSS, JSON, Swift und Kotlin auszuliefern. Aber die Wahl des Toolings kommt nach der Wahl der Architektur. Ein schlecht gestaltetes System wird durch einen Softwarewechsel nicht zu einem guten.