Token-Engineering

Das kann keine KI

Ein Hex-Wert in einer CSS-Datei ist keine Quelle. Tokens sind Verträge — zwischen Marke und Produkt, zwischen Design und Code, zwischen Mensch und KI. Sie brauchen eine Spec, einen Build, ein Release-Modell. Wir behandeln sie wie das, was sie sind: Infrastruktur.

Arbeitspakete

Spec

DTCG-konformes Tokenmodell mit klarer Naming-Konvention, Tier-Struktur (Primitive → Semantic → Component) und expliziten Aliasen. Was gilt, wird einmal entschieden.

Build

Eine Pipeline aus einer Source: CSS-Variablen, JS-Konstanten, iOS/Android-Resources, Figma-Variables. Format folgt Plattform, nicht andersherum.

Release

SemVer, Changelogs, Breaking-Change-Policy. Tokens werden wie eine API behandelt — mit Deprecation-Pfaden statt stillschweigendem Umbenennen.

Migration

Bestandscode auf die neue Token-Schicht heben, Linting einführen, harte Werte verbieten. Refactoring in messbaren Stufen, nicht als Big-Bang.

Fragen

Fragen, die Token-Engineering beantwortet.

  • Single Source

    Liegen Ihre Tokens an genau einer Stelle — oder gibt es Schatten-Definitionen in Figma, CSS und Brand-Manual?

  • Build-Pipeline

    Werden Tokens automatisch in CSS, JS, iOS und Android exportiert — oder kopiert jemand Hex-Werte?

  • Naming

    Folgen Ihre Tokens einer dokumentierten Konvention oder historischem Zufall?

  • Versionierung

    Können Sie sagen, welche Token-Version in welcher App und welchem Brand-Theme produktiv läuft?

  • Breaking Changes

    Wie kommunizieren Sie Token-Änderungen an Downstream-Teams — Changelog, Slack, Hoffnung?

  • Tier-Trennung

    Trennen Sie semantische Tokens sauber von primitiven Werten — oder hardcoded jemand `#FF0000` direkt?

Reden wir über
Ihre Token-Schicht.

Kontakt aufnehmen