Multi-Brand Design Tokens: Token-Architektur für Mehrmarken-Systeme

Das Problem mit flachen Token-Strukturen

Wer ein Design-System für eine einzelne Marke baut, kommt lange mit einer flachen Token-Datei aus: color-primary: #0057FF, font-size-lg: 1.25rem — fertig. Sobald eine zweite Marke ins Spiel kommt, bricht dieses Modell.

Die naheliegende Lösung — einen zweiten Token-Satz anlegen und alle Komponenten duplizieren — erzeugt exponentielle Wartungskosten. Jede Bugfix-Iteration, jedes neue Komponent, jede Accessibility-Anforderung muss n-mal durchgeführt werden. In der Praxis bedeutet das: Die zweite Marke hängt der ersten immer sechs Monate hinterher.

Die architektonisch korrekte Antwort ist Schichtentrennung. Markenentscheidungen wandern in eine eigene Token-Schicht; Komponenten referenzieren semantische Tokens, die wiederum auf Marken-Tokens zeigen. Die Komponente selbst weiß nicht, welche Marke aktiv ist.

Die vier Token-Schichten

Die Branche hat sich auf ein Modell geeinigt, das Brad Frost als Dreistufenarchitektur beschreibt, das in der Praxis aber vier funktionale Schichten hat. Der Unterschied liegt darin, wo die Markenlogik sitzt.

Schicht 1: Primitive Tokens

Primitive Tokens sind die Farbpalette des Systems — rohe Werte ohne jede Bedeutungszuweisung. Sie antworten auf die Frage: Welche Werte existieren überhaupt?

{
  "color": {
    "blue": {
      "100": { "$value": "#dbeafe", "$type": "color" },
      "500": { "$value": "#3b82f6", "$type": "color" },
      "900": { "$value": "#1e3a8a", "$type": "color" }
    },
    "zinc": {
      "50":  { "$value": "#fafafa", "$type": "color" },
      "900": { "$value": "#18181b", "$type": "color" }
    }
  }
}

Primitive Tokens werden nie direkt in Komponenten verwendet. Sie sind ausschließlich Referenzziele für die darüber liegenden Schichten. Nathan Curtis (EightShapes) nennt sie „Options” — das Inventar möglicher Werte, noch ohne Entscheidung.

Schicht 2: Semantische Tokens

Semantische Tokens weisen Primitiven eine Bedeutung zu. Sie antworten auf die Frage: Wofür wird dieser Wert verwendet?

{
  "color": {
    "interactive": {
      "$value": "{color.blue.500}",
      "$type": "color",
      "$description": "Primäre Interaktionsfarbe — Buttons, Links, aktive Zustände"
    },
    "surface": {
      "base": { "$value": "{color.zinc.50}", "$type": "color" },
      "elevated": { "$value": "#ffffff", "$type": "color" }
    },
    "text": {
      "primary":   { "$value": "{color.zinc.900}", "$type": "color" },
      "secondary":  { "$value": "{color.zinc.500}", "$type": "color" }
    }
  }
}

Der Schlüsselunterschied: Ein Komponente referenziert color.interactive, nicht color.blue.500. Wenn eine Marke Interaktion in Grün statt Blau darstellt, ändert sich ausschließlich die semantische Token-Datei — kein einziges Komponenten-Stylesheet wird berührt.

Schicht 3: Brand Tokens

Brand Tokens sind markenspezifische Overrides der semantischen Schicht. Sie existieren als separate Datei pro Marke und überschreiben nur die Tokens, die sich von der Standardmarke unterscheiden.

{
  "$extends": "../semantic/color",
  "color": {
    "interactive": {
      "$value": "{color.green.600}",
      "$description": "Marke B: Interaktionsfarbe ist Grün"
    }
  }
}

Das $extends-Schlüsselwort ist seit Oktober 2025 Teil der W3C Design Tokens Specification 2025.10. Es ermöglicht Deep-Merge-Vererbung: Eine Marken-Token-Datei erbt alle semantischen Tokens und überschreibt nur die abweichenden. Tokens auf demselben Pfad werden überschrieben; neue lokale Tokens werden ergänzt; alle übrigen Tokens werden unverändert vererbt.

Schicht 4: Komponenten-Tokens

Komponenten-Tokens sind komponentenspezifische Tokens, die auf semantische Tokens zeigen. Sie antworten auf die Frage: Welche semantische Eigenschaft verwendet diese Komponente an welcher Stelle?

{
  "button": {
    "primary": {
      "background": {
        "$value": "{color.interactive}",
        "$type": "color"
      },
      "text": {
        "$value": "{color.surface.elevated}",
        "$type": "color"
      },
      "background-hover": {
        "$value": "{color.interactive-strong}",
        "$type": "color"
      }
    }
  }
}

Komponenten-Tokens haben den Vorteil, dass Komponenten-Overrides möglich werden, ohne die semantische Schicht zu beschmutzen. Wenn eine Marke möchte, dass ihr primärer Button nicht die allgemeine Interaktionsfarbe, sondern eine eigene Akzentfarbe trägt, geschieht das auf Komponenten-Token-Ebene, nicht in der Komponente selbst.

Die Schichten in CSS umgesetzt

Die elegante Implementierung dieser Architektur in CSS nutzt Custom Properties und das Kaskadierungsverhalten des Browsers:

/* Schicht 1: Primitive */
:root {
  --color-blue-500: #3b82f6;
  --color-green-600: #16a34a;
  --color-zinc-900: #18181b;
}

/* Schicht 2: Semantik (Standard-Theme) */
:root {
  --color-interactive: var(--color-blue-500);
  --color-text-primary: var(--color-zinc-900);
}

/* Schicht 3: Marken-Override */
[data-brand="marke-b"] {
  --color-interactive: var(--color-green-600);
}

/* Schicht 4: Komponente */
.button-primary {
  background: var(--button-primary-background, var(--color-interactive));
  color: var(--button-primary-text, white);
}

Der Markenwechsel ist damit ein einziges DOM-Attribut: document.documentElement.setAttribute('data-brand', 'marke-b'). Kein JavaScript-Bundle-Switch, kein Stylesheet-Reload, keine Flash of Unstyled Content. Marken-Tokens können auch auf Subseitenebene oder innerhalb einzelner Komponenten gesetzt werden — das ermöglicht Seiten mit gemischten Marken-Kontexten, wie sie White-Label-Portale oder Vergleichsseiten benötigen.

Praxisbeispiel: Signify / Photon

Signify (früher Philips Lighting, seit 2016 eigenständig) verwaltet unter anderem die Marken Philips, Philips Hue, WiZ, Interact und Color Kinetics. Das Designbüro Hike One entwickelte das markenübergreifende „Photon”-System.

Das zentrale Architekturprinzip, das Hike One beschreibt: Der erste Token-Layer kapselt Markenentscheidungen (welche Farben, welche Schriften gehören zu dieser Marke). Der zweite Layer legt fest, wo und wie diese Entscheidungen angewendet werden — unabhängig davon, welche Marke aktiv ist. Alle Komponenten werden aus einem einzigen markenagnostischen Kern gebaut. Das System ist so konzipiert, dass es beliebige zukünftige Marken aufnehmen kann, ohne die Komponentenbibliothek anzufassen.

Das Ergebnis: Jede neue Marke erfordert ausschließlich eine neue Brand-Token-Datei. Design- und Entwicklungskosten pro Marke sinken erheblich, weil der Komponentencode nicht repliziert wird.

Praxisbeispiel: Telefónica / Mística

Telefónica betreibt das vollständig Open-Source-Design-System „Mística” für 16 Märkte und die Marken Movistar, O2, Vivo und Telefónica Corporate. Die Architektur exportiert pro Marke eine separate JSON-Datei mit den relevanten Token-Werten. Ein automatisierter Pipeline via GitHub Actions erstellt bei jedem Token-Update Pull Requests in die drei Plattform-Repositories — Web, Android, iOS — gleichzeitig.

Was früher bei Farbänderungen laut Telefónicas eigenem Bericht ein erheblicher Aufwand war, ist heute ein reproduzierbarer Pipeline-Schritt.

Das W3C-Format als strukturelle Grundlage

Die W3C Design Tokens Specification 2025.10 kodifiziert die oben beschriebene Architektur in einem formalen, werkzeugübergreifenden Format. Die für Multi-Brand-Systeme relevanten Teile:

$type-Kaskadierung auf Gruppenebene: Statt jedem Token einzeln "$type": "color" zuzuweisen, kann der Typ auf der Gruppe gesetzt werden und kaskadiert auf alle Kinder. Das reduziert Redundanz in großen Paletten erheblich.

{
  "brand": {
    "$type": "color",
    "primary": { "$value": "#0057FF" },
    "secondary": { "$value": "#FF5700" },
    "neutral": { "$value": "#6B7280" }
  }
}

$extends für Marken-Vererbung: Seit 2025.10 offiziell Teil der Spezifikation. Eine Marken-Datei erbt alle Tokens einer Basis-Gruppe und überschreibt nur die abweichenden Werte. Tools müssen die Merge-Semantik korrekt implementieren — ein Kompatibilitätsmerkmal, das beim Tooling-Wechsel entscheidend ist.

$extensions für Governance-Metadaten: Werkzeug-spezifische Erweiterungen wie Figma-Scoping, Accessibility-Annotationen oder interne Freigabe-Status können in $extensions abgelegt werden, ohne das Basisformat zu beschmutzen. Tools müssen Extensions, die sie nicht kennen, unverändert erhalten — das garantiert verlustfreien Datei-Transfer zwischen Werkzeugen.

Themes als gestalterisches Kontrollinstrument

Ein häufiges Missverständnis: Theme-Switching wird als Accessibility-Notlösung eingesetzt — ein Button für „hoher Kontrast”, ein Toggle für Dark Mode, beides wirkt wie ein nachträglicher Einbau und kompromittiert das Corporate Design.

Das ist das falsche Modell. Korrekt implementiert sind Themes ein gestalterisches Präzisionsinstrument. Jedes Theme ist eine vollständige, intentional gestaltete Ausführung des Systems — nicht eine degradierte Version davon.

/* Standard-Theme: designerisch vollwertig */
[data-theme="default"] {
  --color-interactive: #0057FF;
  --color-surface-base: #F8F9FA;
}

/* Kontrast-Theme: eigene Designentscheidungen, keine Kompromisse */
[data-theme="high-contrast"] {
  --color-interactive: #003080;
  --color-surface-base: #FFFFFF;
  --color-text-primary: #000000;
  --border-width-interactive: 2px;
}

/* Dark Mode: ebenfalls vollständig gestaltet */
[data-theme="dark"] {
  --color-interactive: #60A5FA;
  --color-surface-base: #0F172A;
  --color-surface-elevated: #1E293B;
}

Der Unterschied zur schlechten Implementierung liegt darin, dass das Kontrast-Theme nicht automatisch generiert wird (z. B. durch einfaches Abdunkeln aller Farben), sondern für jedes Theme eigene Designentscheidungen getroffen werden. Schriftgrößen, Abstände, Border-Stärken — all das kann theme-spezifisch justiert werden. Das Ergebnis ist ein System, das Barrierefreiheit und Designqualität nicht als Gegensätze behandelt, sondern als parallele Anforderungen mit getrennten Token-Sätzen löst.

Style Dictionary ist das meistgenutzte Werkzeug für die Code-seitige Transformation. Das Multi-Brand-Muster nutzt zwei Konfigurationsebenen: Geteilte Basis-Tokens in include, markenspezifische Overrides in source. Der Deep-Merge-Mechanismus stellt sicher, dass nur die tatsächlich abweichenden Tokens überschrieben werden.

// style-dictionary.config.js für Marke B
export default {
  include: ['tokens/primitives/**/*.json', 'tokens/semantic/**/*.json'],
  source: ['tokens/brands/marke-b/**/*.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      buildPath: 'dist/marke-b/',
      files: [{ destination: 'variables.css', format: 'css/variables' }]
    }
  }
}

Tokens Studio implementiert dasselbe Prinzip durch Token-Sets und Theme-Groups. Token-Sets können als Enabled, Disabled oder Source/Reference-Only markiert werden; die Position in der Liste bestimmt die Kaskadierung. Kombinierte Theme-Groups ermöglichen eine Matrix aus Marke × Color-Mode × Breakpoint ohne manuelle Datei-Multiplikation.

Namenskonventionen für Multi-Brand-Systeme

Die Namensgebung entscheidet darüber, ob das System skaliert oder unter eigenem Gewicht kollabiert. Einige Leitlinien:

Semantische Tokens beschreiben Verwendung, nicht Aussehen. --color-interactive statt --color-blue. Sobald eine Marke Interaktion in Rot darstellt, ist ein farbbeschreibender Name falsch.

Marken-Tokens tragen den Markennamen im Namespace. brand-a.color.primary statt color.primary für markenspezifische Primitive. Das verhindert Kollisionen und macht die Herkunft eines Tokens in jedem Kontext erkennbar.

Komponenten-Tokens tragen den Komponentennamen. button.primary.background, nicht interactive-element-background. Die Granularität richtet sich nach der tatsächlichen Variationsbreite — nicht nach dem was theoretisch konfigurierbar sein könnte.

Deprecation konsequent nutzen. Die W3C-Spezifikation unterstützt $deprecated auf Token-Ebene. Bei Marken-Migrationen sollten alte Token-Namen mindestens einen Release-Zyklus lang als deprecated erhalten bleiben.

Entscheidungsbaum: Wann lohnt sich die vollständige Vier-Schichten-Architektur?

Die vollständige Architektur ist kein Selbstzweck. Sie lohnt sich, wenn mindestens eine der folgenden Bedingungen zutrifft:

Mehrere Marken aus einer Bibliothek. Zwei und mehr Marken mit eigenem Visual Identity sind der Kernfall. Ab drei Marken ist die Architektur nahezu zwingend.

Geplante Marken-Evolution. Rebrands, Akquisitionen, Spin-offs — wenn bekannt ist, dass das Markenportfolio wächst, ist vorausschauendes Schichten-Design billiger als nachträgliche Migration.

White-Label-Produkt. Wenn Kunden das System mit eigener Marke betreiben, ist die Token-Schicht gleichzeitig die Kundenschnittstelle. Sie muss klar, vollständig und gut dokumentiert sein.

Mehrere Themes pro Marke. Dark Mode, High Contrast, saisonale Kampagnen-Themes — sobald mehr als ein Theme pro Marke existiert, ist die Schichtenarchitektur die einzige wartbare Lösung.

Für ein System mit einer einzigen Marke und einem einzigen Theme ist das vollständige Modell oft Overengineering. In diesem Fall reicht eine Zwei-Schichten-Struktur (Primitives + Semantik) vollständig aus.

Weiterführende Ressourcen

• W3C Design Tokens Community Group: designtokens.org
• W3C DTCG Spezifikation 2025.10: designtokens.org/tr/2025.10
• Brad Frost: The Many Faces of Themeable Design Systems
• Brad Frost: The Multi-All-The-Things Organization
• Hike One / Signify: A multi-branded design system leveraging design tokens
• kickstartDS: kickstartDS is a White-Label Design System
• Style Dictionary: styledictionary.com