Was ein Design System in der Praxis enthält – und warum es mehr ist als eine Komponentenbibliothek.
Weniger Debatten, mehr Ergebnis
Ein Design System spart Zeit, senkt Fehlerquoten und macht Marken skalierbar. Jedes neue Projekt profitiert von definierten Regeln statt neuen Debatten über Farben, Abstände oder Layoutlogik. Design entsteht nicht aus Intuition – sondern aus klaren, wiederholbaren Entscheidungen.
Die meisten Webprojekte beginnen trotzdem mit der falschen Frage: „Wie soll es aussehen?” Die richtige lautet: „Welche Regeln gelten hier?”
Ein Design System ist kein Styleguide und keine Komponentenbibliothek – obwohl es beides enthält. Es ist ein Regelwerk, das festlegt, wie visuelle Entscheidungen getroffen werden. Farben, Abstände, Typografie, Animationen, Layouts – all das folgt Prinzipien, die einmal definiert und dann auf jedes Element angewandt werden.
Der Effekt: Jede Seite, die innerhalb des Systems entsteht, sieht automatisch zusammengehörig aus. Nicht weil jemand jedes Element einzeln gestaltet hat, sondern weil das System Konsistenz erzwingt.
Was ein Design System tatsächlich enthält
Ein robustes System besteht nicht nur aus Komponenten, sondern aus Schichten, die zusammen eine visuelle Sprache formen. Sieben davon bauen aufeinander auf:
7 Schichten eines Design Systems
1. Markenfundament – Die strategische Basis. Nicht „welche Farbe gefällt dem Kunden”, sondern: Wer ist die Zielgruppe? Welche Tonalität passt? Was machen Wettbewerber, und was vermeiden wir bewusst? Ein einseitiges Dokument mit fünf Attributen reicht – aber ohne diesen Schritt ist jedes Design beliebig.
2. Design Tokens – Das visuelle Fundament in CSS Custom Properties. Farben, Typografie-Stufen, Abstände, Radien, Schatten. Nicht als Figma-Datei, sondern als Code. Tokens sind die einzige Stelle, an der visuelle Werte definiert werden – alles andere referenziert sie.
3. Layout-Regeln – Container, Grid, Breakpoints. CSS Grid für Seitenlayouts, Flexbox für Komponenteninhalte. Container Queries statt Media Queries, wo das Verhalten einer Komponente von ihrem verfügbaren Platz abhängt, nicht von der Bildschirmbreite.
Diese drei Ebenen bilden das technische Fundament – erst danach beginnt die eigentliche Komponentenschicht.
4. Component Library – Isolierte, token-basierte Bausteine. Ein Button referenziert var(--color-primary), nie #3498db. Jede Komponente hat klar definierte Zustände: Default, Hover (Mausberührung), Active, Focus und Disabled.
5. Interaction-Regelwerk – Wie reagieren Elemente auf Nutzerinteraktion? Nicht „irgendein Hover-Effekt”, sondern definierte Feedback-Muster mit festgelegten Timings und Easing-Kurven.
6. Motion-System – Maximal vier bis fünf Bewegungsmuster für das gesamte Projekt. Micro-Feedback (Hover, Click), Content-Reveal (Scroll-basiert), Seitenübergang (View Transitions), Layout-Shift – also Expand- und Collapse-Animationen. Wenn ein fünftes Muster nötig wird, muss dokumentiert werden, warum keines der bestehenden passt.
7. Content-Patterns – Seiten werden zusammengesetzt, nicht neu designed. Jede Seite besteht aus denselben Modultypen: Hero, Content-Sections, CTA-Blöcke, Navigation, Footer. Die Variation entsteht durch unterschiedliche Token-Werte, nicht durch neues Layout.
Code-first: Tokens statt Mockups
Der größte Unterschied zwischen einem theoretischen Styleguide und einem funktionierenden Design System ist die Quelle der Wahrheit. In vielen Teams liegt sie in Figma. Das führt zu einem Übersetzungsproblem: Designer definieren Werte in Figma, Entwickler interpretieren sie im Code – und dazwischen entstehen Abweichungen.
Ein Code-first Design System löst dieses Problem, indem die Tokens direkt in CSS definiert werden:
:root {
/* Farben */
--color-primary: #2D5A3D;
--color-primary-dark: #1E3D2A;
--color-accent: #C67B3C;
--color-bg: #FAFAF8;
--color-surface: #FFFFFF;
--color-text-strong: #1A1A1A;
--color-text-base: #333333;
--color-text-muted: #666666;
/* Fluid Typography */
--step-0: clamp(1.00rem, 0.91rem + 0.43vw, 1.25rem);
--step-1: clamp(1.20rem, 1.07rem + 0.63vw, 1.56rem);
--step-2: clamp(1.44rem, 1.26rem + 0.89vw, 1.95rem);
--step-3: clamp(1.73rem, 1.48rem + 1.24vw, 2.44rem);
/* Spacing – konsistente Skala */
--space-s: clamp(1.00rem, 0.91rem + 0.43vw, 1.25rem);
--space-m: clamp(1.50rem, 1.37rem + 0.65vw, 1.88rem);
--space-l: clamp(2.00rem, 1.83rem + 0.87vw, 2.50rem);
--space-xl: clamp(3.00rem, 2.74rem + 1.30vw, 3.75rem);
/* Form */
--radius-md: 8px;
--shadow-md: 0 4px 6px rgba(0,0,0,0.07);
}clamp() macht die Typografie und Abstände fluid – sie skalieren automatisch zwischen Mobile und Desktop, ohne Media Queries. Die Werte sind einmal definiert und gelten überall.
Figma wird in diesem Modell optional – als Moodboard für die Markenklärung oder als Abnahme-Tool für Kunden, aber nicht als Designquelle.
CSS @layer als Architektur
Moderne Design Systems nutzen CSS Cascade Layers, um die Spezifität kontrolliert zu steuern:
@layer reset, tokens, layout, components, utilities;Jede Schicht hat ihren Platz in der Kaskade. Tokens überschreiben den Reset, Layout überschreibt Tokens, Komponenten überschreiben Layout. Keine Spezifitätskonflikte, keine !important-Hacks.
Eine Komponente sieht dann so aus:
@layer components {
.button {
padding: var(--space-xs) var(--space-m);
font-size: var(--step-0);
background: var(--color-primary);
color: var(--color-bg);
border-radius: var(--radius-md);
transition: background-color 150ms ease-out;
&:hover { background: var(--color-primary-dark); }
&:focus-visible { outline: 2px solid var(--color-primary); outline-offset: 2px; }
&:disabled { opacity: 0.5; cursor: not-allowed; }
}
}Kein fester Farbwert, kein fester Abstand, kein fester Radius. Alles referenziert Tokens. Wenn sich die Markenfarbe ändert, ändert sich ein Token – und jede Komponente, die ihn nutzt, passt sich an.
Das Zwei-Schichten-Modell
Ein Design System, das über mehrere Projekte funktioniert, braucht eine klare Trennung:
Core-System – projektübergreifend identisch. Spacing-Skala, Motion-Regeln, Grid-Logik, CSS-Layer-Reihenfolge, Basiskomponenten, Accessibility-Standards.
Projekt-Theme – pro Kunde unterschiedlich. Farb-Tokens, Typografie, Radius-Philosophie (kantig vs. rund vs. weich), Schatten-Intensität, Hero-Varianten, CTA-Stil.
Die Trennung bedeutet: Ein neues Kundenprojekt startet nie bei null. Das Core-System steht, nur die Token-Werte werden angepasst. Ein Handwerksbetrieb bekommt --radius-md: 4px (kantig, solide), ein Tech-Startup --radius-md: 12px (weich, modern). Dieselben Komponenten, völlig anderer Charakter.
Motion als System, nicht als Deko
Die meisten Websites haben Animationen – aber kein Motion-System. Elemente faden ein, sliden rein, bouncen, gleiten. Jedes Element hat seine eigene Transition-Duration, sein eigenes Easing, seine eigene Distanz.
Ein Motion-System begrenzt das bewusst auf wenige Muster:
Micro-Feedback (100 bis 150ms) – Hover, Focus, Click. Buttons heben sich leicht, Karten werfen einen Schatten. Schnell und subtil.
Content-Reveal (200 bis 400ms) – Elemente werden beim Scrollen sichtbar. CSS Scroll-driven Animations machen das ohne JavaScript möglich:
.reveal {
animation: fade-up linear both;
animation-timeline: view();
animation-range: entry 0% entry 30%;
}Seitenübergang (maximal 300ms) – Navigation zwischen Seiten. Die View Transitions API in Astro macht Crossfades und Shared-Element-Transitions nativ verfügbar.
Layout-Shift (200 bis 300ms) – Akkordeons, Mobile-Navigation, Filter-Panels. grid-template-rows: 0fr zu 1fr animiert, statt max-height-Hacks.
Diese vier Muster decken 95 Prozent aller Animationen ab. Und mit prefers-reduced-motion werden sie für Nutzer, die das bevorzugen, auf ein Minimum reduziert.
Komposition statt Kreation
Wenn das System steht, ist der Seitenaufbau kein Design-Prozess mehr, sondern ein Kompositionsprozess. Jede Seite besteht aus einer Abfolge bekannter Module: Navigation, Hero, Content-Sections, CTA, Footer. Die Variation entsteht durch Reihenfolge, Token-Varianten und Inhalte.
Passt beim Zusammensetzen ein Element nicht, gibt es nur zwei Erklärungen: Es fehlt ein Token – oder eine Komponenten-Variante. Beides wird im System ergänzt, nicht in der einzelnen Seite überschrieben. Der Impuls „Ich brauche ein neues Styling für diese Seite” wird ersetzt durch „Mir fehlt ein Token oder eine Variante.” Das ist der entscheidende Perspektivwechsel.
Damit dieser Perspektivwechsel langfristig funktioniert, braucht das System klare Erweiterungsregeln. Ohne sie wird jedes Design System unweigerlich chaotisch – neue Entwickler umgehen Tokens, Farben werden hardcodiert, Komponenten dupliziert.
Die Lösung ist ein einfacher Entscheidungsbaum: Braucht das Projekt eine neue Farbe? Dann wird ein semantischer Token angelegt, kein Hex-Wert in eine Komponente geschrieben. Braucht es ein neues Element? Zuerst prüfen, ob eine bestehende Komponente eine Variante braucht. Ein neues Motion-Muster? Nur wenn keines der vier bestehenden passt – und dann dokumentiert, warum.
Versionierung folgt semantischen Regeln: Major-Versionen für Breaking Changes im Core, Minor für neue Komponenten, Patches für Bugfixes. Das Core-System wird nicht pro Projekt geforkt, sondern zentral gepflegt.
Was sich rechnet
Ein Design System kostet initial mehr als der direkte Weg. Token-System aufsetzen, Komponenten isolieren, Motion-Muster definieren, Governance dokumentieren – der Aufwand zahlt sich nicht sofort aus, aber er amortisiert sich exponentiell mit jedem weiteren Projekt.
Konkret: Ein neues Kundenprojekt, das auf einem bestehenden Core-System aufbaut, braucht für das visuelle Setup zwei bis drei Tage statt zwei bis drei Wochen. Token-Werte anpassen, Marken-Profil übersetzen, los. Komponenten, Grid und Motion-Regeln stehen bereits.
Der weniger offensichtliche Vorteil: Qualität. Nicht weil einzelne Entwickler besser werden, sondern weil das System schlechte Entscheidungen schwerer macht. Wenn die einzige Möglichkeit, eine Farbe zu verwenden, über einen Token führt, gibt es keine inkonsistenten Farben. Wenn Motion auf vier Muster begrenzt ist, gibt es keine willkürlichen Animationen.
Kein Nice-to-have mehr
Je mehr digitale Produkte ein Unternehmen betreibt – Website, App, Kundenportal, interne Tools – desto teurer wird Inkonsistenz. Design Systems sind kein Overhead für große Teams, sondern ein Werkzeug, das kleine Teams groß arbeiten lässt.
Der Einstieg muss nicht umfassend sein. Ein Token-System für Farben und Typografie, eine Handvoll isolierter Komponenten, zwei Motion-Muster. Von dort wächst das System mit den Projekten – nicht vorher.
Ein Design System ist kein Luxus. Es ist die gemeinsame Sprache, die Design, Code und Marke verbindet – und jedes neue Projekt nahtlos anschließen lässt.
Weiterführende Ressourcen: