So verwendest du semantische Farb-Tokens

Deine Marke ist grün. Der wichtigste Button ist grün, die Erfolgsmeldung ist grün und der ausgewählte Navigationseintrag auch. Alles wirkt abgestimmt, bis die Marke auf Violett wechselt. Soll nun auch ein erfolgreicher Upload violett werden? Was passiert mit dem Fokusrahmen oder der Warnung an einem bald ablaufenden Konto?

Semantische Farb-Tokens machen diese Entscheidungen ausdrücklich. Ein primitives Token benennt einen Farbwert, etwa green-700. Ein semantisches Token benennt seine Aufgabe, etwa action-primary-background oder status-success-text. Komponenten beziehen sich auf die Aufgabe. So kann ein Markenwechsel die beabsichtigten Rollen ändern, ohne versehentlich jede Verwendung einer ähnlichen Farbe mitzuverändern.

Beginne mit dem Fehler, den du verhindern möchtest

Stell dir einen Arbeitsbereich mit „Projekt erstellen“, einer Bestätigung „Gespeichert“, einer Fehlermeldung und einem ausgewählten Seitenleistenlink vor. Die ursprüngliche Gestaltung nutzte dasselbe dunkle Grün für Button, Bestätigung und ausgewählten Link. Eine Entwicklerin speicherte den Wert vernünftigerweise einmal und verwendete ihn mehrfach. Nun verlangt die neue Markenrichtung eine andere Primärfarbe.

Das Ändern der gemeinsamen Grünvariable aktualisiert alle drei Elemente. Die Umsetzung bleibt mit dem ursprünglichen Code konsistent, die Entscheidung ist trotzdem falsch: Die Bestätigung war grün, weil sie Erfolg vermittelt, nicht weil sie die wichtigste Markenaktion darstellt. Diese Unterscheidung existierte im Kopf der gestaltenden Person, gelangte aber nie in wiederverwendbare Regeln.

Halte vor dem Anlegen von Tokens diese Unterscheidung in Alltagssprache fest. „Die Hauptaktion folgt der Produktmarke. Erfolgsrückmeldungen behalten ihre Statusbedeutung. Auswahl braucht einen klaren aktiven Zustand.“ Diese Aussagen sind wertvoller als der Einstieg über Namenskonventionen. Sie erklären, welche Werte gemeinsam verändert werden dürfen.

So macht Atlassian Rollen an der Oberfläche sichtbar

Atlassians Farbempfehlungen ordnen einem Jira-Board Tokens für Auswahl, Text und den Hintergrund eines Markenbuttons zu. Die Begrifflichkeit unterscheidet Farbrollen, Betonung und Interaktionszustand. Sie trennt außerdem Auswahl vom Tastaturfokus: Ein ausgewähltes Element soll seine Auswahldarstellung behalten, wenn ein Fokusindikator hinzukommt.

Hier zeigt sich, warum eine kommentierte Oberfläche hilfreicher ist als eine Palette allein. Ein Farbfeld nennt den Wert. Das Board zeigt, welcher Teil des Erlebnisses ihn verwenden soll und warum. Man erkennt, ob die Beschriftung Text, Fläche oder Symbol betrifft, statt die beabsichtigte Verwendung aus der Sättigung zu erraten.

Übernimm für ein kleines System zuerst diese Gewohnheit, nicht den gesamten Namenskatalog. Setze das vorgeschlagene Token neben eine echte Verwendung, beschreibe seinen Änderungsanlass und zeige eine Verwendung, die es nicht steuern soll. „Markenaktion“ und „erfolgreicher Vorgang“ können dasselbe Grün nutzen und trotzdem unabhängige Entscheidungen bleiben. Kann deine Zuordnung diesen Unterschied nicht ausdrücken, speichert sie eine Palette statt der Oberflächensemantik.

Mache den Abhängigkeitstest konkret

Eine kleine Alias-Zuordnung reicht, um den Fehler sichtbar zu machen. Im Beispiel beginnen Erfolg und Hauptaktion mit demselben Wert, beziehen sich aber auf getrennte Rollen:

:root {
  --palette-green-700: #236646;
  --palette-purple-700: #6439a8;
  --action-primary-bg: var(--palette-green-700);
  --action-primary-fg: #fff;
  --status-success-text: var(--palette-green-700);
}
[data-brand="purple"] {
  --action-primary-bg: var(--palette-purple-700);
}

Ein geändertes Markenattribut sollte die Verwendungen von --action-primary-bg verändern. Es sollte keine Erfolgsbeschriftung verändern, die --status-success-text verwendet. Ändert sich beides, prüfe vor der Wahl eines anderen Farbtons die tatsächlichen Komponentenreferenzen. Ändert sich nichts, suche nach fest eingetragenen Werten oder spezifischeren Überschreibungen. Das ist ein Abhängigkeitstest. Die Beispielwerte brauchen in ihren tatsächlichen Kontexten weiterhin Kontrastprüfungen.

Prüfe anschließend Vorder- und Hintergrund zusammen. Aktionsfläche und Beschriftung sind ein Paar. Wird nur die Fläche geändert, kann eine zuvor lesbare Beschriftung scheitern, besonders beim Wechsel von einer dunklen zu einer hellen Markenfarbe. Dokumentiere die verbundene Rolle in der Zuordnung. Eine Änderung soll die Prüfung des Gegenstücks auslösen, statt vom Gedächtnis der prüfenden Person abzuhängen.

Prüfe die Migration in drei Durchgängen:

1. Werte unverändert lassen. Aliasse einführen und die visuelle Ausgangslage vergleichen. Unerwartete Unterschiede deuten auf Zuordnungsfehler hin.
2. Vorübergehend eine Rolle ändern. Alle vorgesehenen Verwendungen prüfen, auch Elemente, die unverändert bleiben sollen.
3. Das freigegebene Theme wiederherstellen. Hover-, Fokus-, deaktivierte und ausgewählte Kombinationen prüfen. Bewusste Rohwerte getrennt von unfertiger Migration dokumentieren.

Trenne Werte, Rollen und Komponentenentscheidungen

Ein kleines System kann mit zwei Ebenen beginnen. Die Wertebene enthält die eigentlichen Farben. Die Rollenebene ordnet sie Oberflächenzwecken zu. Eine dritte, komponentenspezifische Ebene hilft, wenn sich eine Komponente unabhängig weiterentwickeln muss. Sie ist nicht für jedes kleine Projekt zwingend.

neutral-950 könnte beispielsweise den dunkelsten Neutralton enthalten. text-primary und border-strong könnten zunächst beide darauf zeigen. Sie bleiben unterschiedliche Rollen, weil bessere Fließtextlesbarkeit nicht zwangsläufig jeden starken Rahmen dunkler machen soll. Heute identische Werte beweisen keine dauerhaft gemeinsame Entscheidung.

Der umgekehrte Fehler ist ein eigenes Token für jedes sichtbare Element. Erfüllen alle gewöhnlichen Fließtextabsätze dieselbe Rolle, bringt ein Text-Token pro Absatz Wartung ohne Bedeutung. Frage: Würden wir diese Verwendung jemals absichtlich ändern wollen, ohne die andere zu ändern? Falls ja, kommen getrennte Rollen infrage. Falls nein, verwende die bestehende Rolle erneut.

Namen sollten bei der richtigen Wahl helfen, ohne jede Komponente öffnen zu müssen. Wer einen Fehlerrand für ein Eingabefeld sucht, sollte nicht raten müssen, ob accent-strong, special-red oder brand-secondary Gefahr bedeutet. Eine verständliche Rolle ist besser als eine clevere Abkürzung, besonders wenn auch ein Coding-Agent denselben Kontext nutzen soll.

Ordne semantische Farben Oberflächenrollen zu

Prüfe zunächst eine repräsentative Seite in mehreren Zuständen. Ein statischer Dashboard-Screenshot zeigt weder deaktivierte Aktionen noch Validierungsrückmeldungen, Tastaturfokus oder ausgewählte Menüeinträge. Du brauchst genug Zustände für tatsächliche Farbaufgaben, nicht jeden theoretischen Zustand, den eine große Organisation irgendwann unterstützen könnte.

Für den fiktiven Arbeitsbereich kann die erste Zuordnung Seitenhintergrund, erhöhte Fläche, Haupt- und Zusatztext, gewöhnlichen Rahmen, Hauptaktion, Text auf dieser Aktion, Auswahl, Fokus, Erfolg, Warnung und Fehler umfassen. Manche Rollen brauchen ein Vordergrund-Hintergrund-Paar. Eine helle Erfolgsfläche und ihr dunkler Text haben unterschiedliche Werte mit gemeinsamem Zweck.

Die erste Prüfung ist eine Zuordnungsaufgabe. Markiere jede sichtbare Farbe der Beispielseite und frage, was sie vermittelt. Gruppiert ein hellgrünes Panel nur zusammengehörige Bedienelemente, gehört es zu einer Flächen- oder Gruppierungsrolle. Meldet es einen erfolgreichen Vorgang, gehört es zur Rückmeldung. Beide können ähnlich aussehen, ihre künftigen Änderungen sollten aber verschiedenen Regeln folgen.

Halte die Beschreibung neben dem Tokennamen fest. „Hintergrund der Hauptaktion: die wichtigste verfügbare Aktion innerhalb eines Bereichs“ hilft mehr als „grün“. Ergänze bei Verwechslungsgefahr ein Gegenbeispiel: Das Token bedeutet nicht „alles, was auffallen soll“. Eine wichtige Fehlermeldung braucht weiterhin die passende Rückmeldungsrolle.

Spiele einen Markenwechsel vor der Festlegung durch

Hier ein bewusst kleines Beispiel. Der Arbeitsbereich startet mit grüner Markenaktion und grünem Erfolgsfeedback. Später wechselt die Aktionsfarbe zu einem anderen Markenton. Button und ausgewählte Navigation sollen der neuen Richtung folgen, „Gespeichert“ aber die erkennbare Erfolgsrolle behalten.

Bestimme zuerst die betroffenen Rollen. Buttonhintergrund und Vordergrundtext müssen gemeinsam geprüft werden. Auswahl kann eine eigene markenbezogene Fläche oder einen Indikator nutzen. Das Logo ist eine Markendatei, kein gewöhnliches Button-Token. Färbe es nicht über allgemeine Oberflächenregeln um, ohne seine eigenen Anforderungen zu berücksichtigen.

Ändere anschließend die Rollenzuordnung in einer Kopie der Seite. Ersetze nicht wahllos jedes Vorkommen des alten Hexwerts. Eine Rohwertsuche findet Kandidaten, verrät aber nicht, ob eine Stelle einen Link, einen Erfolgszustand oder ein Illustrationsdetail darstellt.

Prüfe zum Schluss alle Verwendungen der geänderten Rollen. Die Hauptaktion kann auf einer weißen Seite, in einem hellen Panel und in einem Dialog erscheinen. Eine neue Füllung, die in einem Kontext kräftig wirkt, kann im anderen verschwinden. Die Änderung ist erst vollständig, wenn alle vorgesehenen Verwendungen weiterhin die richtige Aktion verständlich und lesbar vermitteln.

Beschreibe Zustände, ohne für alles eine neue Farbe zu schaffen

Das Standardaussehen einer Aktion ist nur ein Teil ihres Verhaltens. Hover, gedrückt, fokussiert, ausgewählt und deaktiviert können Verschiedenes ausdrücken. Ein Navigationseintrag kann ausgewählt bleiben und zugleich Tastaturfokus erhalten. Ein Button kann fokussiert sein, ohne gedrückt zu sein. Fasse diese Bedingungen nicht zu einer einzigen „aktiven“ Farbe zusammen.

Beginne mit der Information jedes Zustands. Hover vermittelt eine Zeigerbeziehung. Fokus zeigt bei Tastaturbedienung, wo die Interaktion stattfinden wird. Auswahl kennzeichnet eine anhaltende Entscheidung. Die Darstellungen können Zutaten teilen, müssen aber bei gemeinsamem Auftreten unterscheidbar bleiben. Rahmen, Unterstreichung, Symbol oder Form können Teile der Bedeutung tragen.

Für die Beispielseitenleiste wären eine dezente Auswahlfläche und ein deutlicher Fokusrahmen denkbar. Der Rahmen darf nicht verschwinden, nur weil der Eintrag schon ausgewählt ist. Prüfe diesen kombinierten Zustand direkt. Isolierte Farbfelder zeigen nicht, ob sich beide Darstellungen in der Komponente behindern.

Deaktivierte Gestaltung braucht dieselbe Sorgfalt. Kann die Person den Grund nicht erschließen, braucht die nicht verfügbare Aktion eine Erklärung. Grau sagt nicht, ob ein Pflichtfeld fehlt, eine Berechtigung fehlt oder ein Vorgang bereits läuft. Ein Token benennt eine visuelle Rolle; es ersetzt weder Interaktionslogik noch erklärenden Text.

Halte komponentenspezifische Ausnahmen sichtbar. Braucht eine destruktive Bestätigung einen eigenen Buttonstil, dokumentiere den Zweck, statt in einem Dialog still das Hauptaktions-Token zu ersetzen. Die Ausnahme kann berechtigt sein. Problematisch wird es, wenn niemand ihre Absicht von einer einmaligen Abkürzung unterscheiden kann.

Verbinde Farbe mit lesbarer Bedeutung

Farbe erleichtert das Überfliegen, doch Bedeutung muss auch bei schwer unterscheidbaren Farbtönen erhalten bleiben. Ein roter Rahmen allein lässt Nutzer erraten, was schiefging. Fehlerbeschriftung und brauchbarer Korrekturhinweis machen den Zustand verständlich. Ebenso vermittelt ein Erfolgssymbol mit „Änderungen gespeichert“ mehr als ein unbeschrifteter grüner Punkt.

Die W3C-Empfehlungen zur Farbnutzung erklären, dass Informationen oder Handlungen nicht allein durch Farbe erkennbar sein dürfen. Wende das auf jede Rolle im Kontext an. In unserem Arbeitsbereich erhalten Statusmeldungen lesbaren Text, ausgewählte Einträge eine erkennbare Auswahldarstellung und Links mehr als einen subtilen Farbunterschied.

Kontrast ist eine separate Prüfung. Eine Farbe kann die richtige Bedeutung vermitteln und trotzdem zu blass zum Lesen sein. Bewerte Vordergrund-Hintergrund-Paare, statt ein Markenfarbfeld pauschal „barrierefrei“ zu nennen. Dunkler Text auf heller Erfolgsfläche ist eine andere Kombination als weißer Text auf einem gesättigten Erfolgsbutton.

Für normalen Text fordert das WCAG-Mindestkontrastkriterium grundsätzlich 4.5:1, für entsprechend großen Text 3:1, jeweils mit definierten Ausnahmen. Die W3C-Erklärung zum Mindestkontrast erläutert Geltung und Details. Miss das tatsächliche Paar und seine gerenderte Verwendung. Ein bestandenes Paar zertifiziert keine Komponente, kein Theme und keine ganze Website.

Die Beispielwerte machen das greifbar. Die Berechnung der relativen Leuchtdichte ergibt für Grün #236646 und Violett #6439a8 gegenüber Weiß Kontrastverhältnisse von 6.86:1 und 7.80:1. Gegenüber Schwarz ergeben dieselben Füllungen 3.06:1 und 2.69:1. Beide unterstützen damit weiße Beschriftungen beim Grenzwert für normalen Text, schwarze dagegen nicht. Der semantische Name stellt das nicht sicher. Ausschlaggebend sind die konkreten Vorder- und Hintergrundwerte. Halte die Rechnung am jeweiligen Paar fest, damit eine spätere hellere Markenfarbe eine neue Prüfung auslöst.

Behebe nicht jeden Fehler, indem du die gesamte Oberfläche abdunkelst. Prüfe, welche Rolle auf welcher Fläche in welchem Zustand scheitert. Auch Zusatztext hat eine Leseaufgabe. Ein zu blasser Hilfetext wird durch die Bezeichnung „subtil“ nicht besser. Umgekehrt kann jede Trennlinie als kräftiger dunkler Strich die gewünschte Hierarchie zerstören.

Prüfe ein dunkles Theme als neue Zuordnung

Ein dunkles Theme ist ein nützlicher Belastungstest, weil es Zweck und Erscheinung trennt. Haupttext bleibt Haupttext, sein Wert ändert sich aber. Eine erhöhte Fläche muss sich weiterhin vom Seitenhintergrund unterscheiden. Erfolgsfeedback bleibt verständlich, auch wenn Vorder- und Hintergrund andere Werte als im hellen Theme haben.

Invertiere nicht einfach alle primitiven Werte und verwende nicht unverändert die hellen Werte vor einer dunklen Seite. Prüfe die Beziehungen neu. Eine auf Weiß ausgewogene helle Aktion kann eine dunkle Fläche dominieren. Ein auf blassem Panel sanfter Rahmen kann verschwinden. Auch Bilder, Logos und Diagramme brauchen womöglich Entscheidungen außerhalb der semantischen Farbzuordnung.

Verwende in beiden Vorschauen dieselben Inhalte. Unterschiede bei Dichte oder Bildern lenken sonst von Farbentscheidungen ab. Zeige Formularfehler, Erfolgsmeldung, ausgewählte Navigation, fokussiertes Bedienelement und Zusatztext. Diese Zustände liefern mehr als eine Galerie schöner Standardbuttons.

Die Rollennamen bleiben stabil. Wenn du im dunklen Theme text-primary in white-text umbenennen möchtest, setzt du einen Wert in einen Namen zurück, der eigentlich eine Aufgabe beschreiben soll. Erhalte die Bedeutung und ändere ihre Zuordnung.

Gib einem Coding-Agent die Zuordnung, nicht nur die Palette

Wenn ein Agent eine Seite verbessern soll, liefere die Rollenentscheidungen neben der visuellen Referenz. Ein Screenshot zeigt aktuelle Farben. Er erklärt nicht, welche beim Markenwechsel gekoppelt bleiben sollen oder welche Zustandskombinationen weiter funktionieren müssen. Eine kurze Zuordnungstabelle und eine repräsentative Komponente machen die Absicht viel leichter prüfbar.

In unterstützten OpenDesign-HTML-Vorschauen kannst du das gerenderte Ergebnis prüfen, verfügbare manuelle Stilwerkzeuge nutzen und Kommentare zum betreffenden Bereich in die Unterhaltung geben. Benenne damit eine konkrete Abweichung, etwa eine Erfolgsmeldung im Hauptaktionsstil. Das Feedback sollte neben der sichtbaren Stelle auch die vorgesehene Rolle nennen.

Bitte den Agent etwa, die Hauptaktionszuordnung zu ändern und Erfolgs- sowie Fehlerrollen zu erhalten. Lass anschließend die betroffenen Buttons in ihren unterschiedlichen Zuständen zeigen. Hat das Projekt bereits Tokenkonventionen, gib die Dateien oder den Gestaltungskontext mit. Verlange im Rahmen einer kleinen Farbkorrektur kein völlig neues Namenssystem.

Prüfe nach der visuellen Korrektur die Komponentenreferenz in den erzeugten Dateien. Der Button kann richtig aussehen und trotzdem das Erfolgstoken verwenden. Beim nächsten Themewechsel würde derselbe Abhängigkeitsfehler zurückkehren.

Migriere zuerst eine repräsentative Komponente

Du kannst semantische Rollen einführen, ohne die ganze Website auf einmal zu ersetzen. Wähle eine Komponente mit mehreren bedeutungsvollen Zuständen, etwa das Formular zur Projekterstellung. Liste aktuelle Werte auf, bestimme ihre Rollen und ordne sie der bestehenden Palette zu. Die sichtbare Gestaltung kann anfangs fast unverändert bleiben.

Ändere dann eine Rollenzuordnung kontrolliert. Sollen Hauptaktionen gemeinsam wechseln, prüfe die beabsichtigten Buttons. Sollen Statusmeldungen unabhängig bleiben, prüfe, dass sie der Aktionsfarbe nicht folgen. Der Test betrifft die Abhängigkeit, nicht die Eignung der vorübergehenden Farbe als endgültige Markenwahl.

Dokumentiere Verwendungen, die weiterhin Rohwerte nutzen. Manche sind bewusst: Illustration, Partnerlogo oder Datenvisualisierung gehören vielleicht nicht derselben Oberflächenrolle an. Andere sind noch offene Migration. Kennzeichne den Unterschied, damit unvollständige Umstellung nicht für eine freigegebene Ausnahme gehalten wird.

Funktioniert die repräsentative Komponente richtig, weite die Arbeit auf verwandte Komponenten aus. Prüfe die gerenderte Seite nach jeder wesentlichen Gruppe, statt einem globalen Ersetzen zu vertrauen. Gemeinsame Regeln können gerade nicht geöffnete Kontexte betreffen. Eine kleine Migration findet sie, bevor die gesamte Oberfläche schwieriger vergleichbar wird.

Was eine nützliche Tokenprüfung hinterlassen sollte

Am Ende steht eine brauchbare Zuordnung: Rollennamen, beabsichtigte Zwecke, aktuelle Werte nach unterstütztem Theme und einige repräsentative Komponenten mit ihren Zuständen. Ergänze Hinweise auf gekoppelte Rollen wie Text auf einer Aktionsfläche. Halte wichtige Ausnahmen fest, ohne aus jedem Pixel eine eigene Richtlinie zu machen.

Bitte ein Teammitglied, anhand dieser Zuordnung das Token für eine neue Erfolgsmeldung und eine neue Hauptaktion zu wählen. Gelingt das ohne Raten anhand der Farbfelder, leistet das System nützliche Arbeit. Führen beide Entscheidungen weiterhin zu „Nimm das Markengrün“, kläre zuerst die Rollenbeschreibungen, bevor du weitere Tokens ergänzt.