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

„Der Rebrand war auf drei Tage angesetzt. Es wurden drei Wochen.” Die Post-mortem-Geschichte hinter diesem Satz ist meist dieselbe: Die alte Markenfarbe existierte als roher Hex-Wert, in Hunderte von Components kopiert, also war „das Blau gegen das Petrol tauschen” keine einzige Änderung — es war ein Suchen-und-Ersetzen über die gesamte Codebase, plus eine Prüfung jeder Stelle, an der das Ersetzen falsch geraten hat. Nichts war falsch gebaut; es gab schlicht keine Ebene, in der „die Markenfarbe” als eine einzige Entscheidung existierte.

Token-Architektur verhindert genau das — mit bis zu drei Ebenen. Primitive Tokens sind das rohe Vokabular — brand-600, space-4, text-lg — Werte mit positionsbasierten Namen und ohne Meinung zur Verwendung. Semantische design tokens sind die Entscheidungen — background, text-primary, accent, gap-section — Rollennamen, die auf Primitive zeigen; hier lebt die gestalterische Absicht. Component-Tokens — button-bg, das auf accent zeigt — sind eine optionale dritte Ebene für die Fälle, in denen ein Component sich von einem semantischen Standard lösen muss. Components lesen die semantische Ebene, und die häufigen Änderungen — Rebrand, Theme, Ausnahme — landen jeweils in genau einer Ebene. Das allgemeine Token-Konzept hat einen eigenen Artikel in unserem Leitfaden zu design tokens; hier geht es um das Ebenen-Modell selbst.

Was macht jede Ebene?

Primitive sind die Palette und die Skalen: brand-50 bis brand-900, space-1 bis space-7, text-sm bis text-xl. Ihre Namen benennen eine Position, nie einen Zweck — brand-600 sagt dir, welches Blau, und bewusst nichts darüber, wohin es gehört. Sie sind das Vokabular des Systems: alles Sagbare, noch nichts Gesagtes.

Semantische Tokens sagen etwas. background → neutral-50, text-primary → neutral-800, accent → brand-600, gap-section → space-7: Jedes ist eine gestalterische Entscheidung — diese Rolle wird von jenem Wert gespielt — festgehalten als Referenz. Wenn jemand fragt, wo die gestalterische Absicht eines Produkts festgeschrieben ist, ist diese Ebene die Antwort.

Component-Tokens halten Ausnahmen fest. button-bg hat normalerweise keinen Grund zu existieren — der Button kann accent direkt lesen. Es verdient seinen Platz an dem Tag, an dem der Button aufhören muss, accent zu folgen: Ein Marketing-Theme lenkt accent auf einen sekundären Farbton um, aber der primäre Button soll markentreu bleiben. Das Component-Token hält diese Ablösung fest.

Das Token-System von Material Design dokumentiert dieselbe dreistufige Architektur — reference-, system- und component-Tokens — in seiner design tokens overview, nur unter anderen Ebenen-Namen.

Welche Regeln bringen die Ebenen zum Funktionieren?

Drei Regeln, jede schützt eine andere Eigenschaft:

• Components konsumieren Semantik, nie Primitive. Ein Component, das brand-600 liest, hat eine Annahme fest verdrahtet — welcher Schritt heute welche Aufgabe erfüllt; ein Component, das accent liest, formuliert einen Bedarf und lässt das System ihn beantworten. Diese Regel macht Rebrands und Themes billig — brich sie, und die Ebene oberhalb des Bruchs schützt dich nicht mehr.
• Semantik zeigt nach unten, einen Sprung weit. Ein semantisches Token referenziert ein Primitive, kein weiteres semantisches Token. Ketten wie button-text → text-inverse → on-dark → neutral-50 wirken flexibel, kosten aber Navigierbarkeit: Niemand kann einen Wert auflösen, ohne sich durchzuwühlen. Ein einziger Sprung hält jede Rolle in einer einzigen Abfrage beantwortbar.
• Primitive referenzieren nichts. Sie sind der Boden. Jede Spur endet, nach unten verfolgt, in einem Primitive, das einen literalen Wert hält — genau das macht Spuren endlich und Dateien debugbar.

Warum schlagen Ebenen eine flache Token-Liste?

Wegen dessen, was jede Änderung kostet. In einem geschichteten System berührt jede der drei häufigen Änderungen genau eine Ebene:

In einer flachen Liste — oder schlimmer, rohen Werten in Components — wird jede dieser Änderungen zum Drei-Wochen-Rebrand vom Anfang: ein Suchen-und-Ersetzen über alles hinweg, mit Ermessensentscheidungen bei jedem Treffer, weil dasselbe #2563eb, das in einer Datei „Marke” bedeutete, in einer anderen „Link-Farbe, die zufällig passt” bedeutete.

Das intuitive Warum lohnt sich als das auszusprechen, was es ist — eine Programmier-Parallele: Ebenen sind Indirektion, und Indirektion ist die Art, wie Software Änderungen schon immer eingedämmt hat — aus demselben Grund, aus dem Code Funktionen aufruft, statt ihren Rumpf zu wiederholen. Ein semantisches Token ist ein Interface; Primitive sind die Implementierung; und Änderungen hören an der Grenze zwischen beiden auf, sich weiterzuverbreiten. Design-Systeme haben den Trick nicht erfunden, sie haben ihn geerbt.

Wie sieht eine vollständige Spur aus?

Nach unten, von einem Component aus: button.background liest {semantic.accent}; accent liest {color.brand.600}; brand-600 speichert #2563eb, also oklch(0.546 0.215 262.9). Drei Sprünge, jeder eine trennbare Entscheidung. Dieselbe Form gilt außerhalb der Farbe: gap-section liest {spacing.7}, das 64px speichert.

Nach oben, von einem Wert aus: #2563eb wird genau einmal gespeichert, bei brand-600. Eine semantische Rolle zeigt darauf — accent. Frag, was accent konsumiert, und du hast den vollständigen Wirkungsradius einer Änderung der Markenfarbe: den Button, Links, den aktiven Nav-Zustand — eine endliche, auflistbare Menge, statt „überall dort, wo der Hex-Wert eingefügt wurde”.

Öffne die Spur-Ansicht in Scale Composer — die primitiven Rampen und Skalen auf der einen Seite, die semantischen Rollen, die in sie hineinzeigen, und die Kette jeder Rolle Sprung für Sprung lesbar bis hinunter zum gespeicherten Wert.

Jetzt der Rebrand-Test, der Beweis des geschichteten Systems: Leite die Palette neu aus einer Petrol-Ausgangsfarbe ab. brand-600 behält seinen Namen und ändert seinen gespeicherten Wert. accent sagt weiterhin {color.brand.600} — als Aussage ist es unangetastet und immer noch wahr. button.background sagt weiterhin {semantic.accent}. Die Änderung geschah in einer Ebene, und die Ebenen darüber haben sich nicht bewegt. Das ist der Drei-Wochen-Rebrand, reduziert auf seine ehrliche Größe: eine Bearbeitung und eine Prüfung.

Wann ist es ehrlich, eine Ebene wegzulassen?

Die Component-Ebene, oft. Ein kleines Produkt mit disziplinierter Semantik hat selten Ablösungsfälle, und Component-Tokens, die im Voraus vor dem Bedarf angelegt werden, sind Indirektion ohne Bedeutung — button-bg → accent → brand-600, drei Namen für einen Wert, der nie unabhängig variiert, vervielfacht über eine Component-Bibliothek, bis niemand mehr die Menge navigieren kann. Die Ebene verdient ihren Platz im Maßstab eines Design-Systems, wenn echte Ausnahmen auftauchen — eine vernünftige Grundregel ist, jedes Component-Token mit der Ausnahme einzuführen, die es rechtfertigt, nicht vorher.

Die semantische Ebene ist die, die man auch im Kleinen behält. Nur-Primitive bedeutet, dass Components Annahmen versteinern (brand-600 als „Button-Farbe” an hundert Stellen) — das ist die Anfangsgeschichte mit besseren Namen. Primitive plus Semantik ist das ehrliche Minimum für ein System, das erwartet, einen Rebrand zu überleben oder ein Dark-Theme wachsen zu lassen.

Mach den Rebrand-Test selbst

Dem Ebenen-Modell vertraut man am leichtesten, nachdem man zugesehen hat, wie eine Änderung an einer Grenze stoppt. Tausch die Ausgangsfarbe und sieh die Ebenen arbeiten — die primitive Rampe leitet sich neu ab, die semantischen Rollen zeigen automatisch neu und behalten ihre Namen, und die Spur vom Button abwärts löst sich immer noch auf — dieselben Aussagen, neue Antworten, kein Suchen-und-Ersetzen.