Eine Organisation investiert Hunderttausende in die Definition ihrer Design-Entscheidungen: Markenfarben, Typografie-Regeln, Spacing-Systeme, Komponentenvarianten. Diese Entscheidungen sind digitales Kapital. Doch in der Praxis sind sie oft in proprietären Formaten gefangen – in Figma-Dateien, in einem Sketch-Library, in einem SCSS-Monolithen, der an ein spezifisches Framework gebunden ist.

Das Problem proprietärer Token-Formate

Figma speichert Styles und Variables in einem proprietären Format, das nur über die Figma-API zugänglich ist. Wer seine komplette Design-Dokumentation in Figma hat und morgen zu Penpot wechseln will, muss alles manuell migrieren – oder ein teures Migrationstool beauftragen. Die Design-Entscheidungen gehören faktisch dem Tool-Anbieter, nicht der Organisation.

Das gleiche Problem existiert auf der Code-Seite: SCSS-Variablen sind an den SCSS-Compiler gebunden, Tailwind-Konfigurationen an das Tailwind-Framework, Styled-Components-Themes an React. Wer das Framework wechselt, verliert seine Token-Definitionen.

Souveräne Tokens: Der Ansatz

Souveräne Tokens lösen dieses Problem durch drei Prinzipien:

Offenes Format: Tokens werden im W3C DTCG-Format gespeichert – einem standardisierten JSON-Format, das jedes Build-Tool lesen kann. Kein proprietäres Format, kein Vendor Lock-in.

Single Source of Truth: Die JSON-Token-Dateien im Git-Repository sind die kanonische Quelle. Figma, Code und Dokumentation werden aus dieser Quelle gespeist – nicht umgekehrt. Das Repository gehört der Organisation, nicht einem SaaS-Anbieter.

Multi-Output Build: Eine Build-Pipeline (Style Dictionary, Cobalt UI) generiert aus den Token-Dateien alle benötigten Ausgabeformate: CSS Custom Properties, SCSS, TypeScript-Konstanten, iOS Swift, Android XML, Figma Variables. Ein Input, viele Outputs.

Token-Portabilität in der Praxis

Ein konkretes Szenario: Eine Organisation hat ein Design-System mit 500 Tokens (Farben, Typografie, Spacing, Schatten, Border-Radien). Die Tokens sind im DTCG-Format dokumentiert und im Git-Repository versioniert.

Szenario 1 – Figma → Penpot: Die JSON-Token-Dateien bleiben identisch. Penpot Import-Tooling liest das DTCG-Format. Migration der Tokens: Stunden, nicht Wochen.

Szenario 2 – React → Svelte: Die CSS Custom Properties bleiben identisch. Nur die Headless-Komponentenbasis wird getauscht. Token-Migration: Null Aufwand.

Szenario 3 – Rebranding: Semantic Token-Werte werden aktualisiert. Die Build-Pipeline generiert neues CSS. Alle Produkte aktualisieren sich automatisch. Migration: Ein Commit.

Was „souverän" konkret bedeutet

Dimension
Nicht-souverän
Souverän
Speicherort
Figma Cloud (US)
Git-Repository (eigene Infra)
Format
Proprietary (Figma/Sketch)
W3C DTCG (offener Standard)
Build-Pipeline
SaaS (Specify, Supernova)
Open Source (Style Dictionary)
Output
Ein Framework
Multi-Platform (CSS, iOS, Android)
Portabilität
Tool-gebunden
Tool-unabhängig
Versionierung
Tool-eigene History
Git (vollständig, dauerhaft)

Kernpunkte

  • Design-Entscheidungen sind digitales Kapital – sie sollten nicht in proprietären Formaten gefangen sein.
  • Souveräne Tokens basieren auf drei Prinzipien: offenes Format (W3C DTCG), Single Source of Truth (Git), Multi-Output Build (Style Dictionary/Cobalt UI).
  • Token-Portabilität macht Tool-Wechsel (Figma → Penpot), Framework-Wechsel (React → Svelte) und Rebranding zu operativen statt strategischen Aufgaben.
  • Die Build-Pipeline sollte auf Open-Source-Tools basieren – kein SaaS als kritischer Pfad.
  • Git als Speicherort garantiert Versionierung, Nachvollziehbarkeit und Eigentumsrecht.
  • Wer seine Tokens heute im W3C-Format hat, investiert in langfristige Unabhängigkeit.