Design Tokens für Farben, Abstände und Typografie

Eine Farbe taucht in mehreren Schaltflächen auf. Ein Abstand wird für Karten, Dialoge und Formulare verwendet. Eine Überschrift erhält dieselbe Größe an verschiedenen Stellen. Solange diese Entscheidungen als einzelne Werte in vielen Dateien liegen, ist jede Änderung eine Suche nach Zusammenhängen. Design Tokens geben wiederkehrenden Entscheidungen Namen. Dadurch lässt sich festhalten, welcher Wert gilt und welche Aufgabe er erfüllt.

Ein Token ist allerdings noch kein vollständiges Gestaltungssystem. Ein sauber benannter Farbwert erklärt weder den richtigen Einsatz noch die Bedienbarkeit einer Komponente. Entscheidend ist die Verbindung aus Bedeutung, technischer Verwendung und überprüftem Beispiel. Dieser Beitrag entwickelt eine kleine nachvollziehbare Grundlage für Farben, Abstände und Typografie. Die Komponentenansicht wird tatsächlich aus dem gezeigten CSS gerendert. Sie ist ein Lernbeispiel ohne erfundene Produktivmessung.

1. Wiederkehrende Entscheidungen zuerst sichtbar machen

Beginne mit dem vorhandenen Entwurf oder der tatsächlichen Webseite. Welche Farben, Abstände und Schriftgrößen kehren wieder? Welche Werte unterscheiden sich aus einem guten Grund? Eine Bestandsaufnahme sollte beides erfassen. Nur weil zwei Karten zufällig denselben Abstand verwenden, müssen sie noch keine gemeinsame gestalterische Aufgabe besitzen. Umgekehrt können leicht unterschiedliche Werte auf eine unbeabsichtigte Abweichung hindeuten.

Betrachte deshalb die Anwendung neben dem Zahlenwert. Ein Innenabstand strukturiert den Inhalt einer Karte. Ein Außenabstand trennt Bereiche. Auch wenn beide momentan gleich groß sind, können sie später unterschiedlich behandelt werden. Die Benennung sollte diese Entscheidung unterstützen. Eine lange Liste aller zufällig gefundenen Zahlen ist noch keine hilfreiche Grundlage.

Für eine kleine Webseite genügt zunächst eine begrenzte Auswahl. Erfasse die häufig verwendeten Werte und die Komponenten, die sie benötigen. Übertriebene Vollständigkeit am Anfang erzeugt viele Namen ohne klare Verantwortung. Ein überschaubares System lässt sich leichter fachlich prüfen und bei tatsächlichem Bedarf gezielt erweitern.

2. Grundwerte und semantische Rollen unterscheiden

Ein Grundwert beschreibt eine gestalterische Auswahl wie einen bestimmten Rotton. Eine semantische Rolle erklärt seine Aufgabe, beispielsweise die Hintergrundfarbe einer primären Aktion. Beide Ebenen können zusammenhängen. Sie beantworten aber unterschiedliche Fragen. Der Grundwert ist Teil der Palette. Die Rolle verbindet ihn mit einem konkreten Einsatz.

Diese Trennung hilft bei späteren Änderungen. Wenn die Aktionsfarbe geändert werden soll, müssen nicht automatisch alle roten dekorativen Elemente folgen. Eine Rolle wie color-action kann bewusst auf einen anderen Grundwert zeigen. Wurde dagegen überall derselbe allgemeine Markenwert direkt verwendet, ist die gewünschte Grenze schwerer auszudrücken.

Es braucht nicht für jeden Einzelfall mehrere zusätzliche Ebenen. Ein einfaches Projekt kann mit wenigen sinnvollen Rollen beginnen. Maßgeblich ist, ob die Benennung eine tatsächliche Entscheidung erklärt. Verschachtelungen ohne praktischen Nutzen erhöhen lediglich die Sucharbeit. Eine gute Struktur macht Zusammenhänge sichtbar und lässt wichtige Unterschiede bestehen.

3. Ein kleines ausführbares CSS-Beispiel aufbauen

CSS Custom Properties können solche Werte innerhalb einer Webseite verfügbar machen. Die MDN-Einführung zu Custom Properties erläutert Definition, Verwendung und Kaskade. Im Beispiel gibt es einen Markenwert, zwei Aktionsrollen, eine Abstandsbasis und zwei Schriftgrößen. Das ist eine begrenzte Auswahl für die gezeigte Demonstration.

:root {
  --color-brand: #b80024;
  --color-action: var(--color-brand);
  --color-action-text: #ffffff;
  --space-unit: 0.5rem;
  --space-component: calc(var(--space-unit) * 3);
  --font-body: system-ui, sans-serif;
  --font-size-body: 1rem;
  --font-size-title: 1.5rem;
}
.demo {
  font-family: var(--font-body);
  font-size: var(--font-size-body);
}
.demo .card {
  padding: var(--space-component);
  border: 1px solid #8b9499;
  background: #ffffff;
  color: #192329;
}
.demo h3 { font-size: var(--font-size-title); }
.demo .button {
  display: inline-block;
  background: var(--color-action);
  color: var(--color-action-text);
  padding: var(--space-unit) calc(var(--space-unit) * 2);
}
.demo.compact {
  --space-component: calc(var(--space-unit) * 2);
}

Bei einer im Prüfbeispiel festgelegten Wurzelschriftgröße von 16 Pixeln ergibt sich aus der halben rem-Einheit ein Basisabstand von 8 Pixeln. Der normale Kartenabstand beträgt 24 Pixel. Die kompakte Variante verwendet 16 Pixel. Diese Werte sind eigene Lernparameter. Sie sind weder eine allgemeine Norm noch eine Empfehlung für jede Komponente.

4. Die Bedeutung einer Überschreibung begrenzen

Die kompakte Variante überschreibt nur den Abstand der Karte. Farbe, Schriftgrößen und Inhalt bleiben gleich. Dadurch lässt sich eine konkrete Änderung nachvollziehen. Die Eigenschaft wird innerhalb des betroffenen Bereichs verwendet. Das Beispiel zeigt keine vollständige Dichtesteuerung für eine ganze Anwendung. Eine solche Funktion müsste weitere Komponenten und ihre Bedienung berücksichtigen.

Die Kaskade ist dabei Teil des Verhaltens. Ein anders gesetzter Wert in einem übergeordneten oder spezifischeren Bereich kann das Ergebnis beeinflussen. Wer ein Token verändert, sollte daher nicht nur seine Definition finden. Auch die tatsächlich wirksame Verwendung muss geprüft werden. Der berechnete Wert einer Komponente ist eine nützliche Kontrollstelle.

Ein gemeinsamer Name garantiert noch keine gemeinsame Wirkung. Eine Komponente kann einen festen Wert verwenden oder das Token in ihrem eigenen Bereich erneut überschreiben. Solche Abweichungen sollten nachvollziehbar sein. Unbemerkte Ausnahmen erschweren die Pflege gerade deshalb, weil die zentrale Liste einen stärkeren Zusammenhang vermuten lässt, als technisch vorhanden ist.

5. Abstände als Beziehungen gestalten

Eine Abstandsskala schafft eine begrenzte Auswahl. Sie kann Entscheidungen vereinfachen und ähnliche Anwendungen zusammenführen. Die Skala muss jedoch zur tatsächlichen Informationsstruktur passen. Ein Abstand innerhalb einer Gruppe erfüllt eine andere Aufgabe als die Trennung zweier Hauptbereiche. Werte werden verständlich, wenn ihre Verwendung diese Beziehungen unterstützt.

Im Beispiel wird eine einfache Basis multipliziert. Das macht die Rechnung gut nachvollziehbar. Daraus folgt keine Pflicht, jeden Abstand als Vielfaches derselben Einheit zu gestalten. Kleine Korrekturen können bei optischen Beziehungen sinnvoll sein. Sie sollten bewusst entschieden werden und nicht als versehentliche Einzelfallwerte im Code entstehen.

Prüfe eine kompaktere Variante außerdem mit realistischem Inhalt. Weniger Innenabstand kann eine Karte ruhiger zusammenführen. Er kann aber auch lange Beschriftungen bedrängen. Ein schönes Beispiel mit zwei kurzen Wörtern beweist wenig über eine längere Übersetzung. Die Skala gehört deshalb mit den tatsächlich benötigten Komponenten und Textmengen überprüft.

6. Typografie nicht auf eine Größenliste reduzieren

Ein Schriftgrößentoken ist nur ein Teil der typografischen Entscheidung. Schriftfamilie, Gewicht, Zeilenhöhe und verfügbare Breite beeinflussen die Darstellung ebenfalls. Eine Überschrift kann dieselbe nominelle Größe verwenden und in einer anderen Schrift deutlich anders wirken. Tokens sollen diese Beziehungen ordnen. Sie ersetzen nicht die Sichtung des tatsächlichen Schriftbilds.

Eine semantische Rolle wie Überschrift oder Fließtext kann mehrere Eigenschaften zusammenfassen. In einfachem CSS werden sie möglicherweise getrennt benannt. Andere Werkzeuge können zusammengesetzte Werte abbilden. Entscheidend ist, dass die beteiligten Personen wissen, welche Eigenschaften zusammengehören und welche Änderungen gemeinsam geprüft werden müssen.

Behalte außerdem den Unterschied zwischen Gestaltung und Dokumentstruktur im Blick. Eine optisch große Zeile ist nicht automatisch die richtige Überschriftenebene. Die semantische Gliederung des Dokuments braucht ihre eigene Begründung. Ein Schriftgrößentoken darf nicht dazu führen, dass Überschriften nur nach gewünschter Optik ausgewählt werden.

7. Farbrollen zusammen mit ihrem Hintergrund prüfen

Ein einzelner Farbwert ist noch kein Kontrastverhältnis. Dafür braucht es die tatsächlich zusammentreffenden Farben. Eine Textrolle und eine Hintergrundrolle sollten deshalb als Kombination geprüft werden. Transparenz, Überlagerungen und wechselnde Hintergründe können das Ergebnis verändern. Die Prüfung eines isolierten Farbfelds genügt in solchen Fällen nicht.

Die WAI-Erläuterung zu WCAG 2.2, Erfolgskriterium 1.4.3 beschreibt für gewöhnlichen Text grundsätzlich 4,5 zu 1 und für großen Text 3 zu 1 mit den dort erläuterten Bedingungen und Ausnahmen. Diese konkrete Anforderung ist von einer vollständigen Barrierefreiheitsbewertung zu unterscheiden. Ein passendes Farbpaar allein prüft keine gesamte Komponente.

Für die Praxis bedeutet das, die tatsächlich verwendeten Kombinationen zu erfassen. Ein Markenton kann als Akzent geeignet sein und als kleine Schrift auf einem bestimmten Hintergrund problematisch werden. Semantische Rollen helfen, solche Einsätze auseinanderzuhalten. Sie machen die notwendige Sichtung und fachliche Prüfung jedoch nicht überflüssig.

8. Zustände als eigene Entscheidungen behandeln

Eine Schaltfläche besitzt möglicherweise Grundzustand, Fokus, Überfahren und deaktivierten Zustand. Diese Varianten benötigen verständliche Unterschiede. Ein einziges Aktionsfarbtoken erklärt noch nicht alle Zustände. Benenne zusätzliche Rollen dann, wenn sie eine konkrete Aufgabe besitzen. Eine große Liste ungenutzter Zustandswerte wäre dagegen nur ein unüberprüfter Vorrat.

Prüfe die Zustände in einer echten Komponentenansicht. Ein Fokus muss im jeweiligen Umfeld erkennbar bleiben. Ein deaktivierter Zustand sollte nicht durch eine missverständliche Beschriftung wie eine verfügbare Aktion wirken. Die Tokenliste dokumentiert Werte. Ob der Zustand verständlich und bedienbar ist, zeigt sich erst im konkreten Einsatz.

Das kleine Beispiel beschränkt sich bewusst auf eine statische Aktionsdarstellung. Es enthält keine vollständige Zustandsbibliothek und keinen tatsächlich angebundenen Formularversand. Diese Grenzen verhindern, dass eine Farbdemonstration als fertiges Funktionsmodul missverstanden wird. Für eine reale Anwendung müssten die benötigten Zustände und Funktionen ergänzt und geprüft werden.

9. Austauschformat und Browsertechnik unterscheiden

Design Tokens können in mehreren Werkzeugen und Plattformen verwendet werden. Die CSS Custom Property ist eine konkrete Browsertechnik. Ein Austauschformat hat eine andere Aufgabe: Es beschreibt Werte und Beziehungen so, dass Werkzeuge sie weiterverarbeiten können. Beide Ebenen können verbunden werden. Sie sind aber nicht dasselbe Dateiformat und nicht automatisch kompatibel.

Das Design Tokens Format Module 2025.10 beschreibt ein Austauschformat und wurde als Community Group Report veröffentlicht. Es ist laut eigener Statusbeschreibung kein W3C-Standard. Diese Unterscheidung ist wichtig, wenn ein Projekt eine technische Grundlage auswählt. Die Bezeichnung Standard sollte nicht ungenau als allgemeines Gütesiegel verwendet werden.

Für ein kleines CSS-Projekt ist deshalb nicht zwingend sofort eine zusätzliche Werkzeugkette nötig. Wenn mehrere Plattformen oder Designwerkzeuge dieselben Entscheidungen nutzen sollen, kann ein definierter Austausch dagegen sinnvoll sein. Prüfe die tatsächlichen Import- und Exportmöglichkeiten der verwendeten Werkzeuge. Ein ähnlich klingender Tokenbegriff beweist keine verlustfreie Übernahme.

10. Namen nach Aufgabe und Änderbarkeit wählen

Ein Name sollte die Verwendung unterstützen. color-red sagt etwas über den sichtbaren Wert. color-action sagt etwas über seine Aufgabe. Beide können sinnvoll sein, wenn ihre Ebene klar bleibt. Ein Name wie color-red-action vermischt möglicherweise beides und wird unpassend, sobald die Aktion eine andere Farbe bekommen soll.

Bei Abständen helfen benannte Rollen oder nachvollziehbare Skalen. space-component kann für ein kleines Lernbeispiel genügen. In einer umfangreichen Anwendung wäre möglicherweise genauer zu unterscheiden, welche Komponente und welche Beziehung gemeint sind. Namen sollten mit dem tatsächlichen Umfang wachsen. Sie müssen nicht vorsorglich jede theoretische Erweiterung abbilden.

Vermeide außerdem unnötige Abkürzungen. Ein paar gesparte Zeichen rechtfertigen selten einen schwer verständlichen Namen. Eine kurze Beschreibung mit typischen Einsätzen und bewussten Grenzen hilft bei der Übergabe. Sie beantwortet, wann der Wert verwendet werden soll und wann eine andere Rolle nötig ist.

11. Bestehende Werte schrittweise zuordnen

Bei einer bestehenden Webseite beginnt die Umstellung mit einer überschaubaren Komponente. Ordne ihre Werte den gewählten Rollen zu und vergleiche die Darstellung vorher und nachher. Die erste Änderung sollte nachvollziehbar bleiben. Eine vollständige gleichzeitige Umbenennung aller Werte erschwert die Suche nach unerwarteten Folgen.

Wenn die Darstellung zunächst gleich bleiben soll, ist diese Gleichheit eine konkrete Prüffrage. Wenn eine bewusste gestalterische Änderung vorgesehen ist, muss sie gesondert benannt werden. Eine technische Zusammenführung und eine neue Gestaltung sind verschiedene Entscheidungen. Werden sie vermischt, lässt sich eine sichtbare Abweichung später schlechter erklären.

Erfasse verbleibende Ausnahmen. Ein historischer Sonderfall muss nicht sofort entfernt werden, sollte aber als solcher verständlich sein. So entsteht ein ehrliches Bild der Abdeckung. Eine zentrale Tokenliste ohne Kenntnis der tatsächlichen Anwendungen vermittelt sonst eine Einheitlichkeit, die im Bestand noch gar nicht erreicht wurde.

12. Änderungen mit einem kleinen Prüfplan absichern

Eine Änderung am gemeinsamen Wert kann mehrere Stellen betreffen. Wähle deshalb typische Anwendungen für die Kontrolle aus. Dazu gehören kurze und lange Inhalte, schmale und breite Ansichten sowie erforderliche Zustände. Der Prüfplan richtet sich nach der Bedeutung des Tokens. Eine Typografieänderung braucht andere Beispiele als ein kleiner Abstand innerhalb einer einzelnen Karte.

Im Lernbeispiel werden berechnete Werte und gleiche Inhalte tatsächlich überprüft. Die normale und die kompakte Karte unterscheiden sich im benannten Innenabstand. Diese begrenzte Prüfung erklärt den Mechanismus. Sie behauptet weder eine vollständige Designsystemabdeckung noch eine gemessene Zeitersparnis durch Tokens.

13. Zuständigkeit und Dokumentation zusammenführen

Ein gemeinsamer Wert braucht eine nachvollziehbare Entscheidungspraxis. Wer darf seine Bedeutung ändern? Welche Anwendungen müssen bei einer Änderung betrachtet werden? Wo steht die Begründung? Diese Fragen sind oft wichtiger als eine besonders große Anzahl von Tokens. Ohne klare Verantwortung kann auch eine technisch saubere Liste widersprüchlich wachsen.

Eine knappe Dokumentation nennt Name, Bedeutung, Wert, typische Verwendung und bekannte Ausnahmen. Für größere Änderungen gehört ein Hinweis auf betroffene Komponenten dazu. Dadurch lässt sich ein neuer Wert nicht nur finden, sondern fachlich einordnen. Die Dokumentation sollte zur tatsächlichen Anwendung passen und nach Änderungen mitgepflegt werden.

• Die wiederkehrenden Entscheidungen sind anhand konkreter Anwendungen erfasst.
• Grundwerte und Rollen sind verständlich unterschieden.
• Die Namen beschreiben die tatsächlich benötigte Bedeutung.
• Farbkombinationen und Zustände werden im Kontext geprüft.
• Abstände und Typografie wurden mit realistischem Inhalt angesehen.
• Berechnete Werte stimmen mit dem beabsichtigten Beispiel überein.
• Ausnahmen und technische Grenzen sind dokumentiert.
• Austauschformate werden nicht mit Browsertechnik verwechselt.
• Änderungen besitzen eine nachvollziehbare Zuständigkeit.

Design Tokens werden damit zu einer handhabbaren Verbindung zwischen gestalterischer Entscheidung und technischer Anwendung. Ihr Wert liegt in verständlichen Beziehungen, überprüften Komponenten und bewusst begrenzten Änderungen. Eine größere Liste ist dafür nicht automatisch besser. Entscheidend ist, dass die benannten Entscheidungen in der tatsächlichen Webseite verlässlich verwendet werden.

14. Einheiten und ihren Bezug ausdrücklich festhalten

Die Einheit wird im CSS-Values-Arbeitsentwurf technisch eingeordnet. Ein Wert von 1rem verweist auf die Schriftgröße des Wurzelelements. Er ist deshalb nicht grundsätzlich gleichbedeutend mit 16 Pixeln. Diese Zahl gilt im gezeigten Prüfaufbau, weil die Wurzelschriftgröße dort entsprechend festgelegt ist. Wenn sich dieser Bezug ändert, ändern sich auch die daraus berechneten Abstände. Das kann gewünscht sein. Die Dokumentation muss den Zusammenhang aber korrekt beschreiben.

Eine andere Einheit kann einen anderen Zweck besitzen. Ein Prozentwert bezieht sich je nach verwendeter Eigenschaft auf eine konkrete Bezugsgröße. Ein fester Pixelwert beschreibt wiederum eine andere Entscheidung. Ein Tokenname allein beseitigt diese Unterschiede nicht. Prüfe deshalb, ob ein Wert mit seiner Einheit an allen vorgesehenen Stellen sinnvoll verwendet werden kann. Ein gemeinsamer Name für unvereinbare Anwendungen schafft nur scheinbare Einheitlichkeit.

In unserem Beispiel lässt sich die Wirkung gezielt kontrollieren. Wird die Wurzelschriftgröße im isolierten Prüfaufbau auf 20 Pixel gesetzt, ergibt die halbe rem-Einheit 10 Pixel. Der normale Kartenabstand wird damit 30 Pixel und der kompakte 20 Pixel. Das ist eine Konsequenz der tatsächlich gezeigten Rechnung. Es ist kein Beweis, dass jede reale Oberfläche bei veränderten Schriftgrößen bereits richtig funktioniert.

15. Fehlerhafte Werte von fehlenden Werten unterscheiden

Die CSS-Variables-Spezifikation beschreibt die Variablenverwendung. Ein Fallback bei einer Variablenverwendung ist keine allgemeine fachliche Fehlerprüfung. Eine Rolle kann vorhanden sein und trotzdem einen Wert enthalten, der zur verwendenden CSS-Eigenschaft nicht passt. Außerdem kann ein technisch zulässiger Wert gestalterisch ungeeignet sein. Diese Fälle verlangen unterschiedliche Kontrollen. Eine fehlende Definition, ein ungeeigneter Datentyp und ein unpassender Kontrast sind nicht dieselbe Art von Problem.

Verlasse dich deshalb nicht ausschließlich auf die zentrale Liste. Öffne die tatsächlich gerenderte Komponente und prüfe ihre berechneten Eigenschaften. Wenn ein neuer Wert scheinbar keine Wirkung zeigt, können Kaskade, Selektor oder eine ungültige Verwendung beteiligt sein. Die Fehlersuche sollte diesen Zusammenhang nachvollziehen, statt sofort einen zusätzlichen festen Wert als Ausnahme einzubauen. Solche schnellen Ausnahmen können die ursprüngliche Ursache verdecken.

Für die Freigabe ist schließlich entscheidend, was die Besucher sehen und bedienen. Technische Prüfungen liefern dafür konkrete Hinweise. Sie ersetzen die gestalterische Sichtung mit passenden Inhalten nicht. Ein kleines System mit ehrlichen Grenzen und nachvollziehbaren Beispielen ist leichter zu pflegen als eine umfangreiche Sammlung, deren tatsächliche Wirkung niemand mehr sicher zuordnen kann.

Quellen und technischer Stand

Quellenstand: 9. November 2026. Die verlinkten MDN-, WAI- und DTCG-Primärquellen wurden tatsächlich aufgerufen. Das Austauschformat wird ausdrücklich in seiner Fassung 2025.10 eingeordnet. Die CSS-Werte und Demonstrationskarten sind eigene Lernparameter ohne Anspruch auf universelle Skalierung oder vollständige Konformitätsprüfung.