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.

Die letzte Zeile ist diejenige, die man zweimal lesen sollte. Das Scheitern einer Komponenten-Library ist sichtbar: zwei Date-Picker, drei Button-Implementierungen, ein Bug in der einen gefixt, in der anderen nicht. Das Scheitern eines Designsystems ist von innen heraus unsichtbar: Alles ist konsistent, nichts ist falsch, und das Produkt könnte von jedem stammen.

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

Eine Library wird mit Standardwerten ausgeliefert. Diese Defaults sind zwangsläufig neutral. Sie müssen für tausende unterschiedliche Produkte funktionieren und kodieren daher die am wenigsten spezifische Version jeder Entscheidung. Wer sie installiert, übernimmt einen vollständigen Satz an Design-Entscheidungen, die explizit so gewählt wurden, dass sie niemanden stören.

Vor der Library hatte das Produkt kein System und wirkte inkonsistent. Danach besitzt es ein System – allerdings das eines anderen, optimiert für maximale Allgemeingültigkeit. Die Inkonsistenz ist behoben, aber ein Identitätsproblem wurde geschaffen. Da das zweite Problem keine Fehlermeldungen produziert, bleibt es lange Zeit unbenannt.

Dies ist kein Argument gegen Komponenten-Libraries. Es ist ein Argument dafür, dass die Installation einer solchen nur die Hälfte der Arbeit erledigt – und genau die Hälfte, die bereits sichtbar war.

Mehrere verwandte Begriffe werden oft synonym verwendet. Sie sind jedoch keine Synonyme, sondern beschreiben unterschiedliche Aspekte.

Ein Token-Set verdient besondere Aufmerksamkeit, da es das Artefakt ist, das am häufigsten mit einem gesamten System verwechselt wird. Eine Datei mit benannten Werten ist zwar absolut notwendig, sie sagt aber niemandem, wofür --color-primary verwendet werden darf. Genau diese Entscheidung bestimmt jedoch, ob die Oberfläche zurückhaltend wirkt oder wie ein beliebiges Template.

Vier Dinge, von denen keines in der API einer Komponente existieren kann und die alle darüber entscheiden, wie das Produkt aussieht.

1. 1

   Kompositionsregeln

   Wie Komponenten zusammenwirken. Eine primäre Aktion pro Sektion. Zusammengehörige Controls werden gruppiert, nicht zusammengehörige durch einen vollen Spacing-Schritt getrennt. Tabellen werden niemals in Cards verschachtelt. Eine Komponenten-Library hat keine Meinung dazu, was ihre Komponenten umgibt, dabei macht der Raum zwischen den Komponenten den Großteil eines Screens aus.

2. 2

   Dichte und Rhythmus

   Ob es sich um ein dichtes Tool oder eine luftige Marketing-Fläche handelt. Derselbe Button mit 8px Padding in einer Tabellenzeile und 16px in einem Hero-Bereich erzeugt zwei unterschiedliche Produkte. Die Library unterstützt beides, entscheidet sich aber für keines von beidem.

3. 3

   Motive

   Das wiederkehrende, spezifische Element, das das Design einzigartig macht: eine bestimmte Eckgestaltung, 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 Allzweck-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 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 einfachsten 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 deckt Zustände ab, für die die Bibliothek nur einen Slot vorgesehen 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. Der Agent füllt diese 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 nichts neu gebaut werden muss. Wenn eine Komponenten-Bibliothek und Tokens vorhanden sind, 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ß, aber 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.