Von Figma Color Styles zu echten Tokens

Figma Color Styles und Variablen lösen unterschiedliche Probleme. Ein Style ist ein benannter Paint — eine Fill-Definition, die eine Volltonfarbe, einen Verlauf oder ein Bild enthalten kann. Eine Variable ist ein benannter Wert mit Modes: eine Variable kann einen hellen und einen dunklen Wert halten, und wenn du den Mode eines Frames umschaltest, wechselt jeder daran gebundene Fill mit. Eine Figma-Palette in echte Tokens zu verwandeln heißt, ihre Volltonfarben in Variablen zu überführen — geschichtet als primitive Collection (die rohen Rampenstufen) und semantische Collection (Rollen wie text/primary, die darauf verweisen) — dieselbe zweischichtige Struktur, die design tokens im Code haben.

Der Abstand zwischen diesen beiden Features ist der Punkt, an dem viele “unser Design-System lebt in Figma”-Setups stillschweigend hängenbleiben: eine Wand aus gut benannten Color Styles, die keinen Dark Mode ausdrücken können und die Code nur von Hand nachbauen kann. Dieser Artikel behandelt die Trennung, das geschichtete Setup und den Workflow von der generierten Rampe zum gebundenen Fill; die Rampen selbst sind Thema unseres Leitfadens zu Farbskalen.

Was ist der Unterschied zwischen Color Styles und Variablen?

Styles sind das ältere Feature: benannte Paints, die du auf Fills und Strokes anwendest. Sie sind nach wie vor der einzige Ort für Verläufe und Bild-Fills, und für Teams, die nur konsistente Benennung brauchen, funktionieren sie. Was ein Style nicht kann, ist mehr als einen Wert zu halten — ein Style namens background ist ein einziger Paint, für immer, unabhängig vom Theme.

Variablen sind benannte Werte, die in Collections organisiert sind, und jede Collection kann Modes definieren — parallele Wertesätze für dieselben Namen. Variablen können sich außerdem gegenseitig referenzieren (Aliase) und binden an Fills, Strokes und Effekte.

Für Farbe sind Modes das entscheidende Feature. Definiere eine background-Variable mit einem hellen und einem dunklen Wert, binde sie an den Fill eines Frames, und das dunkle Theme ist keine parallele Datei mehr, die du pflegen musst: Frame auswählen, Mode umschalten, und jeder gebundene Fill darauf wechselt auf einen Schlag. Ein style-basiertes dunkles Theme ist dagegen ein zweiter Satz Styles, von Hand angewendet — ein Redesign, das für jeden Screen erneut durchgeführt werden muss.

Wie sollten Farbvariablen geschichtet werden?

In zwei Collections, die die Token-Ebenen im Code spiegeln.

Die primitive Collection hält das Rohmaterial: die Rampenstufen. brand/50 bis brand/900, dasselbe für die Skala der Neutraltöne und die Funktionsfarben — Namen, die beschreiben, was eine Farbe ist. Primitive brauchen meist keine Modes; eine Rampenstufe ist in jedem Theme derselbe Wert.

Die semantische Collection hält die Rollen: background, surface, text/primary, border/default, fill/brand — Namen, die beschreiben, wofür eine Farbe da ist. Jede semantische Variable ist ein Alias in die primitive Collection, und dies ist die Ebene, die die Modes trägt: im Light Mode verweist background auf eine Stufe nahe Weiß, im Dark Mode auf eine nahe Schwarz. Der Name der Rolle bleibt an Ort und Stelle, während ihr Wert wandert.

Der Gewinn dieser Indirektion ist derselbe, den Tokens im Code bringen: Designer arbeiten im Vokabular der Rollen, die Rampe kann neu generiert werden, ohne dass etwas umbenannt werden muss, und Dark Mode ist ein Umbiegen von Aliassen statt neuer Entscheidungen pro Screen.

Wie sieht der Workflow von Anfang bis Ende aus?

Erst generieren, dann binden.

Die Rampen entstehen aus einer einzigen Ausgangsfarbe. Gib Scale Composer eine Markenfarbe — #2563eb, also oklch(0.546 0.215 262.9) — und es generiert die zehnstufige Rampe, die getönte Skala der Neutraltöne und die Funktionsfarben nativ in OKLCH, dann leitet es die semantischen Rollen pro Surface ab, mit geprüften WCAG-Kontrastuntergrenzen und daneben ausgewiesenem APCA. Der Figma-Variables-Export trägt diese Struktur nach außen — Primitive, semantische Aliase, hex-Werte daneben — sodass die oben beschriebenen Collections fertig gebaut ankommen statt von Hand zusammengesetzt.

Öffne den Figma-Variables-Export der Palette in Scale Composer — die Rampenstufen als primitive Collection, die Rollen als Alias darüber, bereit zum Import.

Von da an ist der Vertrag des Designers kurz: binde semantische Variablen an Fills, niemals rohe Stufen — der Hintergrund der Card ist surface/tint, nicht brand/50, auch wenn beide heute denselben Wert ergeben. Rohe Stufen dienen dem Bauen von Rollen, nicht dem Anfassen von Screens.

Dark Mode kommt dann als Daten. Scale Composer leitet die dunkle Palette ab, statt die helle zu spiegeln — mit einer eigenen Helligkeitskurve, das Chroma um rund 20 % angehoben, weil dunkle Umgebungen die wahrgenommene Farbigkeit dämpfen — und diese Werte werden zum zweiten Mode der semantischen Collection. Kein Screen wird neu gestaltet; die Frames lösen sich neu auf.

Was bringt Bindungsdisziplin eigentlich?

Hier ist dieselbe Promo-Card zweimal gebaut. Auf dem Bildschirm sind beide heute bis aufs Pixel identisch:

Beachte: Der hartcodierte Build enthält keine Fehler — jeder hex ist der korrekte aktuelle Wert. Der Unterschied zeigt sich erst, wenn sich die Palette verändert — also genau dann, wenn am wenigsten Zeit bleibt, es zu reparieren.

Beim Rebranding ändert sich die Ausgangsfarbe und die Primitive leiten sich neu ab: Die gebundene Card aktualisiert sich überall dort, wo sie instanziiert ist, während bei der hartcodierten Card fünf Werte aufgespürt und neu getippt werden müssen — multipliziert mit jedem Screen, der sie kopiert hat. Beim Dark Mode wechselt die gebundene Card mit dem Mode des Frames; die hartcodierte Card reagiert überhaupt nicht, also baut jemand ein card-dark-Duplikat, und von diesem Tag an driften die beiden unabhängig voneinander. Die gebundene Spalte kostet ein bisschen Disziplin pro Fill; die hartcodierte Spalte kostet eine Migration pro Änderung.

Was können Variablen nicht für dich leisten?

Zwei ehrliche Grenzen. Erstens halten Farbvariablen Volltonwerte: Verläufe und Bild-Fills leben nach wie vor in Styles, also betreibt eine echte Datei beide Features nebeneinander — Variablen für die token-förmigen Farben, Styles für den malerischen Rest.

Zweitens ist Bindungsdisziplin menschlich. Figma hält niemanden davon ab, einen hex in einen Fill zu tippen, und ein getippter hex umgeht die gesamte Kette stillschweigend — er passt perfekt, bis zum ersten Rebranding oder Mode-Wechsel, und taucht dann als eine veraltete Card in einem aktualisierten Interface auf. Kein Tool-Setup ersetzt die Team-Gewohnheit, bei jedem Fill zu fragen: Welche Rolle ist das? Die Schichtung macht die richtige Wahl billig; sie kann die falsche nicht unmöglich machen.

Der Mode-Mechanik vertraut man leichter, wenn man einmal gesehen hat, wie Werte wandern. Exportiere dieselbe Palette mit Light und Dark Mode nebeneinander — die semantischen Rollen behalten ihre Namen, während beide Wertesätze darunter liegen, die dunklen abgeleitet statt invertiert.