Design Tokens: CTI-Architektur, Benennung, Beispiele für Entwickler

Effizientes Stilmanagement: Design Token Architektur und Benennung mit der CTI-Methodik

Design Tokens sind ein grundlegendes Element moderner Designsysteme, die eine nahtlose Zusammenarbeit zwischen Designern und Entwicklern gewährleisten. Sie ermöglichen die Standardisierung visueller Produktattribute wie Farben, Schriftarten und Abstände, indem sie Rohwerte in benannte Variablen umwandeln. Ein gut konzipiertes Token-System beschleunigt die Entwicklung neuer Benutzeroberflächen erheblich, vereinfacht die Skalierung und Anpassung und minimiert technische Schulden, da das manuelle Ändern fest codierter Stilwerte über verschiedene Komponenten hinweg entfällt. In diesem Artikel tauchen wir tief in die Architektur von Design Tokens und die Besonderheiten von Benennungskonventionen ein, basierend auf der populären CTI-Methodik, die vielen fortschrittlichen Designsystemen zugrunde liegt.

Mehrstufige Abstraktion von Design Tokens

Für den Aufbau eines flexiblen und skalierbaren Designsystems ist der Ansatz zur Wertabstraktion entscheidend. Moderne Systeme verwenden ein dreistufiges Modell (Primitive → Semantisch → Komponente), das oft um eine Nullschicht – Rohdaten – ergänzt wird, um die Vollständigkeit zu gewährleisten. Dieses Modell sorgt für einen strukturierten Datenfluss, bei dem Änderungen auf niedrigeren Ebenen automatisch auf höhere Ebenen übertragen werden, was Konsistenz garantiert und globale Stilaktualisierungen vereinfacht.

0. Rohwerte: Dies sind grundlegende, nicht abstrahierte Daten, wie z.B. hexadezimale Farbcodes (#0055FF), Pixelwerte für Größen (16px) oder spezifische Schriftnamen ('Inter', sans-serif). Sie dienen als Ausgangspunkt, sollten aber nicht direkt in Code oder Designs verwendet werden, um technische Schulden zu vermeiden.

1. Primitive Tokens: Dies ist die erste Abstraktionsebene. Primitive Tokens digitalisieren Rohdaten und geben ihnen aussagekräftige, aber dennoch abstrakte Namen. Zum Beispiel könnte #0055FF zu blue-500 werden. Wenn eine Marke beschließt, den Farbton ihres Unternehmensblaus zu ändern, reicht es aus, den Wert von blue-500 an einer Stelle zu aktualisieren, und diese Änderung wird automatisch auf alle abhängigen Tokens angewendet. Primitive Tokens beschreiben oft Farbpaletten, Abstands-Skalen oder Schriftgrößen.

2. Semantische Tokens: Diese Tokens beschreiben die Rolle oder den Zweck einer Ressource innerhalb der Benutzeroberfläche und beantworten die Frage 'Warum?'. Sie verknüpfen primitive Tokens mit spezifischen Nutzungskontexten. Zum Beispiel könnte blue-500 verwendet werden, um color-bg-primary (die primäre Hintergrundfarbe) zu erstellen. Semantische Tokens spielen eine entscheidende Rolle bei der Implementierung von Themes (hell/dunkel) und der Anpassung an verschiedene Modi, da derselbe semantische Token je nach aktivem Theme auf unterschiedliche primitive Tokens verweisen kann.

3. Komponenten-Tokens: Diese Ebene beschreibt die spezifische Anwendung eines Stils innerhalb eines einzelnen Elements oder einer Komponente und beantwortet die Frage 'Wo?'. Komponenten-Tokens ermöglichen feingranulare Stilanpassungen für spezifische Komponenten, ohne andere Elemente zu beeinflussen, die dieselben semantischen Tokens verwenden könnten. Sie dienen dazu, Ausnahmen und spezifische Komponentenanforderungen zu verwalten und gleichzeitig die Vererbung allgemeiner Semantik zu gewährleisten. Zum Beispiel könnte color-button-bg-primary-hover einzigartig für einen Button sein, selbst wenn sein Basis-Semantik-Token an anderer Stelle verwendet wird.

Die CTI-Methodik: Benennungsarchitektur

CTI (Kategorie → Typ → Element) ist eines der populärsten Benennungsmodelle für Design Tokens, das insbesondere in Verbindung mit dem Tool Style Dictionary weit verbreitet ist und diesen Ansatz populär gemacht hat. Die Kernidee hinter CTI ist, dass der Name eines Tokens seine physikalische Eigenschaft oder Kategorie priorisiert, anstatt die Komponente, zu der es gehört. Dies macht das System für Compiler und Skripte leicht interpretierbar.

Die Benennungsformel in CTI sieht typischerweise so aus: Kategorie-Typ-Element-Unterelement-Zustand.

Betrachten wir jedes Element im Detail:

• Kategorie: Definiert die grundlegende physikalische Natur des Tokens. Dies ist immer das erste Wort im Namen des Tokens und gibt den Datentyp an. Beispiele: color (Farbe), size (Größe), font (Schriftart), spacing (Abstand), radius (Radius).
• Typ: Beschreibt, auf welche UI-Eigenschaft sich diese Kategorie bezieht. Beispiele: background (Hintergrund), text (Text), border (Rand), icon (Symbol).
• Element: Spezifiziert das bestimmte Benutzeroberflächenelement oder die Komponente, auf die sich das Token bezieht. Beispiele: button (Schaltfläche), dropdown (Auswahlmenü), container (Behälter).
• Unterelement (Modifikator): Fügt dem Element eine Klärung hinzu, die seine Variante oder Rolle angibt. Beispiele: primary (primär), secondary (sekundär), success (Erfolg), warning (Warnung), danger (Gefahr).
• Zustand: Beschreibt den interaktiven Zustand eines Elements. Beispiele: hover (Mauszeiger darüber), active (aktiv), disabled (deaktiviert), focus (Fokus).

Zum Beispiel würde ein Token für die Hintergrundfarbe eines primären Buttons im aktiven Zustand so aussehen: color-background-button-primary-active.

Vorteile und Nachteile des CTI-Ansatzes

Wie jede Methodik hat auch CTI ihre Stärken und Schwächen, die bei der Konzeption eines Designsystems berücksichtigt werden sollten.

Vorteile von CTI:

• Optimierung für Compiler: Da das erste Wort eines Tokens immer seine Kategorie (color, size, font) angibt, ist es für Compiler-Skripte (z.B. Style Dictionary) extrem einfach zu verstehen, mit welchen Daten sie arbeiten. Dies vereinfacht die automatische Generierung von CSS-Variablen, SCSS-Mixins, Swift-Dateien und anderen Formaten aus JSON-Token-Definitionen und minimiert den Bedarf an benutzerdefinierten Konfigurationen.
• Effiziente Prüfung und globale Änderungen: Wenn ein Frontend-Entwickler alle Abstände in einer Anwendung überprüfen oder ändern möchte, reicht es aus, einfach nach dem Präfix $spacing- oder --spacing- zu suchen. Dies liefert schnell eine vollständige Liste aller Abstands-Variablen, was für globale Prüfungen oder Massenänderungen praktisch ist.
• Standardisierung: CTI ist die Standardarchitektur für Tools wie Style Dictionary, wodurch es gut dokumentiert und für viele Entwickler, die mit Designsystemen gearbeitet haben, verständlich ist.

Nachteile von CTI:

• Streuung der Komponentenstile: In modernen komponentenbasierten Frameworks (React, Vue) ist eine Komponente, wie z.B. ein Button, eine isolierte Einheit. Beim CTI-Ansatz sind die Stile für diesen Button über das gesamte Designsystem verstreut: Farbe könnte in colors.json liegen, Abstände in spacings.json und Radien in radii.json. Um eine Komponente zusammenzustellen oder zu entfernen, muss ein Entwickler zwischen verschiedenen Dateien "hin- und herspringen", was den Kontext unterbricht und den Workflow erschwert.
• Schwierigkeiten bei Suche und Autovervollständigung: Für einen Entwickler, der einen Button gestaltet, ist es oft wichtiger, schnell alles zu finden, was mit button und primary zusammenhängt, anstatt mit color- oder background-Präfixen. Bei langen CTI-Tokens erscheinen diese Schlüsselwörter in der Mitte. Die Autovervollständigung in einer IDE schlägt zunächst viele Farben vor, wodurch der Entwickler einen erheblichen Teil des Tokens eingeben muss, um zur gewünschten Komponente zu gelangen.
• Aufwand beim Komponenten-Refactoring: Wenn das Unternehmen beschließt, eine Komponente umzubenennen (z.B. modal in dialog), müsste ein Frontend-Entwickler beim CTI-Ansatz Tokens in zahlreichen Kategorien (Farben, Schatten, Z-Index, Abstände) suchen und umbenennen. Wenn die Komponente priorisiert wäre (dialog-bg-color), würde das Umbenennen eines einzelnen Ordners oder einer Gruppe von Tokens ausreichen.

Semantische vs. Komponenten-Tokens: Rollenabgrenzung

Das Verständnis der Unterschiede zwischen semantischen und Komponenten-Tokens ist entscheidend für den Aufbau eines flexiblen Designsystems. Obwohl ihre Benennungsformeln ähnlich sind, unterscheiden sich ihre Zwecke grundlegend.

Semantische Tokens beantworten die Frage 'Warum?'. Sie definieren die Rolle oder Absicht eines Stils. Zum Beispiel bedeutet color-bg-primary "primäre Hintergrundfarbe", unabhängig davon, wo sie verwendet wird. Diese Tokens sind hochgradig wiederverwendbar und dienen dazu, die allgemeine Konsistenz und Theme-Unterstützung zu gewährleisten. Ihre Benennungsformel lautet: [Kategorie]-[Eigenschaft]-[Rolle]-[Prominenz]-[Zustand].

Komponenten-Tokens beantworten die Frage 'Wo?'. Sie beschreiben Stile, die spezifisch für eine bestimmte Komponente sind. Sie werden verwendet, wenn es notwendig ist, von der allgemeinen Semantik abzuweichen oder einen einzigartigen Stil auf ein spezifisches Element anzuwenden, ohne andere Teile des Systems zu beeinflussen. Im Wesentlichen sind sie verwaltete Ausnahmen. Ihre Benennungsformel lautet: [Kategorie]-[Komponente]-[Eigenschaft]-[Rolle]-[Prominenz]-[Zustand]. Wie Sie sehen, wird [Komponente] einfach zur Kette hinzugefügt.

Goldene Regel: Wenn ein Token an verschiedenen Stellen wiederverwendet wird und einen allgemeinen Zweck definiert, ist es ein semantisches Token. Wenn ein Stil nur für ein spezifisches Element oder eine Komponente geändert werden muss, ist es ein Komponenten-Token.

Detaillierung der CTI-Benennungselemente

Für ein tieferes Verständnis der CTI-Benennung wollen wir jedes ihrer Elemente detaillierter mit Beispielen untersuchen:

• Kategorie: Der Hauptordner oder Datentyp. Dies bildet die Grundlage für die Organisation von Tokens.

* color – für alle Farbwerte.

* spacing – für interne und externe Abstände.

* radius – für Eckradien.

* shadow – für Schattenparameter.

* typography – für Textstile (Größe, Gewicht, Zeilenhöhe).

* size – für Elementbreite/-höhe.

* z-index – zur Verwaltung der Element-Schichtreihenfolge.

* opacity – für Opazitätswerte.

* duration – für Animationsdauern.

• Eigenschaft: Klärt, auf welchen Teil der Benutzeroberfläche sich das Token innerhalb seiner Kategorie bezieht.

* bg / surface – für Hintergrundfarbe.

* text – für Textfarbe.

* border – für Rahmenfarbe.

* icon – für Symbolfarbe.

* outline / ring – für Fokusumrisse.

* overlay – für die Hintergrundfarbe von Modal-Fenstern.

• Rolle (Bedeutung / Zweck): Definiert die funktionale oder emotionale Bedeutung des Tokens.

* primary / secondary / tertiary – zur Hierarchieanzeige.

* brand / accent – für Markenfarben.

* success – für Erfolgsmeldungen (grün).

* warning – für Warnungen (gelb).

* danger / error – für Fehler (rot).

* neutral – für neutrale Elemente (grau).

* inverse – für Elemente, die die Farbe auf dunklem Hintergrund invertieren.

* static – für Farben, die sich nicht mit Themes ändern (weiß/schwarz).

• Prominenz (Hierarchie / Intensität): Beschreibt die Intensität oder Sichtbarkeit eines Elements.

* default / main / base – ein Referenzpunkt, Basiszustand (oft im Namen weggelassen).

* muted – weniger prominent.

* subtle – sehr subtil.

* intense – stärker ausgeprägt.

* on-brand – für kontrastierenden Inhalt über einem Marken-Hintergrund.

• Zustand / Modifikator / Größe: Zusätzliche Verfeinerungen.

* Zustände: hover, active, focus, disabled – für interaktive Zustände.

* Größen: sm, md, lg, xl – für verschiedene Komponenten- oder Elementgrößen.

Wichtige Regel für den default-Zustand: Befindet sich ein Token in seinem Basis-, Ruhezustand, wird das Suffix -default in der Regel weggelassen. Zum Beispiel bezieht sich color-text-primary implizit auf den Standardzustand. Andere Zustände werden nach der Rolle hinzugefügt, wie z.B. color-text-primary-hover.

Praktische Beispiele der CTI-Token-Struktur

Um das Verständnis zu festigen, betrachten wir einige praktische Beispiele für die Erstellung von Tokens für Buttons, die den Übergang von Rohwerten zu spezifischen Komponenten-Tokens demonstrieren.

Beispiel 1: Akzent-Button im Standard-Zustand

Nehmen wir an, wir haben einen primären Button mit einer Akzentfarbe.

• 0. Rohwert: #0055FF (rohe blaue Farbe)
• 1. Primitives Token: blue-500 (Abstraktion des Rohwerts)
• 2. Semantisches Token: color-bg-accent (primäre Akzent-Hintergrundfarbe, verweist auf blue-500)
• 3. Komponenten-Token: color-button-accent-bg (Akzent-Button-Hintergrundfarbe, verweist auf color-bg-accent)

Hier sehen wir, wie wir von einem allgemeinen Wert (blue-500) zu einem spezifischeren (color-button-accent-bg) übergehen. Es ist wichtig, dass wir im Komponenten-Token kein -default schreiben, da dies impliziert ist.

Beispiel 2: Akzent-Button im Hover-Zustand

Betrachten wir nun, wie sich die Benennung für denselben Button im Hover-Zustand ändert.

• 0. Rohwert: #0044DD (dunkleres Blau)
• 1. Primitives Token: blue-600 (Abstraktion des dunkleren Blaus)
• 2. Semantisches Token: color-bg-accent-hover (Akzent-Hintergrundfarbe bei Hover, verweist auf blue-600)
• 3. Komponenten-Token: color-button-accent-bg-hover (Akzent-Button-Hintergrundfarbe bei Hover, verweist auf color-bg-accent-hover)

Hier wird das Suffix -hover explizit hinzugefügt, was einen interaktiven Zustand anzeigt. Jede Abstraktionsebene macht das Designsystem flexibler und ermöglicht Farbtonänderungen auf der primitiven Ebene, ohne Tausende von Tokens umbenennen zu müssen.

Beispiel 3: Sekundär-Button im Standard-Zustand

Für einen sekundären Button könnte eine andere Palette verwendet werden, zum Beispiel mit Transparenz.

• 0. Rohwert: #0055FF mit 10% Transparenz oder rgba(0, 85, 255, 0.1)
• 1. Primitives Token: blue-transparent-100
• 2. Semantisches Token: color-bg-secondary (verweist auf blue-transparent-100)
• 3. Komponenten-Token: color-button-secondary-bg (verweist auf color-bg-secondary)

Dieser Ansatz ermöglicht einen einfachen Palettenwechsel für verschiedene Button-Typen unter Verwendung einer gemeinsamen Token-Struktur.

Beispiel 4: Sekundär-Button-Text im Standard-Zustand

Betrachten wir ein Token für den Text innerhalb eines sekundären Buttons.

• 0. Rohwert: #0055FF
• 1. Primitives Token: blue-500
• 2. Semantisches Token: color-text-on-brand (Textfarbe über einem Marken-Hintergrund, verweist auf blue-500). Hier erscheint der Modifikator on-brand, der den Nutzungskontext angibt.
• 3. Komponenten-Token: color-button-secondary-text-on-brand (sekundäre Button-Textfarbe, verweist auf color-text-on-brand)

Wie Sie sehen, steht die Kategorie (color, spacing, typography) immer an erster Stelle, gefolgt von der Eigenschaft oder Komponente und dann von Modifikatoren und Zuständen. Dieses "allgemein zu spezifisch"-Prinzip gewährleistet Vorhersehbarkeit und einfache Navigation innerhalb des Designsystems.

Wichtigste Erkenntnisse

• Design Tokens sind ein Schlüsselelement für die Erstellung skalierbarer, konsistenter und leicht wartbarer Designsysteme, die technische Schulden durch hartcodierte Stile verhindern.
• Das mehrstufige Abstraktionsmodell (Rohwerte → Primitive → Semantische → Komponenten-Tokens) bietet Flexibilität und Verwaltbarkeit und ermöglicht globale Änderungen von einem einzigen Punkt aus.
• Die CTI-Methodik (Kategorie → Typ → Element) ist ein beliebter Benennungsansatz, der für die automatisierte Verarbeitung durch Compiler praktisch ist, aber die kontextbezogene Suche und das Refactoring von Komponentenstilen erschweren kann.
• Semantische Tokens definieren die Rolle und den Zweck eines Stils und gewährleisten Wiederverwendbarkeit und Theme-Unterstützung, während Komponenten-Tokens für feingranulare Anpassungen und die Verwaltung von Ausnahmen innerhalb spezifischer Komponenten dienen.
• Klare Benennungsregeln unter Verwendung von Kategorien, Eigenschaften, Rollen, Hierarchien und Zuständen sind entscheidend für die Aufrechterhaltung von Ordnung und Vorhersehbarkeit innerhalb eines Designsystems.

— Editorial Team