Eine Quelle der Wahrheit: Der Token-Workflow

Design Tokens geben einem Produkt eine einzige Quelle der Wahrheit, wenn eine kanonische Tokens-Datei der Ort ist, an dem jede Design-Entscheidung lebt, und jeder Konsument — Stylesheets, Utility-Theme, Design-Tool-Variablen — daraus generiert wird. Das aufrechtzuerhalten ist ein Kreislauf aus fünf Schritten: im Design-Tool entscheiden, die kanonische Datei plus ihre Konsumenten-Formate exportieren, sie committen, damit der Pull Request zum Review-Tor wird, die generierten Formate in Code- und Design-Dateien konsumieren und jede spätere Änderung zurück durch Schritt eins leiten.

Der Begriff single source of truth stammt aus dem Design von Informationssystemen: Speichere jeden Fakt genau einmal und leite jedes weitere Auftreten davon ab, sodass die Übereinstimmung zwischen Kopien durch Struktur statt durch Sorgfalt gewahrt bleibt. Dieser Artikel überträgt dieses Prinzip auf den täglichen Token-Workflow — den Kreislauf, den Fehler, den jeder Schritt verhindert, wer was verantwortet, und eine Änderung von Anfang bis Ende verfolgt. Es ist das Workflow-Kapitel unseres Design-Tokens-Leitfadens.

Was sind die fünf Schritte des Token-Workflows?

1. Entscheiden — im Design-Tool. Skalen-Parameter, Ausgangsfarben, semantische Rollen: Scale Composer ist die Oberfläche, auf der diese Entscheidungen getroffen werden und ihre Konsequenzen sichtbar sind — eine geänderte Ausgangsfarbe leitet die Farbrampen und die Rollen für beide Themes neu ab, während du zusiehst.
2. Exportieren — die kanonische DTCG-Datei plus die daraus generierten Konsumenten-Formate: CSS Custom Properties, ein Tailwind-v4-@theme-Block, Figma Variables mit Hex daneben. Ein Satz von Entscheidungen, mehrere Ausgaben.
3. Committen — die Tokens-Datei landet im Repository, und der Pull Request wird zum Design-Review: Historie, Begründung in Commit-Nachrichten, Rückgängig-Machbarkeit.
4. Konsumieren — Code referenziert die Custom Properties oder das Theme; Designer binden die Figma-Variablen. Niemand tippt auf einer der beiden Seiten einen rohen Wert.
5. Ändern — die nächste Bearbeitung beginnt wieder bei Schritt eins: Das Tool importiert seine eigene Datei erneut, die Anpassung wird gegen die aktuelle Wahrheit vorgenommen, und der Kreislauf wiederholt sich. Round-Trip-Erhaltung macht das sicher — Abschnitte, die das Tool nicht generiert, überstehen den erneuten Import unberührt, eine getestete Eigenschaft statt einer Hoffnung.

Auf einem Whiteboard gezeichnet ist der Workflow ein Kreis, keine Pipeline — und der Kreis ist der springende Punkt. Eine Pipeline endet, und was auch immer an ihrem Ende steht, beginnt, händische Änderungen anzusammeln.

Welchen Fehler verhindert jeder Schritt?

Überspringe einen Schritt, und an seiner Stelle taucht ein spezifischer, vorhersehbarer Fehler auf:

• Export überspringen und stattdessen von Hand kopieren. Werte, die in CSS oder Figma abgetippt werden, sind vom Moment ihres Auftauchens an zweite Quellen. Drift — die Design-Datei und der Build sind sich über Werte uneinig, die identisch sein sollten — ist die Krankheit, gegen die Tokens existieren, und das Kopieren von Hand führt sie zur ersten Deadline wieder ein.
• Commit überspringen. Die Datei lebt im Tool-Zustand oder auf einem einzigen Laptop: kein Review, keine Historie, kein Zurücksetzen, und „Welche Version ist die echte?” kehrt als Frage mit mehreren Antworten zurück.
• Den Änderungs-Kreislauf überspringen. Bearbeitungen passieren stattdessen weiter unten — jemand patcht das generierte CSS direkt. Jetzt ist die kanonische Datei Fiktion: Der nächste ehrliche Export überschreibt den Patch stillschweigend, also hören die Leute auf zu exportieren, und die Quelle der Wahrheit wird write-only, dann aufgegeben. Die Re-Import-Disziplin ist das, was den Kreislauf geschlossen hält — weil das Tool seine eigene Datei zurückliest, ist der Weg hindurch nie langsamer als der Weg drumherum.

Das Konsumieren hat einen eigenen, leiseren Fehler — exportierte Werte zu referenzieren, indem man sie kopiert statt sie beim Namen zu nennen — aber das ist eine Frage der Bindungs-Disziplin an der Aufrufstelle, kein kaputter Kreislauf.

Die intuitive Zusammenfassung: Eine einzige Quelle der Wahrheit ist nichts, was ein Team einmal einrichtet — sie ist eine Eigenschaft, die jede danach vorgenommene Änderung überleben muss, und jeder der obigen Fehler ist dasselbe Ereignis: eine zweite Quelle, die dort sprießt, wo ein Schritt übersprungen wurde. Der Kreislauf ist so gestaltet, dass bei jedem Schritt die billigste Aktion zugleich die richtige ist: Neu-Generieren schlägt Neu-Tippen, Committen schlägt das Verschicken einer Datei per E-Mail, Re-Import schlägt Neu-Entscheiden. Workflows halten, wenn der bequeme Weg und der richtige Weg derselbe Weg sind.

Sieh in Scale Composer, wie eine Quelle jeden Konsumenten speist — die Abschnitte der kanonischen Datei auf der einen Seite und dieselben Namen daneben, gerendert als CSS-, Tailwind- und Figma-Exporte.

Wer verantwortet welchen Schritt?

Der Kreislauf verteilt sich sauber über die Rollen. Der Designer verantwortet das Entscheiden — dort leben die Ermessensfragen. Exportieren und Committen sind der Handschlag, bei dem eine private Entscheidung zu geteiltem, überprüfbarem Eigentum wird. Entwickler verantworten das Konsumieren im Code; Designer verantworten es in der Design-Datei. Das Ändern gehört demjenigen, dessen Bedarf es ausgelöst hat — geleitet durch dasselbe Tor wie das aller anderen.

Ein nützliches Denkmodell — und es ist ein Denkmodell, keine technische Tatsache: Die Tokens-Datei ist die API zwischen Design und Entwicklung, und sie belohnt dieselben Disziplinen, die eine API erhält. Versioniert, durch Commits. Überprüft, durch Pull Requests. Dokumentiert, durch $description-Felder, die mit den Tokens mitreisen. Mit einer Übergangsfrist abgekündigt statt über Nacht kaputtgemacht. Das Denkmodell sagt auch die Soziologie voraus: Meinungsverschiedenheiten über einen Wert sind keine Revierkämpfe mehr zwischen Design und Entwicklung („die Datei sagt 22, der Build sagt 20”) und werden zu einem Änderungsvorschlag gegen ein Artefakt, das beide Seiten lesen.

In einem Zwei-Personen-Team — oder einem Ein-Personen-Team — ist der Kreislauf derselbe, nur mit weniger Übergaben. Was die Schritte dort einbringen, ist nicht Koordination, sondern Gedächtnis: Die Commit-Historie ist das Design-Protokoll.

Wie zieht man einen Token aus dem Verkehr, ohne Konsumenten zu brechen?

Mit einem Übergang, genau wie es eine API täte. Einen Token umzubenennen oder zu entfernen ist eine Breaking Change für jeden Konsumenten des alten Namens, also verweist der alte Name für einen Release als Alias auf den neuen — "accent-strong": { "$value": "{semantic.accent}" } lässt veraltete Referenzen weiter auflösen, während die Änderung angekündigt wird — und die Entfernung geschieht, nachdem die Konsumenten migriert sind, verifiziert durch die Suche nach dem alten Namen statt durch Hoffen. Ein glattes Löschen bedeutet, dass der Bruch beim nächsten Build entdeckt wird, wenn du Glück hast, und in ausgelieferten Visuals, wenn nicht.

Wie sieht eine Änderung durch den Kreislauf hindurch aus?

Verfolge eine echte: Die Marke wählt für ihren Akzent eine neue Ausgangsfarbe — von Blau, #2563eb, also oklch(0.546 0.215 262.9), hin zu einem tieferen Indigo.

1. Entscheiden. Der Designer lädt die design-tokens.json des Projekts in Scale Composer — die committete Datei, keine veraltete Kopie — und ersetzt die Marken-Ausgangsfarbe. Die Farbrampe leitet sich rund um den neuen Farbton neu ab; die semantischen Rollen zeigen weiter auf dieselben Stufen; Light und Dark leiten sich beide aus der einen Entscheidung neu ab.
2. Exportieren. Die kanonische Datei plus die CSS-, Tailwind- und Figma-Formate. Geändert: Farbrampen-Werte und Rollen-Auflösungen. Unverändert: Namen, Typografie, Abstände — alles, was die Änderung nicht berührt hat, kommt durch den Round-Trip unversehrt hindurch.
3. Committen. Im PR steht „Akzent-Ausgangsfarbe auf Indigo neu setzen — Q4-Marken-Refresh”. Der Reviewer sieht ein Diff, das nur Werte betrifft, bestätigt, dass die On-Accent-Paarungen ihre Kontrast-Untergrenzen weiterhin erreichen, stellt die Frage nach der Reichweite der Auswirkungen und genehmigt. Die Commit-Nachricht ist der Eintrag im Design-Protokoll.
4. Konsumieren. Beim Merge löst --accent überall dort, wo es referenziert wird, zum neuen Wert auf — keine Änderungen am Komponenten-Code. Die Design-Datei aktualisiert ihre Variablen aus dem neuen Export, und gebundene Screens lösen sich ohne Redesign neu auf.
5. Ändern. Zwei Wochen später braucht die Hover-Stufe einen Anstupser. Die Bearbeitung beginnt damit, dieselbe Datei zu laden — die immer noch mit dem übereinstimmt, was ausgeliefert wurde, weil nichts den Kreislauf umgangen hat.

Was jede Rolle gesehen hat: Der Designer nahm eine Bearbeitung vor, der Reviewer las ein lesbares Diff, der Entwickler lieferte null Code-Änderungen aus, und das Produkt verschob sich in einem koordinierten Zug. Entscheidungs-große Arbeit für eine entscheidungs-große Änderung — dafür ist der Kreislauf da.

Durchlaufe den Kreislauf einmal selbst

Am überzeugendsten ist der Kreislauf bei Schritt fünf, wenn das Tool dir deine eigenen Entscheidungen unversehrt zurückgibt. Ändere eine Ausgangsfarbe und sieh zu, wie sie sich fortpflanzt — jeder Export rendert aus derselben Quelle neu, und die Abschnitte, die deine Änderung nicht berührt hat, kommen genau so zurück, wie sie hineingingen.