Du willst ein UI, das wie aus einem Guss wirkt – aber du willst kein “Design System Projekt”, das nie fertig wird. Dann bau’s klein. Aber richtig.
Die meisten Teams scheitern nicht an “Design”. Sie scheitern an Konsistenz im Alltag: ein Button hier, ein anderer da, überall andere Abstände, Farben “ungefähr gleich”, und am Ende sieht jedes Feature aus wie ein Gast in deiner eigenen App.
Dann kommt die Gegenreaktion: “Wir brauchen ein Design System!” – und plötzlich wird daraus ein Mammutprojekt mit 200 Komponenten, 12 Varianten pro Ding und einem Wiki, das keiner liest.
Hier ist der pragmatische Weg dazwischen: Design-System light. Kleiner Scope, harte Regeln, echte Nutzung.
Bitte wähle zuerst eine Zusammenfassungsart aus.KI-Zusammenfassung
- Tokens zuerst: Farben, Typo, Spacing, Radius, Shadow – als “Single Source of Truth”.
- 10 Kernkomponenten: Button, Input, Select, Checkbox/Radio, Modal, Toast, Table, Tabs, Card, Badge.
- 3 Regeln statt 30 Seiten: Naming, Spacing-Raster, Varianten-Policy (“weniger ist mehr”).
- Doku im Repo: kurze Beispiele + Do/Don’t, nicht Wiki-Roman.
- Ownership: 1–2 Leute “halten die Linie” – sonst driftet alles wieder weg.
Warum Teams an UI-Konsistenz scheitern
1) “Nur schnell” ist der größte Design-Feind
Wenn niemand entscheidet, wie Dinge aussehen sollen, entscheidet es die Zeit. Und Zeit entscheidet: Copy-Paste, Quick Fix, Inline-Styles, “passt schon”. Das Ergebnis nennt sich Design Drift.
2) Zu viele Varianten sind keine Flexibilität – sie sind Schulden
“Primary/Secondary/Tertiary/Ghost/Link/…” klingt erstmal nett. In der Praxis heißt es: niemand weiß, was man nehmen soll. Und dann nimmt jeder was anderes.
3) Doku, die niemand findet, existiert nicht
Wenn Regeln in Figma-Kommentaren, Slack-Nachrichten und Tickets verteilt sind, hast du keine Regeln. Du hast Folklore.
- Teams gehen weg vom “perfekten Design System” hin zu Tokens + wenige Patterns, die wirklich genutzt werden.
- Design Tokens werden immer mehr als Brücke zwischen Design (Figma) und Code verstanden.
- Accessibility ist nicht “später”: Wenn du’s am Anfang in Tokens/Komponenten packst, wird’s später nicht schmerzhaft.
Was “Design-System light” wirklich heißt
“Light” heißt nicht “halbgar”. Es heißt: klarer Scope. Du baust nicht alles. Du baust genau das, was den größten Hebel hat.
Der Scope (minimal, aber stark)
- Tokens: Color, Typography, Spacing, Radius, Shadow, Z-Index, Breakpoints
- Kernkomponenten: die 10–12 Bausteine, die überall vorkommen
- Patterns: Form Layout, Empty States, Loading States, Errors, Pagination (nur die häufigen!)
- Regeln: Naming, Variante-Policy, Contribution-Flow
Merksatz: Ein Design-System light ist kein Museum. Es ist ein Betriebssystem für UI-Entscheidungen.
Vergleich: UI Kit vs Design-System light vs Full Design System
| Ansatz | Was du bekommst | Was es kostet | Wann es passt | Typischer Fail |
|---|---|---|---|---|
| UI Kit | Visuelle Bausteine (meist Design-only) | Gering | Marketing-Sites, kleine Apps, schnelle Starts | Kein Code-Äquivalent → Drift zwischen Design & Produkt |
| Design-System light | Tokens + Kernkomponenten + klare Regeln | Mittel (aber kontrollierbar) | Produkt-Teams, Agenturen mit mehreren Projekten, Scale-up | Zu viele Varianten → “light” wird heimlich “monster” |
| Full Design System | Komponenten-Familien, Governance, Research, Plattform-Teams | Hoch | Große Organisationen, mehrere Produkte, viele Teams | System wird Pflegefall, weil Ownership fehlt |
- Wenn du gerade erst startest: nimm ein bestehendes System als Referenz (Material, Polaris, Spectrum, GOV.UK) – aber kopier nicht blind.
- Für “light” brauchst du kein Mega-Tooling. Ein sauberer Repo-Ordner + Storybook/Docs reicht oft.
- Design Tokens sind der beste Hebel, wenn Design und Dev wirklich zusammenarbeiten.
So setzt du’s um
Mini-Use-Case: “Neue Feature-Seite – sieht aus wie der Rest”
Du baust ein neues Feature (z.B. Settings). Ohne System würdest du Buttons, Abstände, Formulare “nach Gefühl” bauen. Mit Design-System light machst du nur noch zwei Entscheidungen:
- Welche Komponenten nutze ich (Button, Input, Card, Tabs)?
- Welche Tokens gelten (Spacing, Typo, Farben)?
Der Rest ist Standard. Genau das spart Zeit.
2-Wochen-Plan (realistisch, nicht “wir bauen jetzt ein System”)
- Inventur: Screenshot-Sammlung deiner aktuellen UI (Buttons, Forms, Tables, Modals).
- Token-Set definieren: neutrales Grundset + Akzentfarben, Typo-Skala, Spacing-Raster.
- Kernkomponenten bauen: Button, Input, Select, Checkbox/Radio, Modal, Toast, Tabs, Card, Table, Badge.
- Docs anlegen: pro Komponente: Zweck, Varianten, Do/Don’t, Beispiel.
- Adoption: ein echtes Feature auf das System umstellen (nicht alles).
- Regel setzen: “Neue UI nur noch über Tokens/Komponenten.”
Checkliste (damit “light” nicht kippt)
- Variante-Policy: Jede neue Variante braucht einen echten Use-Case (kein “könnte man mal brauchen”).
- Naming: Tokens/Komponenten heißen so, dass man sie findet (nicht “blue500_v2_final”).
- Ownership: 1 Owner für Entscheidungen + 1 Backup. Ohne das: Drift.
- Accessibility-Basis: Fokus-States, States (disabled/error), klare Kontraste als Standard in Komponenten.
// “Design-System light” Definition fürs Team (copy & paste):
// 1) Tokens sind die Wahrheit (Farben/Spacing/Typo).
// 2) UI wird aus Kernkomponenten gebaut.
// 3) Neue Varianten nur mit Begründung + Beispiel.
// 4) Doku ist Teil des PRs.
// 5) Owner entscheidet, wenn’s knallt.Typische Fehler & wie du sie vermeidest
- Fehler: Du startest mit 50 Komponenten. Fix: starte mit 10 Kernkomponenten, die überall vorkommen.
- Fehler: Tokens sind “nur Design”. Fix: Tokens gehören in Code und Design, sonst driftet’s.
- Fehler: Jede “Wunschfarbe” wird eine Variante. Fix: “Wenn’s kein Produktproblem löst, gibt’s keine Variante.”
- Fehler: Doku ist optional. Fix: PR-Check: Verhalten/UI geändert → Doku/Example update.
- Fehler: Niemand ist Owner. Fix: benenne Owner + vereinbare “Entscheidung in 24h, sonst Blocker”.
- Du hast 8 Button-Varianten und keiner weiß, welche “richtig” ist.
- Tokens existieren nur in Figma → Dev baut “ungefähr” nach → nach 3 Sprints sieht alles anders aus.
- Du führst ein System ein, aber erlaubst Ausnahmen ohne Regeln → System wird Deko.
Fazit: Konsistenz ist ein Prozess, kein Artefakt
Wenn du Konsistenz willst, brauchst du keine UI-Bibel. Du brauchst wenige, starke Standards: Tokens + Kernkomponenten + klare Regeln.
Meine Empfehlung: Bau “Design-System light” so, dass es in zwei Wochen nutzbar ist. Dann wächst es nur noch über echte Use-Cases – nicht über Ego und “könnte man mal”.
Nächster Schritt: Mach eine UI-Inventur und definiere Tokens. Das ist der schnellste Hebel, um Drift zu stoppen.
FAQ
Was gehört in ein kleines Design System?
Tokens (Farben/Spacing/Typo), 10–12 Kernkomponenten und ein paar Patterns (Form Layout, Loading, Empty States). Plus: klare Regeln zu Varianten und Naming. Mehr brauchst du am Anfang nicht.
Design Tokens: Was sind die und wie starte ich?
Tokens sind benannte Designwerte (z.B. “spacing-sm”, “color-accent”), die in Design und Code wiederverwendet werden. Starte mit wenigen Kategorien (Color, Spacing, Typo) und mach sie zur Quelle der Wahrheit.
Wie verhindere ich Design Drift im Team?
Regel + Workflow: Neue UI nur über Tokens/Komponenten, Varianten nur mit Begründung, Doku-Update im PR. Und ganz wichtig: Owner, der Entscheidungen trifft.
Wann lohnt sich ein “richtiges” Design System?
Wenn du mehrere Produkte/Teams hast, starke Plattform-Governance brauchst und UI-Entscheidungen koordinieren musst. Für viele Teams ist “light” lange der Sweetspot.
Wie dokumentiere ich UI-Regeln ohne Wiki-Hölle?
Kurze Komponentenseiten: Zweck, Varianten, Do/Don’t, Beispiele. Doku im Repo, damit sie über PRs gepflegt wird. Wenn keiner sie findet, ist sie wertlos.
Wie bekomme ich Accessibility in ein kleines System?
Baue Basics als Standard in Komponenten ein: Fokus-States, klare States (disabled/error), sinnvolle Kontraste, saubere Semantik und Tastaturbedienung. Dann ist Accessibility nicht “Feature”, sondern Default.
Welche Fehler machen Teams beim Design-System-Aufbau am häufigsten?
Zu großer Scope, zu viele Varianten, keine Ownership, Tokens nur im Design, Doku ohne Workflow. Alles Dinge, die du mit “light” bewusst vermeiden kannst.
