Was macht Design-System-Builder?
Ein Designsystem ist eine Sammlung von einmal getroffenen Entscheidungen, sodass nicht jeder Bildschirm sie neu treffen muss. Tokens halten die Entscheidungen, Komponenten wenden sie an, Dokumentation erklärt sie. Skaliere den Aufwand auf das Projekt: Eine App für ein Wochenende braucht eine 40-zeilige Token-Datei und eine DESIGN.md; ein Multi-Team-Produkt benötigt Pipelines und Governance. Starte klein, wachse durch Extraktion.
Prozess
0. Lese, was existiert
Suche nach: Tokens/Theme-Dateien, tailwind-Konfiguration oder @theme-Blöcke, components.json, CSS-Variablen, einem theme/-Modul, Figma-Links (verwende den Figma MCP get_variable_defs/search_design_system, falls verbunden), DESIGN.md/.interface-design/system.md. In bestehenden Codebasen extrahiere vor dem Erfinden: Grep die tatsächlich verwendeten Farben, Schriftgrößen, Abstände und Radien, gruppiere sie und schlage die konsolidierte Skala vor. Zeige dem Benutzer das Vorher→Nachher-Mapping.
1. Definiere die Richtung (ein Absatz)
Wer es nutzt, wie es sich anfühlen soll (in konkreten Worten: "dicht wie ein Handelsterminal", "ruhig wie eine Lese-App"), Plattform(en), Markenbeschränkungen, Dichte, Hell/Dunkel. Dies treibt alle folgenden Skalenentscheidungen. Wenn interface-design- oder frontend-design-Skills im Spiel sind, übernehmen diese den ästhetischen Schritt; dieser Skill verwandelt die Richtung in ein System.
2. Grundlagen (Tokens)
Baue in dieser Reihenfolge – jedes hängt vom vorherigen ab:
- Farbe → Führe das Tool des
color-theory-Skills aus:python3 <skills-dir>/color-theory/scripts/palette.py system <brand-hex> --format tailwind|css|json(color-theoryist ein Geschwisterverzeichnis dieses Skills). Es erzeugt primitive Rampen + verifizierte helle/dunkle semantische Rollen. - Typografie → Schriftfamilien (≤2, plus Mono), eine Schriftskala mit benannten Rollen, Zeilenhöhen, Gewichten, Tracking. Siehe
references/scales.md. - Abstand → 4px-Basisraster; T-Shirt- oder numerische Skala; Layout-Abstände getrennt von Komponenten-Padding.
- Form → Radius-Skala (und eine Regel für Verschachtelung: innerer Radius = äußerer − Padding), Rahmenbreiten.
- Höhe → Schatten-Skala (hell) und Oberflächenhelligkeitsstufen (dunkel), Z-Index-Ebenen.
- Bewegung → Dauern + Übergangsfunktionen als Tokens (und reduzierte-Bewegung-Verhalten).
- Layout → Breakpoints, Containerbreiten, Rasterspalten, sichere Bereiche (mobil).
- Größe → Steuerelement-Höhen (sm/md/lg), Symbolgrößen, minimale Touch-Ziele.
3. Token-Architektur
Drei Ebenen – Komponenten dürfen nur die semantische (oder Komponenten-)Ebene konsumieren:
primitive --blue-600, --space-4, --radius-2 Rohwerte, benannt nach dem, was sie SIND
semantisch --color-accent, --space-inset-md, --radius-control Benannt nach der AUFGABE, aliasen primitive Werte, wechseln pro Theme
Komponente --button-bg, --card-padding Optional; nur für Komponenten mit echtem Theming-Bedarf
Theme-Wechsel (Dark Mode, Marken, Dichte, hoher Kontrast) = Neuausrichtung semantischer Tokens. Komponenten ändern sich nie. Vollständige Namensregeln, DTCG-Format, Modi: references/token-architecture.md.
4. Auf die Plattform(en) ausliefern
- Einzelne Web-App: Handgeschriebene CSS-Variablen + Tailwind v4
@themesind ausreichend. - Web + mobil oder mehrere Apps: Erstelle Tokens in DTCG JSON (eine Quelle), baue mit Style Dictionary v5 oder Terrazzo in CSS, Tailwind, TS, Swift, Kotlin/Compose, Flutter, RN.
Rezepte und Ausgabebeispiele pro Plattform:
references/platform-outputs.md. Starter-DTCG-Datei:assets/tokens.example.json.
5. Komponenten
Baue auf zugänglichen Primitiven auf (siehe ui-stack-advisor). Konsistente API: variant (visuelle Absicht), size, tone/color nur bei Bedarf, Zustände über Datenattribute, Komposition über Konfiguration. Jede Komponente dokumentiert alle Zustände: Standard, Hover, Aktiv, Focus-visible, Deaktiviert, Laden, Fehler, Leer, Ausgewählt, Schreibgeschützt. Konventionen und Checkliste: references/components.md.
6. Dokumentieren und verwalten
Schreibe DESIGN.md im Projektstammverzeichnis aus assets/DESIGN.template.md – Richtung, Token-Tabelle, Komponenten-Inventar, Do's/Don'ts und das Warum hinter Entscheidungen. Diese Datei ist das, was zukünftige Sitzungen lesen, um konsistent zu bleiben; halte sie kurz und aktuell. Größere Systeme fügen Storybook (oder Ladle/Histoire), visuelles Regressionstesting, ein Changelog mit Semver und einen Beitragsprozess hinzu (references/components.md#governance).
Standardwerte, die funktionieren (wenn der Benutzer keine Präferenz hat)
| Grundlage | Standard |
|---|---|
| Basiseinheit | 4px; Abstandsskala 0, 1, 2, 4, 6, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96 px |
| Schriftskala | 12, 14, 16 (Textkörper), 18, 20, 24, 30, 36, 48, 60 px (≈1.2–1.25 Verhältnis); Produkt-UI können 14px Textkörper verwenden |
| Zeilenhöhe | 1.5 Textkörper, 1.2–1.3 Überschriften, 1.1 Display; Tracking bei großen Größen straffen (−0.01 bis −0.03em) |
| Radius | 0, 4, 6, 8, 12, 16, 24, voll – wähle eine Persönlichkeit: scharf (2–4), weich (8–12), rund (16+) und wende sie konsistent an |
| Steuerelemente | Höhen 32 / 36–40 / 44–48 px; Touch-Ziele ≥ 44pt (iOS) / 48dp (Android) / 24px min WCAG 2.2 (ziel 44) |
| Bewegung | 100 / 150 / 200 / 300 / 500 ms; Ease-out cubic-bezier(0.23,1,0.32,1) für Eintritt, Ease-in-out für Bewegung, Federn auf Mobilgeräten |
| Breakpoints | 640, 768, 1024, 1280, 1536 (Tailwind); bevorzuge Container-Queries für Komponenten |
| Höhe | 4–5 Schattenebenen; Dark Mode verwendet hellere Oberflächen + subtile Ränder stattdessen |
| Z-Index | Basis 0, Dropdown 1000, Sticky 1100, Overlay 1300, Modal 1400, Popover 1500, Toast 1600, Tooltip 1700 |
Standardwerte sind eine Basis, kein Stil. Die Unterscheidungskraft kommt von den variierenden Entscheidungen: Schriftart, Akzentfarbe, Neutrale-Temperatur, Radius-Persönlichkeit, Dichte und Bewegungscharakter.
Qualitätsbarriere (vor Fertigmeldung prüfen)
- Keine Rohwerte in Komponenten (Hex, px Schriftgrößen, willkürliche Abstände) – grep sie
- Semantische Namen beschreiben Aufgaben, nicht Werte oder Farbtöne
- Hell + Dunkel beide entworfen und kontrastgeprüft (WCAG 2.2 AA)
- Jede interaktive Komponente hat sichtbare Fokus-, Deaktiviert-, Lade-, Fehlerzustände
- Schriftskala hat benannte Rollen (display, h1–h3, body, label, caption, code), nicht nur Größen
- Abstände konsistent: gleiche Beziehung → gleicher Token
- Reduzierte-Bewegung-Variante für Bewegungs-Tokens
- DESIGN.md geschrieben und korrekt
- Mobil: Dynamic Type / Schrift-Skalierung beachtet, sichere Bereiche als Tokens, Touch-Ziele ≥ 44/48
Referenzen
references/token-architecture.md– Ebenen, Namensgrammatik, DTCG 2025.10-Format, Modi/Themes, Aliasing-Regelnreferences/scales.md– Typografie (Skalen, flüssige Schrift, Paarung), Abstand, Radius, Höhe, Bewegung, Dichte, Breakpointsreferences/platform-outputs.md– CSS, Tailwind v4, Shadcn-Theming, React Native (NativeWind/Unistyles/Tamagui), Flutter, SwiftUI, Compose, Style Dictionary/Terrazzo-Pipelinereferences/components.md– Komponenten-API-Konventionen, Anatomie, Zustandsmatrix, Komposition, Dokumentation, Testing, Governanceassets/tokens.example.json– Starter-DTCG-Token-Dateiassets/DESIGN.template.md– DESIGN.md-Vorlage