Design System
Blatt-Skill in Design; erreichbar über die Domain oder den Namen.
Ein Design System spart Entscheidungen, solange die Teams ihm vertrauen. Drift untergräbt dieses Vertrauen leise: drei Namen für eine Komponente, rohe Hex-Werte neben den Tokens, die sie duplizieren, Zustände, die niemand dokumentiert hat. Sobald die Menschen dem System nicht mehr vertrauen, bauen sie darum herum. Diese Methode arbeitet in drei Modi – Audit des Systems, wie es ist; Dokumentation einer Komponente, damit sie korrekt verwendet werden kann; Erweiterung mit einem Pattern, das passt – und verankert jeden in der tatsächlichen Quelle: Tokendateien, Komponentencode und der Designdatei, nicht einer generischen Vorstellung eines Design Systems.
Ein ausgearbeitetes Audit-Ergebnis
Situation (fiktiv): eine React-Bibliothek mit einer Tokendatei; die Anforderung lautet "auditiere unsere Buttons und Karten".
Benennung Button, IconBtn und .btn-link nennen ein Konzept auf drei Arten.
→ Übernimm Button mit einer `icon`- und einer `link`-Variante; aliere die alten
Namen für eine Version.
Tokens 23 hartcodierte Farben in Card und Modal. 18 entsprechen einem existierenden Token
(mechanisch ersetzen); 5 passen zu keinem.
→ Die 5 benötigen eine Entscheidung: ein fehlender Token oder ein Designfehler, der
behoben werden muss.
Zustände Card hat keinen Focus-State, obwohl sie klickbar ist.
Die wiederverwendbare Entscheidung ist die Unterscheidung zwischen einem Wert, der einen Token dupliziert (mechanische Korrektur), und einem, der zu keinem Token passt (Designfrage, die einem Menschen vorgelegt werden muss, anstatt zu raten).
Sammle das System
Lies, was vorhanden ist, bevor du es beurteilst: die Token-Quelle, den Komponentencode oder die Bibliothek sowie die Dokumentation. Eine Suche wie rg -n '#[0-9a-fA-F]{3,8}\b|[0-9]+px' src/components findet hartcodierte Werte im Code; passe das Pattern an den Stack an.
Abschnitte, die mit
~~markiert sind, bezeichnen eine Werkzeugkategorie, kein Produkt:~~design tool(z. B. Figma) oder~~knowledge base(z. B. Notion). Verwende das verbundene Werkzeug dieser Kategorie, das der Host bereitstellt; überspringe den Schritt, wenn keines verfügbar ist.
Mit einem ~~design tool überprüfe Komponentennamen, Varianten, Ebenenstruktur und Token-Verwendung in der Designdatei und vergleiche sie mit dem Code. Mit einer ~~knowledge base finde vorhandene Komponentenseiten und Nutzungsrichtlinien und veröffentliche aktualisierte Dokumentation dort nur, wenn die Person danach gefragt hat.
Ein System hat drei Ebenen; Audit und Dokumentation decken jede ab:
| Ebene | Inhalt |
|---|---|
| Tokens | Farbe (Marke, semantisch, neutral), Typografie, Abstände, Radius und Rahmen, Schatten, Bewegungsdauern und Easings |
| Komponenten | Varianten, Zustände (Standard, Hover, Fokus, Aktiv, Deaktiviert, Laden, Fehler), Größen, Verhalten, Barrierefreiheit |
| Patterns | Formulare, Navigation, Datenanzeige, Feedback – Komponenten kombiniert, um ein wiederkehrendes Problem zu lösen |
Wenn Tokens zwischen Werkzeugen wechseln, ist das Format der Design Tokens Community Group (erste stabile Version 2025.10, Oktober 2025) das gemeinsame Austauschformat; folge dem Format, das das Projekt bereits verwendet.
Grundsätze
- Konsistenz vor Neuheit. Das System existiert, damit Teams aufhören, dieselben Dinge immer wieder neu zu entscheiden; eine einmalige Variante braucht einen Grund, warum das System sie nicht bietet.
- Zusammensetzbar innerhalb von Grenzen. Bevorzuge eine Variante oder eine Kombination vorhandener Komponenten gegenüber einer neuen Komponente.
- Undokumentiert bedeutet unbenutzbar. Ein Zustand oder eine Variante, die niemand findet, wird neu gebaut.
- Versionieren und migrieren. Eine bahnbrechende Umbenennung oder Entfernung benötigt einen Migrationspfad, z. B. einen Alias für eine Version sowie einen Codemod oder eine Suche, um Verwendungen zu finden.
Audit
Berichte Zahlen und Belege, nicht eine Bewertung: eine Zahl ohne Kriterien verbirgt, welches Problem relevant ist.
## Design System Audit: [Umfang]
**Geprüft:** [Komponenten, Tokendateien] | **Ergebnisse:** [Anzahl nach Kategorie]
### Benennung
| Problem | Wo | Empfehlung |
|---|---|---|
### Token-Abdeckung
| Kategorie | Tokens definiert | Hartcodierte Werte | Entspricht einem vorhandenen Token |
|---|---|---|---|
### Komponentenvollständigkeit
| Komponente | Zustände | Varianten | Dokumentation | Barrierefreiheit |
|---|---|---|---|---|
| Button | vollständig | teilweise: keine Nur-Symbol-Größe | fehlt | Fokusring vorhanden |
### Priorisierte Maßnahmen
1. [Höchste Benutzer- oder Teamauswirkung zuerst, mit dem erforderlichen Aufwand]
Dokumentieren
Dokumentiere eine wiederverwendbare Komponente für alle, die sie nutzen. Übernimm Props und das Codebeispiel aus der echten Komponente, nicht aus einer erfundenen API.
## Komponente: [Name]
[Was sie ist und wann man sie verwendet – und wann man etwas anderes verwendet]
### Varianten
| Variante | Verwendung, wenn |
|---|---|
### Props
| Prop | Typ | Standard | Beschreibung |
|---|---|---|---|
### Zustände
| Zustand | Visuell | Verhalten |
|---|---|---|
### Barrierefreiheit
- **Rolle:** [Rolle oder natives Element]
- **Tastatur:** [Tab, Enter, Leertaste, Escape, Pfeiltasten]
- **Screenreader:** [wird angesagt als …]
### Do & Don't
| Do | Don't |
|---|---|
### Beispiel
[Ein kurzer Ausschnitt im Framework des Projekts]
Erweitern
Bevor du etwas Neues vorschlägst, liste die vorhandenen Komponenten auf, die dem nahekommen, und erkläre, warum jede nicht ausreicht; die meisten Anfragen enden als neue Variante. Eine neue Komponente verwendet vorhandene Tokens und schlägt nur einen neuen Token mit Begründung vor.
## Vorgeschlagene Komponente: [Name]
### Problem
[Das Benutzerbedürfnis oder die Lücke]
### Vorhandene Optionen
| Komponente | Gemeinsamkeiten | Warum sie nicht ausreicht |
|---|---|---|
### Design
Props, Varianten und Zustände wie in der Dokumentationsvorlage; verwendete Tokens.
### Barrierefreiheit
Rollen-, Tastatur- und Screenreader-Verhalten.
### Offene Fragen
[Entscheidungen, die eine Design-Überprüfung benötigen]
Die Komponenten und Tokens des Systems sind das Subjekt dieser Methode. Ein Lastenheft für ein einzelnes Feature oder einen Bildschirm und die visuelle Ausrichtung eines neuen Produkts sind separate Design-Arbeiten; ein System-Audit ersetzt auch kein WCAG-Audit.