Die 50-Punkte-Checkliste für Design-System-Audits

Dimension 1: Token-Architektur (10 Punkte)

Die Token-Architektur bildet das Fundament. Ohne konsistente Tokens baut alles Weitere auf Sand.

Tokens existieren in einem strukturierten Format (JSON, DTCG) – nicht nur als SCSS-Variablen oder Figma-Styles. Es gibt eine klare Trennung in Primitive, Semantic und Component Tokens. Aliasing (Token-Referenzen) wird konsistent verwendet. Farbpaletten sind vollständig und systematisch aufgebaut (keine willkürlichen Hex-Werte). Typografie-Tokens decken alle Stufen ab (H1–H6, Body, Caption, etc.). Spacing-Tokens folgen einem nachvollziehbaren System (4px-Grid, Fibonacci, etc.). Token-Naming folgt einer dokumentierten Konvention (CTI oder vergleichbar). Dark Mode / Multi-Theme ist über Token-Modes lösbar, nicht über separate Stylesheets. Verwaiste Tokens (definiert, aber nicht referenziert) sind identifiziert. Eine Build-Pipeline transformiert Tokens automatisch in CSS/SCSS/etc.

Dimension 2: Komponentenbibliothek (12 Punkte)

Die Bibliothek ist der sichtbare Teil des Design-Systems. Qualität, Konsistenz und Abdeckung entscheiden über die Adoption.

Alle häufig verwendeten UI-Patterns existieren als Komponenten (Button, Input, Select, Dialog, Card, etc.). Komponenten-APIs sind konsistent (gleiche Props-Patterns für ähnliche Funktionen). Alle interaktiven Komponenten haben korrekte ARIA-Attribute. Keyboard-Navigation funktioniert in allen Komponenten (Tab, Enter, Escape, Arrow Keys). Fokus-Management ist korrekt implementiert (Focus Trap in Modals, Fokusrückgabe). Farbkontraste erfüllen WCAG 2.1 AA (mindestens 4,5:1 für Text). Komponenten nutzen ausschließlich Design Tokens – keine hardcoded Werte. Es gibt keine duplizierten Komponenten mit unterschiedlichen Implementierungen. Responsive Verhalten ist in Komponenten eingebaut, nicht nur in Layouts. Bundle-Size ist optimiert (Tree-Shaking möglich, keine unnötigen Dependencies). Komponenten haben definierte States (default, hover, active, focus, disabled, error). Component Stories / Beispiele existieren für alle Varianten.

Dimension 3: Dokumentation (10 Punkte)

Dokumentation entscheidet über Adoption. Ein undokumentiertes Design-System wird nicht genutzt.

Eine zentrale Dokumentationsseite existiert und ist für alle Teammitglieder zugänglich. Für jede Komponente existiert eine Dokumentationsseite mit Beschreibung, Props-Tabelle und Beispielen. Usage Guidelines beschreiben, wann welche Komponente zu verwenden ist. Do/Don’t-Beispiele illustrieren korrekte und falsche Verwendung. Code-Snippets sind kopierbar und funktionsfähig. Token-Dokumentation zeigt alle verfügbaren Tokens mit Werten und Verwendungszweck. Die Dokumentation ist aktuell (kein Content älter als 6 Monate ohne Review). Ein Changelog dokumentiert Breaking Changes und neue Features. Onboarding-Guide für neue Teammitglieder existiert. Dokumentation ist durchsuchbar.

Dimension 4: Prozesse (8 Punkte)

Prozesse entscheiden, ob ein Design-System lebt oder stagniert.

Ein definierter Prozess für Komponentenanfragen existiert. Design und Engineering arbeiten synchron (nicht Design-then-Handoff). Ein Versionierungsschema ist definiert und wird konsistent angewendet (SemVer). Breaking Changes werden vor dem Release kommuniziert. Ein Contribution-Modell beschreibt, wie Teams zum System beitragen können. Regelmäßige Reviews (monatlich/quartalsweise) bewerten den Systemzustand. Es gibt einen definierten Owner / ein Core-Team für das Design-System. Feedback-Kanäle (Slack, Issues) existieren und werden aktiv genutzt.

Dimension 5: Tooling und Abhängigkeiten (10 Punkte)

Tooling und Abhängigkeiten bestimmen die langfristige Souveränität des Systems.

Alle npm-Abhängigkeiten sind inventarisiert und auf bekannte Schwachstellen geprüft. Keine externen CDN-Requests bei Seitenaufruf (Fonts, Icons, Scripts self-hosted). Analytics läuft auf EU-hosted oder self-hosted Infrastruktur. Figma/Design-Tool-Abhängigkeit ist dokumentiert und eine Exit-Strategie existiert. Die Build-Pipeline läuft auf eigener Infrastruktur oder EU-SaaS. Lizenzen aller Dependencies sind geprüft und kompatibel. Es gibt keinen Single Point of Failure (ein Dienst, dessen Ausfall das System lahmlegt). Dependency-Updates werden regelmäßig durchgeführt (keine Dependencies älter als 12 Monate). Die CI/CD-Pipeline ist automatisiert (Linting, Testing, Building, Deploying). Jurisdiktion der kritischen Dependencies ist dokumentiert.

Maximaler Score: 100 Punkte. Unter 40: Grundlagen fehlen, System braucht grundlegenden Neuaufbau. 40–60: Solide Basis, aber signifikante Lücken in einzelnen Dimensionen. 60–80: Guter Zustand, gezielte Optimierung in Schwachstellen. Über 80: Ausgereiftes System, Fokus auf kontinuierliche Verbesserung.

Kernpunkte

• 50 Prüfpunkte über fünf Dimensionen machen Design-System-Audits reproduzierbar und vergleichbar.
• Token-Architektur und Tooling/Abhängigkeiten sind die am häufigsten vernachlässigten Dimensionen.
• Der Scoring-Ansatz (0/1/2 pro Punkt, max. 100) ermöglicht Vergleichbarkeit über Zeit und zwischen Systemen.
• Dimension 5 (Tooling und Abhängigkeiten) ist der Souveränitäts-spezifische Differenzierungsfaktor.
• Die Checkliste ist ein Startpunkt – organisationsspezifische Anforderungen sollten ergänzt werden.
• Regelmäßige Audits (halbjährlich) verhindern, dass ein System schleichend verfällt.