Ein Design-System ist nicht das Figma-Dokument. Es ist die Datei tokens.css im Repo. Alles andere ist Dokumentation darüber, was im Code wirklich passiert.

Wir haben in drei aktuellen Projekten denselben Aufbau: Ein Token-File als Single Source of Truth, ein dünner Komponenten-Layer, und Figma als Spiegel davon, nicht als Quelle. Klingt verkehrt herum — funktioniert aber besser.

Tokens sind Code, nicht Tabellen

Klassische Design-Systeme leben in Spec-Dokumenten oder Figma-Variablen. Das ist nett für Designer. Für Entwickler ist es eine zweite Wahrheit, die regelmäßig auseinanderläuft. Wir gehen den umgekehrten Weg: Tokens werden direkt in CSS oder Swift definiert, mit Kommentaren für Designer.

tokens.css
/* ── Color: Brand ── */
--cc-midnight: #00004F;        /* Primary */
--cc-highlight: #E84A0A;       /* Accent */
--cc-link: #039DC6;            /* Cyan */

/* ── Type ── */
--font-display: "Sora", system-ui;
--font-mono: "JetBrains Mono", monospace;

Die Datei ist 122 Zeilen lang. Sie ist im Repo. Sie wird mitversioniert. Designer können sie lesen — wir machen einmal pro Projekt einen kurzen Crashkurs in CSS-Variablen, und damit ist die Sprachbarriere weg.

Warum Figma trotzdem im System bleibt

Figma ist kein Design-System. Aber es ist ein hervorragender Spielplatz, um Komponenten visuell zu durchdenken, bevor sie in Code wandern. Bei uns ist Figma der Ort, an dem ein neues Komponenten-Layout entsteht, und tokens.css der Ort, an dem es real wird. Dass Design und Engineering bei uns am selben Tisch sitzen, ist kein Zufall — so arbeitet unser Studio in jedem Projekt.

  • Designer entwerfen in Figma, mit den importierten Tokens als Variablen.
  • Sobald die Form steht, schreibt ein Engineer (oder der Designer selbst) das HTML/CSS direkt im Repo.
  • Figma wird im Hintergrund über ein Plugin synchronisiert — Tokens fließen aus dem Code zurück.
  • Wenn es einen Konflikt gibt: Code gewinnt. Immer.
// Ende des Artikels