Design Tokens vs. Design Systems: Der Unterschied erklärt

Ein Hex-Code ist noch kein Design Token. Und ein Ordner voller Tokens ist noch kein Design System. Der Unterschied klingt nach Wortklauberei, entscheidet in der Praxis aber darüber, ob ein Produkt konsistent bleibt oder mit jedem Sprint ein Stück mehr auseinanderdriftet.

Der Anlass für diesen Artikel war unspektakulär. Ich habe in einem laufenden Projekt drei verschiedene Grüntöne für „Erfolg" gezählt. Einmal im Button, einmal in der Notification, einmal in einem Badge, das offenbar direkt aus einem alten Mockup kopiert wurde. Niemand hatte das böswillig gemacht. Es gab einfach keine einzige Stelle, an der festgelegt war, welches Grün „Erfolg" im Produkt eigentlich bedeutet.

Genau an diesem Punkt setzen Design Tokens an. Und genau an diesem Punkt hören sie auch wieder auf. Denn ein Token allein macht noch kein System, so wie ein einzelnes Wort noch keine Sprache ist.

Was ein Design Token eigentlich ist

Ein Design Token ist ein benannter Wert für eine gestalterische Entscheidung. Statt einen Rohwert wie #2ECC71 an zwanzig Stellen im Code zu verstreuen, legt man ihn einmal fest, gibt ihm einen Namen und referenziert nur noch diesen Namen.

Typische Kategorien von Tokens:

• Farben (Text, Hintergrund, Rahmen, Status)
• Abstände (Padding, Margin, Gaps im Grid)
• Typografie (Schriftgröße, Zeilenhöhe, Schriftschnitt)
• Radius (Eckenradius von Buttons, Cards, Inputs)
• Schatten (Elevation-Stufen)
• Timing (Dauer und Easing von Animationen)

Der eigentliche Wert eines Tokens ist nicht der Wert selbst, sondern dass er an genau einer Stelle geändert werden kann und sich die Änderung überall durchzieht, wo der Token verwendet wird.

Drei Ebenen, die die meisten Diskussionen durcheinanderbringen

Die häufigste Verwirrung bei Tokens entsteht, weil Menschen von unterschiedlichen Abstraktionsebenen sprechen, ohne das zu merken. In der Praxis lohnt sich eine klare Trennung in drei Ebenen:

Der Trick liegt darin, dass Komponenten sich immer auf semantische Tokens beziehen sollten, nie direkt auf Primitives. Wenn badge-success-background direkt auf green-600 zeigt, muss bei jedem Rebranding jede einzelne Komponente angefasst werden. Zeigt sie stattdessen auf color-success, reicht eine Änderung an genau einer Stelle, und Button, Badge und Notification übernehmen die neue Farbe automatisch.

Diese Zwischenebene ist es auch, die einen Dark Mode überhaupt praktikabel macht: color-success bleibt als Name bestehen, nur die dahinterliegende Primitive wechselt je nach Modus.

Der eigentliche Unterschied: Vokabular vs. Sprache

Hier liegt der Kern der Verwechslung, um die es in diesem Artikel eigentlich geht.

Design Tokens sind das Vokabular. Einzelne, benannte Werte, atomar und ohne Kontext, wie das Produkt sie tatsächlich zusammensetzt.

Ein Design System ist die Sprache, die aus diesem Vokabular gebaut wird: Komponenten, Muster, Richtlinien, Dokumentation und ein Prozess, der festlegt, wann ein neuer Token entsteht, wann eine Komponente ins System aufgenommen wird und wer das entscheidet.

Man kann Tokens haben, ohne ein ausgereiftes Design System zu besitzen. Das ist sogar ein völlig normaler Zwischenschritt: ein junges Produkt legt zuerst Farb- und Abstands-Tokens fest, bevor es sich eine vollständige Komponenten-Bibliothek mit Dokumentation und Review-Prozess leisten kann.

Umgekehrt funktioniert es kaum. Ein „Design System", das nur aus hübsch dokumentierten Komponenten besteht, deren Werte aber weiterhin einzeln in jeder Komponente hart codiert sind, ist im Kern kein System. Es ist eine Sammlung von Einzelfällen, die zufällig gerade ähnlich aussehen, bis die nächste Deadline dazwischenfunkt.

Ein Mini-Beispiel aus der Praxis

Angenommen, ein Produkt braucht einen Status für „Warnung", der in einem Badge, einem Toast und einem Button-Rand auftaucht. Mit Tokens sieht das in CSS ungefähr so aus:

:root {
  /* Primitive */
  --amber-500: #f59e0b;
  --amber-700: #b45309;
 
  /* Semantisch */
  --color-warning: var(--amber-500);
  --color-warning-emphasis: var(--amber-700);
}
 
.badge--warning {
  background-color: var(--color-warning);
}
 
.toast--warning {
  border-left: 4px solid var(--color-warning);
}
 
.button--warning:hover {
  background-color: var(--color-warning-emphasis);
}

Drei Komponenten, ein einziger Ort, an dem „Warnung" farblich definiert ist. Ändert sich die Marke oder kommt ein Dark Mode dazu, ändert sich --color-warning, nicht die Komponenten.

Das ist bereits ein funktionierendes Token-Setup. Ein Design System wird daraus erst, wenn zusätzlich dokumentiert ist, wann ein Element überhaupt „Warnung" statt „Fehler" oder „Hinweis" verwendet, wie sich Badge, Toast und Button in Abstand und Typografie zueinander verhalten, und wer entscheiden darf, wenn ein Team einen vierten Warnton haben möchte.

Warum das kein reines Frontend-Thema ist

Auseinanderdriftende Farben und Abstände wirken erstmal wie Kosmetik. In der Praxis sind sie fast immer ein Symptom für etwas, das ich an anderer Stelle schon als Tech Debt beschrieben habe: unsichtbar, bis sie plötzlich sehr sichtbar wird.

Jede zusätzliche Grün-Variante bedeutet konkret:

• Entwickler raten bei jeder neuen Komponente, welchen Wert sie diesmal nehmen sollen.
• Design-Reviews diskutieren Pixel-Details statt Nutzerfluss.
• Ein Rebranding wird zum Suchen-und-Ersetzen-Projekt statt zur Änderung an einer Stelle.
• Nutzer merken, ohne es benennen zu können, dass sich das Produkt uneinheitlich anfühlt.

Das ist genau der Punkt, an dem sich Design Tokens mit echter UX treffen. Ein Nutzer bewertet nie, ob ein Hex-Code sauber verwaltet ist. Er merkt nur, ob sich ein Produkt konsistent und vorhersehbar anfühlt oder nicht.

Wie du pragmatisch startest, ohne alles neu zu bauen

Ein vollständiges Token-System muss nicht am ersten Tag stehen. Sinnvoller ist ein schrittweises Vorgehen:

1. Bestandsaufnahme statt Neuentwurf. Zähle die tatsächlich verwendeten Farb-, Abstands- und Schriftgrößenwerte im Produkt. Die Zahl ist fast immer höher, als das Team erwartet.
2. Primitives bewusst klein halten. Eine überschaubare Farbskala pro Ton reicht meistens aus. Mehr Primitives bedeuten mehr Entscheidungen, nicht mehr Flexibilität.
3. Semantische Ebene nach Bedeutung, nicht nach Aussehen benennen. color-success, nicht color-green. Die Bedeutung bleibt stabil, auch wenn sich die Farbe irgendwann ändert.
4. Ein Werkzeug wählen, das zum Team passt. Figma Variables für enge Design-Dev-Kopplung, CSS Custom Properties oder ein Tailwind-Theme für Code-first-Teams. Das Werkzeug ist austauschbar, die Ebenen-Logik dahinter nicht.
5. Governance erst dann aufbauen, wenn Tokens tatsächlich genutzt werden. Wer darf einen neuen Token anlegen? Wann wird eine Komponente Teil des Systems? Diese Fragen lohnen sich erst, sobald die Basis steht.

Wichtig dabei: Tokens sind der günstigste Teil des Vorhabens. Der teure Teil ist die Disziplin, sie tatsächlich zu verwenden, statt bei Zeitdruck schnell wieder einen Hex-Code direkt reinzuschreiben.

Fazit

Design Tokens sind das Vokabular eines Produkts: benannte, atomare Werte für Farbe, Abstand, Typografie und mehr. Ein Design System ist die Sprache, die aus diesem Vokabular entsteht, inklusive Komponenten, Regeln und Entscheidungsprozess.

Man kann Tokens ohne ausgereiftes System haben, das ist sogar ein guter Anfang. Ein System ohne Tokens ist dagegen selten mehr als eine hübsche Fassade, die beim nächsten Zeitdruck als Erstes bröckelt.

Bonus-Frage zum Mitnehmen: 👉 Wie viele unterschiedliche Grün-, Rot- oder Blautöne würdest du in eurem Produkt finden, wenn du heute tatsächlich nachzählen würdest?