Designsystem vs. Komponenten-Library: Der Unterschied, der Geld kostet

Eine Komponenten-Library ist eine Sammlung wiederverwendbarer, codierter Interface-Teile mit definierten APIs. Ein Designsystem ist die Gesamtheit aller Entscheidungen, die das Aussehen und Verhalten eines Interfaces steuern – inklusive der Artefakte, die diese Entscheidungen kodieren, wovon eine in der Regel eine Komponenten-Library ist.

Das ist präzise, aber wenig hilfreich, da es nicht dabei hilft, das Vorhandene zu identifizieren. Hier ist ein Test, der das kann.

Die meisten Teams scheitern an diesem Test und sind überrascht, da die Komponenten-Library wie der schwierigste Teil wirkte. Sie war der teure Teil. Aber sie war nicht der Teil, der bestimmt, ob das Produkt eine eigene Identität besitzt.

Diese letzte Zeile ist diejenige, die man zweimal lesen sollte. Das Scheitern einer Component Library ist sichtbar – zwei verschiedene Datepicker, drei Button-Implementierungen, ein Bug, der in der einen, in der anderen aber nicht behoben wurde. Das Scheitern eines Designsystems ist von innen heraus unsichtbar: Alles ist konsistent, nichts ist falsch, und das Produkt könnte von jedem sein.

Hier kommt der kontraintuitive Teil: Die Einführung einer gut gemachten Component Library lässt ein Produkt manchmal *generischer* wirken, nicht weniger, und es lohnt sich, den Mechanismus dahinter zu verstehen, anstatt der Library die Schuld zu geben.

Eine Library wird mit Defaults ausgeliefert. Diese Defaults sind notwendigerweise neutral – sie müssen für Tausende von unzusammenhängenden Produkten funktionieren, daher kodieren sie die am wenigsten subjektive Version jeder Entscheidung. Installiert man sie, übernimmt man einen vollständigen Satz von Design-Entscheidungen, die gezielt darauf ausgelegt wurden, unauffällig zu sein.

Vor der Library hatte das Produkt kein System und wirkte inkonsistent. Danach hat es ein System, aber es gehört jemand anderem und ist auf maximale Allgemeingültigkeit getrimmt. Die Inkonsistenz ist behoben, aber das Identitätsproblem wurde geschaffen – und da das zweite Problem keine Fehler verursacht, bleibt es lange Zeit unbemerkt.

Dies ist kein Argument gegen Component Libraries. Es ist das Argument, dass die Installation einer Library nur die Hälfte der Arbeit erledigt – und die Hälfte, die sie erledigt, ist diejenige, die bereits sichtbar war.

Mehrere verwandte Begriffe werden synonym verwendet. Sie sind keine Synonyme; sie sind unterschiedliche Teilbereiche.

Ein Token-Set verdient besondere Aufmerksamkeit, da es das Artefakt ist, das am häufigsten mit einem vollständigen System verwechselt wird. Eine Datei mit benannten Werten ist zwar notwendig, sagt aber niemandem, wofür --color-primary verwendet werden darf – und genau das ist die Entscheidung, die bestimmt, ob die Benutzeroberfläche dezent wirkt oder wie eine thematisierte Vorlage.

Vier Dinge, von denen keines in der API einer Komponente leben kann und die alle bestimmen, wie das Produkt aussieht.

1. 1

   Kompositionsregeln

   Wie Komponenten zusammenwirken. Eine primäre Aktion pro Sektion. Verwandte Steuerelemente werden gruppiert, unverbundene durch einen vollständigen Spacing-Schritt getrennt. Tabellen werden niemals in Cards verschachtelt. Eine Component Library macht keine Angaben darüber, was ihre Komponenten umgibt, und der Platz zwischen den Komponenten nimmt den Großteil des Bildschirms ein.

2. 2

   Dichte und Rhythmus

   Ob es sich um ein kompaktes Tool oder eine großzügige Marketing-Oberfläche handelt. Derselbe Button mit 8px Padding in einer Tabellenzeile und 16px in einem Hero-Bereich erzeugt zwei verschiedene Produkte. Die Library unterstützt beide, entscheidet sich aber für keinen.

3. 3

   Motive

   Das wiederkehrende, spezifische Element, das das Design einzigartig macht – eine besondere Eckenabrundung, ein charakteristischer Einsatz von Trennlinien, eine konsistente Art und Weise, wie Diagramme gezeichnet werden. Motive sind der Unterschied zwischen „korrekt“ und „charakteristisch“, und sie finden in keiner Komponenten-API Platz.

4. 4

   Verbote

   Was niemals getan wird. Keine Verläufe. Keine Schatten-Elevation. Keine Schriftstärke über 600. Keine Farben außerhalb des Token-Sets. Eine Komponenten-Bibliothek kann nichts verbieten, denn Verbote sind genau das, was eine universelle Bibliothek nicht tun darf.

Der Punkt des Verbots generalisiert über das Design hinaus. Die Aufgabe einer Bibliothek ist es, für viele Produkte nutzbar zu sein, was bedeutet, alles Angemessene zu erlauben. Die Aufgabe eines Systems ist es, ein einzelnes Produkt kohärent zu machen, was erfordert, den Großteil davon auszuschließen. Sie sind strukturell gegensätzlich, weshalb das eine nicht das andere ersetzen kann.

Der Unterschied lässt sich am besten an einem einzelnen Primitiv erkennen. Eine Komponenten-Bibliothek bietet einen Button mit einer variant-Prop und hat keine Meinung dazu, wie eine Variante aussehen sollte. Ein System entscheidet dies – und die Entscheidung umfasst Zustände, für die die Bibliothek lediglich einen Slot bereitgestellt hat:

Die Unterscheidung war verschmerzbar, solange Menschen jeden Screen schrieben. Ein Entwickler, der die letzten zehn Screens gesehen hatte, übernahm die ungeschriebenen Konventionen und reproduzierte sie weitgehend. Das Designsystem existierte undokumentiert in den Köpfen der Menschen, und das funktionierte, solange die Leute im Team blieben.

Ein AI Coding-Agent besitzt kein solches Gedächtnis. Er liest, was im Repository steht, schreibt einen Screen und beginnt von vorn. Alles, was das Team wusste, aber nie aufgeschrieben hat, fehlt schlichtweg, und der Agent füllt die Lücke mit dem statistischen Durchschnitt von allem, was er gesehen hat – und das ist der Grund, warum KI-generierte Interfaces konvergieren und alle gleich aussehen.

Wir haben 299 DESIGN.md-Dateien analysiert, die speziell geschrieben wurden, um diese Lücke zu schließen. Die Zahlen zeigen, dass die meisten dies nicht tun: 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 76 % nennen keinerlei Verbote, 57 % definieren keine Motive, 69 % sagen nichts zum Dark Mode und 44 % enthalten an keiner Stelle einen konkreten Größenwert. 54 % verlassen sich auf mindestens ein vages Adjektiv, wobei „clean“ in 39 % und „modern“ in 36 % vorkommt.

Gelesen im Kontext der vier oben genannten Punkte, handelt es sich um einen Korpus von Dateien, die die Komponenten-Bibliothek dokumentieren und sie ein Designsystem nennen. Die Kompositionsregeln, die Entscheidung zur Dichte, die Motive und die Verbote fehlen größtenteils.

Die gute Nachricht ist, dass Sie nichts neu bauen müssen. Wenn Sie eine Komponenten-Bibliothek und Tokens haben, ist die Designsystem-Ebene ein Dokument, und es ist kurz.

## Intent

A dense tool for people who work in it for hours. Quiet, information-first.
Not a marketing surface: nothing here has to convince anyone of anything.

## Density

Controls: 8-12px padding. Table rows: 32px. Section gap: 32px.
Marketing surfaces run one step up on every value.

## Elevation

A surface step plus a 1px border. Never a box-shadow.

## Composition

One primary action per section. Related controls share a group;
unrelated ones are separated by a full spacing step.
Tables are never nested inside cards.

## Motifs

Section headings carry a 2px accent rule on the left edge.
Numeric columns are always tabular-nums, always right-aligned.

## Never

- No gradients
- No drop shadows
- No font-weight above 600
- No colour value outside the token set
- No border-radius above 12px

Dreißig Zeilen. Es enthält nichts, was Ihre Komponenten-Bibliothek bereits weiß, und alles, was ein neuer Engineer – oder ein Agent – benötigt, um einen Screen zu bauen, der zu Ihrem Produkt gehört und nicht zu den Standardwerten der Bibliothek.

Fast immer beides, aber die Reihenfolge hängt davon ab, wo der Schmerzpunkt liegt.