Markenrichtlinien vs. Design Tokens

Öffne ein Markenrichtlinien-PDF und eine Design-Tokens-Datei nebeneinander, beide auf „dasselbe” Blau. Die PDF-Seite zeigt ein Farbmuster, einen Absatz über Selbstsicherheit und Klarheit und einen hex-Code als Bildunterschrift gesetzt — ein Abbild des Werts. Die Tokens-Datei zeigt "brand-600": { "$value": "#2563eb" } — den Wert selbst, in einer Form, die Figma und eine Build-Pipeline direkt lesen. Das eine ist Dokumentation über die Farbe; das andere ist die Farbe, soweit es Software betrifft.

Markenrichtlinien und Design Tokens erfüllen unterschiedliche Aufgaben, und die meisten Organisationen brauchen beides: Richtlinien tragen die Absicht — warum die Marke so aussieht, wie sie aussieht, die Stimme, die Dos und Don’ts, die Geschichte, die ein Mensch braucht, um eine Ermessensentscheidung zu treffen — während Tokens die Werte tragen, die maschinenlesbaren Antworten, die Design- und Build-Tools ohne Interpretation verarbeiten. Der Fehlermodus, der einen Artikel wert ist, besteht darin, das eine für die Aufgabe des anderen zu benutzen. Dieser hier ist Teil unseres Leitfadens zu Markenfarben.

Welche Aufgabe erfüllen Markenrichtlinien eigentlich?

Richtlinien — das Brand Book in seiner klassischen Form — existieren, um Urteilsvermögen zu übertragen. Sie erklären, warum das Blau blau ist, was es vermitteln soll, wo es hingehört und wo es niemals auftauchen darf, wie sich die Fotografie anfühlt, wie die Marke spricht. Ihr Leser ist ein Mensch, der gerade eine Entscheidung treffen will, die die Regeln nicht vorhergesehen haben: ein neues Partnerschafts-Deck, eine Messewand, ein Format, das noch niemand entworfen hat. Die Absicht ist das, was sich auf den unvorhergesehenen Fall verallgemeinern lässt — ein Wert allein kann dir nicht sagen, ob das Neue markenkonform ist.

Welche Aufgabe erfüllen Design Tokens?

Tokens sind die Entscheidungen der Marke als benannte Werte: brand-600 ist genau diese Farbe, text-primary diese, space-4 diese Anzahl an Pixeln. Ihre Konsumenten sind meist keine Menschen — Figma-Variablen, Stylesheets, Komponentenbibliotheken und Build-Schritte lesen sie direkt, typischerweise in einem Standardformat wie DTCG JSON. Ein Token beantwortet genau eine Art von Frage — was ist der Wert — und beantwortet sie für jeden Konsumenten identisch, jedes Mal. Genau diese Gleichheit ist der springende Punkt: keine Interpretation, keine Annäherung, keine Version des Blaus, die davon abhängt, wer sie kopiert hat.

Was geht schief, wenn das eine die Aufgabe des anderen übernimmt?

Ein PDF als Wertequelle verfällt durch Annäherung. Wenn das Brand Book der Ort ist, an dem die Werte leben, extrahiert sie jeder Leser von Hand: eine Pipette auf dem Farbmuster (oft aus einem komprimierten Export), ein aus dem Gedächtnis neu getippter hex-Code, ein per Auge abgeglichener Screenshot. Jede Kopie driftet ein wenig, jede künftige Fläche kopiert von der nächstgelegenen vorherigen, und innerhalb weniger Jahre hat die Marke fünf Blautöne, von denen keiner maßgeblich ist. Der Mechanismus ist menschliches Lesen — eine Person drückt neu aus, was sie gesehen hat, und im Neu-Ausdrücken schleicht sich der Fehler ein.

Tokens als Absichtsquelle erklären nichts. Eine JSON-Datei kann einem neuen Designer sagen, dass brand-600 gleich #2563eb ist; sie kann ihm nicht sagen, warum, oder dass das Blau für Aktionen reserviert ist, oder dass eine Seite damit zu fluten genau das ist, was die Marke niemals tun sollte. Wenn der unvorhergesehene Fall eintritt, bietet ein reines Werte-System keine Hilfe — und der Designer improvisiert, plausibel und off-brand.

Die intuitive Fassung: Menschen behalten den Kern, Maschinen behalten die Koordinaten. Ein Artefakt, das sich an Menschen richtet, wird gelesen und weitererzählt, und Weitererzählen nähert nur an; ein Artefakt, das sich an Maschinen richtet, wird Bit für Bit kopiert. Leite die Geschichte an den Leser, der für Geschichten gebaut ist, und die Zahlen an den Leser, der für Zahlen gebaut ist.

Wie sieht dieselbe Entscheidung aus, in beiden Formen geschrieben?

Eine Markenentscheidung — Blau ist unsere Aktionsfarbe — geschrieben als jedes der beiden Artefakte.

Der Richtlinien-Absatz, der die Absicht trägt:

Blau ist unsere Aktionsfarbe. Es erscheint überall dort, wo wir etwas vom Leser verlangen — Buttons, Links, die eine hervorgehobene Zahl auf einer Preisseite — und nirgends sonst. Vor ruhigen Neutraltönen liest es sich als Entschlossenheit; über eine Seite verteilt liest es sich als Lärm. Die genauen Werte leben in der Token-Datei unter brand; interaktive Flächen nutzen accent mit seiner zugehörigen Textfarbe on-accent.

Die Token-Einträge, die die Werte tragen:

{
  "brand-600": { "$type": "color", "$value": "oklch(0.546 0.215 262.9)" },
  "accent":    { "$value": "{brand-600}" },
  "on-accent": { "$type": "color", "$value": "#ffffff" }
}

Dieses oklch(0.546 0.215 262.9) ist #2563eb, und weißer Text darauf misst ≈5,2:1 — deshalb kann on-accent deklariert statt improvisiert werden. Beachte, was jedes Artefakt trägt, das das andere nicht kann. Der Absatz hält „und nirgends sonst” fest — eine Regel über Zurückhaltung, die kein Token-Schema kodiert. Die Einträge halten den exakten Wert und seine verifizierte Paarung fest — eine Präzision, die kein Absatz übersteht, wenn man aus ihm neu abtippt.

Öffne die Farbentscheidungen dieser Richtlinie als lebendiges Token-Set im Scale Composer — das Blau als Ausgangsfarbe, die daraus abgeleitete Farbrampe und die semantischen Rollen mit ihren Kontrast-Checks direkt neben den Namen, auf die die Richtlinie verweist.

Das Blau einer Markenrichtlinie als Ausgangsfarbe im Scale Composer, mit der abgeleiteten Farbrampe und benannten semantischen Rollen neben ihren Kontrast-Checks

Wie sollten Richtlinien und Tokens verbunden sein?

Per Referenz, in einer Richtung. Die moderne Form sind Richtlinien, die Tokens benennen, statt Werte einzubetten: Das PDF zeigt die Farbe und sagt „das ist brand-600”; die Token-Datei besitzt die Zahl. Die Übergabelinie fällt natürlich — Richtlinien sagen unser Blau vermittelt Entschlossenheit und wird für primäre Aktionen verwendet; Tokens sagen brand-600 entspricht genau diesem Wert, und Figma und die Codebasis verarbeiten es direkt.

Der Grund ist die älteste Regel der Dokumentation: was an zwei Stellen steht, wird sich irgendwann widersprechen. Wenn das PDF #2563EB einbettet und die Token-Datei später korrigiert oder verfeinert wird, ist das PDF stillschweigend falsch — und es ist das Artefakt, von dem die Leute Screenshots machen. Wenn das PDF „brand-600” sagt, bleibt es durch jede Wertänderung hindurch wahr. Wo möglich, werden die Farbmuster-Seiten selbst aus der Token-Datei neu generiert, sodass sogar die Bilder Renderings der Quelle sind statt Rivalen zu ihr.

Wo fängst du an?

Bei welchem Artefakt du auch immer schon hast. Wenn Richtlinien existieren, aber keine Tokens, sammle jeden wörtlichen Wert, den das PDF nennt — die hex-Codes, die Schriftgrößen, die Abstands-Regeln — in einer einzigen Token-Datei und bearbeite dann die Richtlinien so, dass sie die Tokens benennen, statt die Zahlen einzubetten. Verwandle die Werte, die deine Richtlinien nennen, in eine einzige Token-Quelle — nutze die Markenfarbe als Ausgangsfarbe, leite die Farbrampe und die semantischen Rollen ab und exportiere die DTCG-, CSS- oder Figma-Variables-Datei, die deine Tools direkt lesen.