Farb-Tokens benennen: brand-600 vs blue-600

Zwei Token-Dateien treffen auf denselben Rebrand. In der ersten wurde die Palette nach Farbton benannt — blue-600, referenziert über Hunderte von Dateien hinweg. Die Marke wird türkis, und jede Option ist schlecht: Behältst du den Namen, speichert blue-600 jetzt ein Türkis und belügt jeden künftigen Leser; benennst du ihn um, musst du jede Referenz im gesamten Codebase anfassen. In der zweiten Datei hieß dieselbe Farbe brand-600. Der Rebrand ist eine einzige Änderung — der Wert wechselt, der Name sagt weiterhin die Wahrheit, nichts stromabwärts bewegt sich.

Die Benennung von Farb-Tokens funktioniert in Schichten — bis zu drei. Die Primitiv-Schicht benennt den Platz einer Farbe in der Palette (brand-600); die semantische Schicht benennt UI-Aufgaben (background, text-primary, accent) und zeigt auf Primitive; die optionale Component-Schicht (button-bg) existiert nur dort, wo eine Komponente sich echt von der Semantik lösen muss. Auf der Primitiv-Ebene schlägt brand-600 das blue-600 bei einer Single-Brand-Palette, weil es die Rolle benennt, die eine Farbe spielt, und nicht den Farbton, den sie zufällig hat — auch wenn Farbton-Namen für rohe Paletten mit vielen Farbtönen eine vertretbare Wahl bleiben. Was die Zahl selbst bedeutet — die Skalen-Position hinter der 600 — behandelt unser Leitfaden zu Farbskalen; dieser Artikel handelt von den Wörtern davor.

Sollten Primitive brand-600 oder blue-600 heißen?

Beide Positionen verdienen ihre ehrliche Darstellung.

Das Argument für brand-600: Die stabile Tatsache eines Primitivs ist seine Position in der Palette dieses Produkts, nicht seine Wellenlänge. Die Palette hat einen Haupt-Farbton, einen Satz Neutraltöne, vielleicht eine Sekundärfarbe — das sind Rollen, und sie überstehen jedes Ereignis im Leben der Palette. Der Farbton ist die volatile Eigenschaft: Rebrands ändern ihn, und das Eingangsszenario zeigt, was der Name blue-600 dann kostet. Niemand, der eine Single-Brand-Palette nutzt, musste je wissen, dass die Markenfarbe blau ist; man musste wissen, dass sie die Markenfarbe ist. Die Paletten-Gruppen des Scale Composer sind nach genau diesem Prinzip benannt — Brand, Secondaries, Neutral, Functional — Rollen zuerst, Farbtöne nirgends.

Das Argument für blue-600: In einem System mit vielen Farbtönen gibt es womöglich keine Rolle zu benennen. Eine rohe Palette, die zwanzig Farbtöne als Allzweck-Material ausliefert — Tailwinds Position —, hat keine „Brand” unter ihnen; der Farbton ist der einzige ehrliche Name, den eine solche Palette anbieten kann, und blue-600 ist dort genau richtig. Dieselbe Logik gilt für kategoriale Diagramm-Sets, in denen sechs Farbtöne gleichrangig sind, ohne Hierarchie, die es zu kodieren gäbe.

Die Faustregel ergibt sich sauber: Gehört die Palette zu einer Marke, benenne Primitive nach Rolle; ist sie ein Malkasten, der vielen Herren dient, benenne sie nach Farbton. Die meisten Produkt-Design-Systeme gehören zur ersten Sorte und erben die Namen der zweiten, indem sie die Konventionen eines Frameworks kopieren — und so beginnt blue-600, nach einem Rebrand zu lügen, den niemand geplant hatte.

Was fügt die semantische Schicht hinzu?

Indirektion mit Bedeutung. Semantische Tokens benennen Aufgaben — background, surface, border, text-primary, text-secondary, accent, die Farben für interaktive Zustände — und jedes zeigt auf ein Primitiv. Komponenten konsumieren semantische Tokens und fassen Primitive nie direkt an.

Der Gewinn: Bedeutung und Wert werden unabhängig voneinander änderbar. Eine Komponente, die gegen text-primary geschrieben ist, funktioniert in jedem Theme, weil der Name eine Aufgabe verspricht, keinen Wert; eine Komponente, die gegen brand-900 geschrieben ist, hat eine Annahme darüber fest verdrahtet, welche Stufe diese Aufgabe heute zufällig erfüllt. Diese Schicht ist auch der Ort, an dem Barrierefreiheit natürlich lebt: Eine Aufgabe wie „primärer Text auf dieser Fläche” trägt eine Kontrast-Anforderung, also ist das Token, das die Aufgabe benennt, der richtige Ort, um sie durchzusetzen. Scale Composer leitet auf diese Weise rund siebzehn semantische Rollen pro Fläche ab — jede Rolle zeigt auf eine Skalen-Stufe, geprüft gegen WCAG-Untergrenzen (4,5:1 für Fließtext, 7:1 für die strengere Stufe), mit APCA daneben. Das Token-System von Material Design dokumentiert dieselbe geschichtete Architektur — reference-, system- und component-Tokens in seiner Übersicht zu design tokens — unter anderen Schicht-Namen.

Sieh dir die Schichten an einer echten Palette im Scale Composer an — die Primitiv-Rampen nach Rolle gruppiert, die semantischen Rollen einer Fläche, die in sie hineinzeigen, und das Export-Panel, das beide Schichten als DTCG, CSS, Tailwind oder Figma Variables hinausträgt.

Wann verdient sich eine Component-Schicht ihren Platz?

Selten — und das ist das Design dieser Schicht, nicht ihre Schwäche. Ein Component-Token wie button-bg ist gerechtfertigt, wenn eine Komponente sich von der semantischen Schicht lösen muss: Die Marketing-Website richtet accent auf einen Sekundär-Farbton neu aus, aber der primäre Button muss auf der Markenfarbe bleiben — also folgt button-bg nicht mehr accent, sondern klammert sich ans Marken-Primitiv. Das ist eine echte Entkopplung, und das Token hält sie fest.

Ohne eine solche Abweichung ist ein Component-Token Indirektion ohne Bedeutung: button-bg → accent → brand-600, drei Namen für einen Wert, der nie unabhängig variiert. Über eine ganze Komponenten-Bibliothek multipliziert, entstehen so die Token-Sets, durch die niemand mehr navigieren kann. Eine vernünftige Voreinstellung: Führe das Component-Token ein, wenn die Ausnahme auftaucht, nicht im Voraus.

Was bringen dir die Schichten, wenn sich etwas ändert?

Drei Szenarien, mit der blauen Ausgangsfarbe #2563eb — oklch(0.546 0.215 262.9) — stellvertretend für die Marke.

Rebrand. Die Palette wird aus einer türkisen Ausgangsfarbe neu abgeleitet. Primitive behalten ihre Namen und tauschen Werte — brand-600 speichert nicht mehr ≈#3E65B5, ist aber immer noch die 600 der Marken-Rampe. Die semantische Schicht, die auf Namen statt auf Werte zeigt, ändert sich überhaupt nicht. Komponenten bemerken nichts.

Dark Mode. Semantische Namen behalten ihre Bedeutung, während ihre Ziele sich verschieben: accent zeigt im hellen Theme auf brand-600 (≈#3E65B5) und im dunklen auf eine hellere Stufe wie brand-300 (≈#71AEFF), wo ein dunkler Hintergrund für den Kontrast einen helleren Akzent verlangt. Die Werte stammen sogar aus verschiedenen Rampen — eine abgeleitete dunkle Palette wird mit einer eigenen Helligkeits-Kurve und einer Chroma-Anhebung von rund 20 % erzeugt — und doch sagt eine Komponente immer noch nur accent.

Ein Primitiv, mehrere Aufgaben. Dasselbe brand-600 kann auf einer Fläche als accent-Text dienen und auf einer anderen als Ruhefüllung eines Buttons. Ein gespeicherter Wert, mehrere Bedeutungen — und die Bedeutungen leben in der semantischen Schicht, was der ganze Grund für ihre Existenz ist. Kollabiere die Schichten, und jede dieser Änderungen wird zu einem Suchen-und-Ersetzen quer durch die Komponenten.

Die Benennung ist auch der Teil eines Token-Systems, der das Werkzeug überlebt, das es erzeugt hat: Die hier gewählten Namen sind das, was jeder Export in Code- und Design-Dateien trägt, mit hex neben dem OKLCH. Und der Migrationspfad läuft in beide Richtungen. Importiere deine bestehende Token-Datei und benenne eine Schicht um — lade eine DTCG-Datei, benenne nach Farbton benannte Primitive in Rollen-Namen um und exportiere erneut; der Rundlauf bewahrt die Abschnitte, die du nicht angefasst hast, sodass eine Benennungs-Bereinigung genau die Tokens kostet, die sie umbenennt.