Einen Rebrand über Tokens ausrollen

Ein zusammengesetztes Bild, das viele Teams wiedererkennen werden: Der Rebrand ging übers Wochenende live. Montagmorgen war die Website im neuen Türkis online und der Launch-Thread war voller Jubel; bis Freitag hatte die Liste begonnen — das alte Blau in den E-Mail-Templates, der Checkout-Button, den kein Stylesheet kontrollierte, das Favicon, der PDF-Generator, der Header des Partner-Portals. Der Launch dauerte zwei Tage. Das Aufräumen dauerte ein Quartal, ein hartkodierter hex-Wert nach dem anderen.

Bei einem tokenisierten Produkt ist ein Rebrand ein Werte-Release, kein Rewrite: Leite das neue System aus der neuen Ausgangsfarbe ab, vergleiche die alten Token-Werte per Diff mit den neuen, verifiziere jede Kontrast-Paarung erneut, rolle das Release hinter Flags oder pro Oberfläche aus — und budgetiere separat für den langen Schwanz all dessen, was nie tokenisiert wurde. Das Wochenend-Team oben erledigte den ersten Schritt und übersprang den Rest. Dieser Artikel — Teil unseres Leitfadens zu Markenfarben — geht die Reihenfolge durch. Er setzt voraus, dass die strategische Arbeit schon erledigt ist: Die Pin-Liste, die benennt, was Wiedererkennung trägt und sich nicht bewegen darf, steht — und was folgt, ist die Mechanik, alles auszuliefern, was sich bewegen darf.

Warum ist ein Rebrand ein Werte-Release und kein Rewrite?

Weil in einem tokenisierten Produkt Komponenten nie Farben enthalten — sie referenzieren Rollen, und Rollen lösen sich zu Werten auf. Der Rebrand ändert die Antworten, nicht die Fragen: accent existiert weiterhin, speist weiterhin dieselben Buttons und löst sich einfach zu Türkis auf, wo es sich zu Blau aufgelöst hat. Nichts Strukturelles bewegt sich, und genau das macht die Änderung prüfbar, diffbar und umkehrbar — dieselben Eigenschaften, die ein Code-Release hat, denn es ist eines.

Wie leitest du das neue System ab?

Aus der neuen Ausgangsfarbe, nicht durch das Bearbeiten einzelner Werte. Lade in Scale Composer die design-tokens.json des Projekts, ersetze die Ausgangsfarbe durch die Rebrand-Farbe und leite neu ab: Die Farbrampe, die getönten Neutraltöne, die semantischen Rollen und ihre On-Colors werden aus der neuen Eingabe neu aufgebaut, während der Round-Trip bewahrt, was der Rebrand nicht berührt — die Schriftgrößenskala, die Abstände, die Rollenstruktur selbst. Neu abzuleiten statt von Hand zu bearbeiten ist aus einem stillen Grund wichtig: Die Werte des alten Systems waren miteinander verwandt (Tönungen einer Ausgangsfarbe, gegen Flächen verifizierte Text-Paarungen), und Handedits brechen diese Beziehungen Wert für Wert, ohne dass es jemandem auffällt — bis zum Paletten-Audit.

Warum ist der Token-Diff der eigentliche Umfang des Rebrands?

Weil, wenn du die alte und die neue Token-Datei zur Hand hast, der Diff zwischen ihnen der technische Umfang des Rebrands ist — Zeile für Zeile prüfbar, wie Code. Hier ein Mini-Diff, sechs Tokens, alt → neu:

Die Zeile danger-600 ist die, bei der du kurz innehalten solltest. Irgendwo zwischen Konzept und Export hat jemand das Fehler-Rot „harmonisiert”, während er ohnehin in der Datei war — eine Änderung mit echten Folgen (bestehende Alerts verschieben sich, Screenshots in der Hilfe-Dokumentation veralten), die niemand entschieden hat. In einem nicht tokenisierten Rebrand läuft das unsichtbar mit; in einem Token-Diff ist es eine überraschende Zeile in einem Review. Überraschende Einträge im Diff sind sichtbar gemachtes Scope Creep — was die zweite Aufgabe des Diffs ist, nach dem Dokumentieren des Umfangs, dem alle zugestimmt haben.

Öffne die Vorher- und Nachher-Paletten in Scale Composer — die alten blauen Token-Werte importiert neben dem System, das aus der neuen türkisen Ausgangsfarbe abgeleitet wurde, mit den geänderten Werten und ihren Kontrast-Checks in einer Ansicht lesbar.

Warum ist die erneute Kontrast-Verifikation nicht verhandelbar?

Weil Paarungen, die unter den alten Werten bestanden haben, unter den neuen scheitern können — und zwar lautlos. Das Türkis aus dem Konzept-Deck — sagen wir #0d9488 — hält weißen Text nur bei ≈3,7:1, während das alte Blau ihn bei ≈5,2:1 hielt. Gleiche Rolle, gleiches weißes Label, neue Fläche: eine Barrierefreiheits-Regression, ausgeliefert als ästhetische Entscheidung. Deshalb zeigt der Diff oben, dass brand-600 bei #0f766e landet (≈5,5:1 mit Weiß) — dunkler als das Türkis aus dem Deck, weil die Neu-Ableitung die Mindestwerte durchsetzt und den auszuliefernden Wert so weit schiebt, bis die Paarung besteht. Die On-Color-Neu-Ableitung fängt den Großteil dieser Klasse automatisch ab; was sie nicht abfangen kann, sind Paarungen, die außerhalb des Systems entstanden sind — und das ist das Problem von Schritt fünf.

Wie rollst du das Release stufenweise aus?

Wie jedes Release: schrittweise, mit einem Weg zurück. Weil Alt und Neu zwei Wertesätze hinter denselben Rollen sind, kann ein tokenisiertes Produkt beide gleichzeitig betreiben — was aus dem Big-Bang-Rebrand einen kontrollierten Rollout macht. Leg den neuen Satz hinter einen Feature Toggle und aktiviere ihn pro Umgebung; oder rolle pro Oberfläche aus (zuerst die Marketing-Website, dann das Produkt, zuletzt die transaktionalen E-Mails); oder pro Markt, falls die Botschaft des Rebrands in Wellen ankommt. Die Teams, die Rebrands ruhig ausliefern, sind selten mutiger — sie haben nur dafür gesorgt, dass „Ups” ein Umlegen eines Flags ist statt eines erneuten Releases.

Was deckt das Token-Release nicht ab?

Alles, was nie ein Token referenziert hat — und die ehrliche Liste ist lang: hartkodierte hex-Werte in alten Templates (transaktionale E-Mails sind das klassische Nest), Rasterbilder mit eingebrannter alter Farbe, Favicons und App-Icons, generierte PDFs, Social-Templates im Account von wem-auch-immer-Instagram-macht, Einträge bei Drittanbietern und das gedruckte Material im Materiallager. Tokens bewahren dich nicht vor dem, was sie nie konsumiert hat; sie bewahren dich davor, die 90 % erneut zu bekämpfen, die es taten — damit sich die Suche auf diese Liste konzentrieren kann. Budgetiere die Suche als eigenen Workstream — grep nach den alten Werten in jedem Repository, inventarisiere die Assets, weise Verantwortliche zu. Das verlorene Quartal des Wochenend-Teams war genau diese Liste, entdeckt statt geplant.

Wo fängst du an?

Mit den zwei Artefakten, die jeder spätere Schritt konsumiert: der alten Token-Datei und der neuen, aus der Rebrand-Ausgangsfarbe abgeleiteten. Leite deine Palette aus der neuen Ausgangsfarbe neu ab und behalte den alten Satz daneben — lade die Tokens des Projekts, setze eine neue Ausgangsfarbe und vergleiche Wert für Wert: Die Änderungen sind der Umfang des Rollouts, sein Review und sein Testplan in einem.