Mein Ansatz zum Aufbau von Designsystemen
Strategie & Fundament
Bevor ich Komponenten zeichne oder Tokens definiere, kläre ich grundsätzliche Fragen:
Wer nutzt das System – Designer:innen, Entwickler:innen, externe Partner?
Welche Plattformen und Devices sollen abgedeckt werden?
Wie eng sollen Design und Code verzahnt sein?
Auf dieser Basis entscheide ich, ob ein eher lightweightes UI-Kit ausreicht oder ein vollumfängliches, dokumentiertes System inkl. Komponentenbibliothek notwendig ist.
Atomic Design als Strukturprinzip
Die logische, modulare Struktur des Atomic Design hilft mir, Ordnung in komplexe UI-Welten zu bringen. Ich gliedere Komponenten daher meist in:
Atoms: Grundelemente wie Farben, Typografie, Icons, Buttons
Molecules: Kleine Funktionseinheiten (z. B. ein Label mit Input-Feld)
Organisms: Komplexere UI-Bausteine wie Navigationsleisten oder Cards
Templates: Strukturierte Layouts mit Platzhaltern
Pages: Vollständige Screens mit realen Inhalten
Diese Denkweise erleichtert es nicht nur, Komponenten zu benennen und zu organisieren, sondern fördert auch Konsistenz im Designprozess.
Design Tokens mit semantischer Struktur
Ich arbeite mit einem **zweistufigen Token-Modell**, das zwischen **Systemtokens (alias Referenztokens)** und **semantischen Tokens** unterscheidet. Das ermöglicht sowohl technische Flexibilität als auch semantische Klarheit im Designprozess.
1. Referenz-Tokens
Das sind die **roh definierten Werte**, meist generisch benannt. Sie bilden die Grundlage für konkrete Anwendungen – z. B.:
Diese Tokens repräsentieren z. B. ein bestimmtes Blau oder eine konkrete Pixelgröße – ohne Kontext.
2. Semantische Tokens
Semantische Tokens sind kontextabhängige Verweise auf Referenz-Tokens. Statt #0055FF zu verwenden, definiere ich z. B.:
Der große Vorteil: Die semantische Schicht erlaubt es, Designkontexte konsistent zu definieren und bei Bedarf leicht auszutauschen – etwa bei Dark Mode, Markenvarianten oder Theme-Switches.
Vorteile dieser Struktur
Skalierbarkeit: Änderungen an der Referenz wirken überall – semantische Bezeichnungen bleiben stabil.
Lesbarkeit & Pflege:
color/text/onPrimaryist sofort verständlich – statt sich zu fragen, wofürblue500steht.Theming: Ich kann ganze Farbsysteme austauschen, ohne Komponenten zu ändern – etwa für Light/Dark Themes oder unterschiedliche Markenidentitäten.
Konsistenz: Padding, Fontgrößen, Farbkontraste – alles wird durch Tokens kontrolliert.
Komponentenentwicklung
Ich baue Komponenten sowohl visuell in Figma als auch funktional im Code (z. B. React oder Web Components). Wichtig ist mir dabei:
Responsivität von Anfang an mitdenken
Zustände definieren (hover, focus, disabled, loading)
Barrierefreiheit beachten (z. B. Fokus-Management, ARIA-Roles)
Dokumentation direkt mitliefern, z. B. in Storybook
Die Komponenten sind bewusst nicht monolithisch, sondern flexibel und kombinierbar. Ich achte darauf, dass sie in verschiedenen Kontexten funktionieren.
Dokumentation & Kollaboration
Ein Designsystem entfaltet seinen Wert erst durch gute Dokumentation. Neben dem „Was“ und „Wie“ dokumentiere ich auch das „Warum“ – also Designentscheidungen, Prinzipien und zugrundeliegende UX-Überlegungen.
Storybook für interaktive Komponenten
Figma, Zeroheight oder Notion für Guidelines und Regeln
Figma für visuelle Referenzen mit klarer Namenskonvention