Ein Design System ist ein lebendiges System, mit dem du Farben, Typografie, Abstände, Komponenten und Regeln aus einer einzigen Quelle verwaltest und über jedes Produkt hinweg konsistent wiederverwendest, statt jeden Screen von Grund auf zu gestalten. Man verwechselt es mit einem Styleguide, doch der Unterschied ist dieser: Ein Dokument beschreibt nur, "wie es aussehen soll", während ein Design System zusätzlich funktionierenden Code, fertige Komponenten und die Regeln zu ihrer Kombination liefert. Mit anderen Worten: Es bringt Designer und Entwickler dazu, dieselbe Sprache zu sprechen.
Was löst ein Design System eigentlich?
In einem kleinen Projekt schreibst du die Farbe eines Buttons direkt in den Screen und niemand bemerkt es. Doch sobald du zehn, zwanzig, fünfzig Screens hast, werden die überall verstreuten kleinen Entscheidungen (#3b82f6 an einer Stelle, #3a80f0 an einer anderen) zur Inkonsistenz und zum Wartungsalbtraum. Ein Design System zentralisiert diese Entscheidungen und löst folgende Probleme:
- Konsistenz: derselbe Button, derselbe Abstand, derselbe Schatten auf jeder Seite.
- Tempo: einen neuen Screen zu bauen wird so einfach wie fertige Teile anzuordnen.
- Wartung: die Markenfarbe zu ändern bedeutet, nur einen einzigen Wert zu aktualisieren.
- Gemeinsame Sprache: der Designer sagt "Primary Button" und der Entwickler kennt genau die Komponente.
Schicht 1: Design Tokens
Ein Token ist die kleinste benannte Einheit einer Designentscheidung. Statt eines rohen Wertes #1e293b gibst du ihm einen aussagekräftigen Namen wie color-text-primary. So bleibt der Name stabil, auch wenn sich der Wert ändert, und überall wird automatisch aktualisiert. Der sauberste Ansatz nutzt zwei Token-Ebenen: zuerst rohe Werte (primitive), dann semantische Aliase.
:root {
/* Primitive: rohe Werte */
--blue-500: #3b82f6;
--slate-900: #0f172a;
--space-2: 8px;
--space-3: 12px;
/* Semantisch: Aliase, die die Absicht ausdrücken */
--color-action: var(--blue-500);
--color-text: var(--slate-900);
--radius-button: 8px;
}
.btn-primary {
background: var(--color-action);
color: white;
padding: var(--space-2) var(--space-3);
border-radius: var(--radius-button);
}Wenn du zu einem dunklen Theme wechseln willst, definierst du nur die semantischen Tokens neu; den Code der Komponenten rührst du nicht an. Genau dort liegt die Skalierbarkeit.
Schicht 2: Komponenten
Wenn Tokens die Farbe sind, dann sind Komponenten die Bausteine. Button, Eingabefeld, Karte, Modal, Navigation... jedes ist ein in sich geschlossenes Teil, das Tokens nutzt und sich immer wieder einsetzen lässt. Eine gute Komponente wird zusammen mit ihren Varianten entworfen: die Primary-/Secondary-/Ghost-Stile eines Buttons, seine Hover- und Disabled-Zustände, seine Größen Small/Medium/Large. Darüber muss man systematisch nachdenken, nicht Stück für Stück.
- Atomarer Ansatz: kleine Teile (Atome) verbinden sich zu größeren (Molekülen, Organismen).
- Einzelverantwortung: eine Komponente macht eine Sache gut; Geschäftslogik vergräbst du nicht darin.
- Barrierefreiheit von Anfang an: Tastaturfokus, Kontrast und ARIA-Labels sind in die Komponente eingebaut.
Schicht 3: Dokumentation und Nutzungsregeln
Selbst die besten Tokens und Komponenten sind nutzlos, wenn niemand weiß, wie man sie verwendet. Die Dokumentation erklärt mit Beispielen, wofür jede Komponente da ist, wann man sie einsetzt (und wann nicht). In der Praxis empfehlen sich drei Bausteine: lebende Komponentenbeispiele, kopierbarer Code und "Do / Don't"-Regeln. Tools wie Storybook sind gängig, um Komponenten in einer isolierten Umgebung zu zeigen; auf der Designseite öffnen Figma-Bibliotheken dieselben Tokens und Komponenten für Designer.
Wie baut ein kleines Team eines auf?
Zu versuchen, von null ein riesiges System zu bauen, ist für die meisten kleinen Teams eine Falle. Der realistischere Weg ist, schrittweise voranzugehen:
- 1. Mach eine Bestandsaufnahme: wie viele verschiedene Buttons, Farben und Schriftgrößen hat dein aktuelles Produkt? Meist weit mehr als nötig.
- 2. Beginne mit Tokens: lege die Skalen für Farbe, Typografie und Abstand fest. Hier holst du den höchsten Ertrag.
- 3. Standardisiere die 5–10 meistgenutzten Komponenten: Button, Eingabefeld, Karte genügen; mach nicht alles auf einmal.
- 4. Halte das Single-Source-Prinzip ein: Design (Figma) und Code sollten dieselben Namen verwenden; driften sie auseinander, stirbt das System.
- 5. Versioniere und kommuniziere: dokumentiere Änderungen und kündige sie an; ein Design System lebt wie ein Produkt.
Du brauchst kein spezielles Werkzeug; selbst schlichte CSS-Variablen und ein gut benannter Komponentenordner sind für ein kleines Team ein mehr als ausreichender Startpunkt.
Häufige Fragen
Sind ein Design System und ein Styleguide dasselbe?
Nein. Ein Styleguide ist ein Dokument, das Markenregeln beschreibt (Logo, Farbe, Ton). Ein Design System umfasst das, liefert aber zusätzlich funktionierenden Code, wiederverwendbare Komponenten und Tokens. Der Styleguide sagt "so soll es aussehen"; das Design System sagt "hier ist ein fertiges Teil, nutze es".
Ist ein Design System für ein Soloprojekt übertrieben?
Eine leichte Variante lohnt sich fast immer. Selbst wenn du allein arbeitest, hilft dir das Festlegen von Farb- und Abstands-Tokens, deine eigenen Entscheidungen später zu erinnern und konsistent zu bleiben. Eine vollwertige Komponentenbibliothek brauchst du vielleicht nicht, aber die Token-Schicht zahlt sich in jeder Größenordnung aus.
Mit welchem Werkzeug sollte ich anfangen?
Schlichte CSS Custom Properties reichen für Tokens. Zum Dokumentieren von Komponenten sind Storybook und auf der Designseite Figma-Bibliotheken gängige Optionen. Prinzipien zählen mehr als Werkzeuge: eine Quelle, semantische Namen und schrittweises Wachstum.
Willst du eine konsistente, skalierbare Oberfläche? Von Markenfarben bis zu einer funktionierenden Komponentenbibliothek helfe ich dir beim Aufbau eines Design Systems. Nimm Kontakt auf und lass uns über dein Projekt sprechen.