Design-Systeme, ohne das Marketing-Geschwätz
Der Begriff „Design-System“ ist nach zwei Jahren LinkedIn-Posts komplett abgenutzt. Zeit, die Definition zurückzusetzen.
Ein Design-System ist die ausführbare, versionierte Single Source of Truth dafür, wie Ihr Produkt aussieht und sich verhält. „Ausführbar“, weil Designer mit denselben Komponenten arbeiten, die Entwickler ausliefern. „Versioniert“, weil sich das System mit der Zeit weiterentwickelt und alte Versionen weiter funktionieren müssen. „Single Source of Truth“, weil das System seinen Zweck verfehlt, wenn noch Unklarheit besteht.
Eine Figma-Datei mit ein paar Buttons ist kein Design-System. Ein Storybook mit 40 Komponenten und ohne Design-Tokens ist kein Design-System. Das System ist die Brücke zwischen beidem.
Was sich ändert, wenn Sie eines haben
Drei Dinge, messbar:
Geschwindigkeit bei neuen Features. Bei Projekten, in die wir mitten in der laufenden Zusammenarbeit ein echtes Design-System einführen, beschleunigt sich die Feature-Auslieferung innerhalb von zwei Sprints um 30–50 %. Designer hören auf, Formularmuster neu zu erfinden. Entwickler hören auf, Buttons neu zu implementieren. PRs werden kleiner.
Konsistenz über alle Oberflächen hinweg. Bei Unternehmen mit mehreren Produkten liegt der Nutzen auf der Hand, aber auch Teams mit nur einem Produkt profitieren. Die Marketing-Website, die App, das Admin-Dashboard, die E-Mail-Templates — wenn sie dieselben Tokens teilen, wirken sie wie aus einem Guss. Ohne gemeinsame Tokens driften sie zwangsläufig auseinander.
Onboarding-Kosten. Ein neuer Designer oder Entwickler kann den ersten PR schon in der ersten Woche liefern statt erst im ersten Monat. Das System beantwortet die meisten „Wie machen wir X“-Fragen, bevor sie überhaupt gestellt werden.
Was gehört hinein
Ein funktionierendes Design-System besteht aus grob vier Ebenen. Lässt man eine davon weg, wird das System brüchig.
1. Tokens. Farben, Typografie, Abstände, Radien, Schatten, Animationsdauern, Easing-Kurven. Das ist JSON, keine Bilder. Sie speisen sowohl Figma (über Tools wie Tokens Studio) als auch den Code (über Style Dictionary oder Ähnliches). Die Token-Ebene ist die wichtigste — und die am häufigsten übersprungene.
2. Primitives. Buttons, Inputs, Selects, Checkboxes, Radios, Toggles, Badges, Tooltips, Modals. Die atomaren UI-Elemente, die auf jedem Screen auftauchen. Sie sollten einmal implementiert werden — mit sauberer Barrierefreiheit (Focus Rings, ARIA, Tastaturbedienung) — und mit Prop-Tabellen dokumentiert sein.
3. Patterns. Formulare, Navigation, Empty States, Loading States, Error States, Datentabellen. Das sind Kompositionen aus Primitives. Sie legen eine Haltung fest: „So handhaben wir ein mehrstufiges Formular“ statt „Hier ist eine Formular-Bibliothek.“
4. Guidelines. Sprache und Tonalität, Accessibility-Standards, Content-Regeln (etwa „wir verwenden Sentence Case in Buttons“), Animationsprinzipien. Die nicht-komponentenbasierten Teile, die die Arbeit zusammenhalten.
Ein häufiges Scheitern: System ausliefern, dann fallen lassen
Die Hälfte der Design-Systeme, die wir in Kunden-Codebases sehen, wurde vor zwei Jahren gebaut, sechs Monate genutzt und dann still und leise umgangen. Symptome: ein Storybook, das niemand mehr pflegt, Komponenten im Code, die die Design-System-Komponenten überschatten, hartcodierte Hex-Farbwerte an 30 Stellen.
Das passiert meist, wenn das System als einmaliges Deliverable behandelt wird statt als lebendiges Produkt. Die Lösung ist strukturell:
- Bestimmen Sie einen Owner. Auch in Teilzeit. Ohne Owner entscheidet niemand, wann eine neue Komponente ins System aufgenommen wird.
- Machen Sie das System einfacher zu nutzen als zu umgehen. Wenn das Hinzufügen einer neuen Komponente zum System länger dauert, als sie einfach zu kopieren, haben Sie schon verloren.
- Führen Sie ein vierteljährliches Audit durch. Gehen Sie jeden Screen durch, zählen Sie die Abweichungen, beheben Sie sie. Wir nutzen eine einfache Kennzahl: „Prozentsatz der Screens, die ausschließlich System-Komponenten nutzen.“ Alles unter 80 % ist ein Problem.
Klein anfangen (und dranbleiben)
Sie brauchen keine 200-Komponenten-Bibliothek, damit es ein Design-System heißt. Eine funktionierende v1 passt in eine einzige Figma-Bibliothek und ein einziges npm-Paket und enthält grob:
- 8 Farb-Tokens
- 4 Typografie-Skalen
- Eine Abstandsskala (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 Komponenten: Button, Input, Select, Modal, Card, Table
- 3 Patterns: Formular-Layout, Page Header, Empty State
Das ist ein echtes Design-System. Am Freitag ausliefern, am Montag nutzen, im nächsten Jahr wachsen lassen.
Wann Sie keins brauchen
Ein Zweierteam, das sechs Monate lang an einem einzigen Produkt baut, liefert ohne den Overhead eines formalen Systems schneller. Der Break-even liegt ungefähr bei: drei oder mehr Designern/Entwicklern, mehreren Oberflächen oder einem Produkt, das voraussichtlich länger als 18 Monate lebt. Darunter reicht es, die Konventionen aufzuschreiben und weiterzumachen.
Darüber lautet die Frage nicht mehr „Sollten wir ein Design-System bauen?“, sondern „Wie viel haben wir schon dafür bezahlt, keins zu haben?“ Wenn Sie eine zweite Meinung dazu wollen, wo das System Ihres Teams steht: Unser UI/UX-Design-Team führt dafür als Einstieg ein schlankes Audit durch.
