Ein Design System ist kein Komponentenkatalog

Viele Design Systems beginnen mit einer Bibliothek: Buttons, Inputs, Karten, alles sauber in Figma. Das Team ist stolz, die Dokumentation steht, und ein paar Monate später baut trotzdem jede Seite ihren eigenen Button.

Wir bauen seit Jahren Design Systems und sehen dieses Muster immer wieder. Das Problem ist selten die Qualität der Komponenten. Es ist die Frage, was das System eigentlich sein soll.

Ein Katalog beantwortet „Was gibt es?“

Ein Katalog zeigt, was vorhanden ist. Wer ihn nutzen will, muss suchen, vergleichen und entscheiden, ob das Gesuchte passt. Wenn das länger dauert, als es selbst zu bauen, wird selbst gebaut. Das ist keine Disziplinlosigkeit, sondern ein vernünftiger Schluss.

Ein System beantwortet „Wie machen wir das hier?“

Ein tragfähiges System nimmt Entscheidungen ab. Welcher Abstand gilt zwischen zwei Karten? Welche Farbe hat ein Fokusrahmen? Wie sieht ein Ladezustand aus? Wenn diese Antworten im System stehen und nicht in den Köpfen einzelner Personen, muss niemand mehr nachfragen.

Tokens zuerst, Komponenten danach

Am Anfang stehen die Entscheidungen, die die Marke schon getroffen hat: Farben, Schrift, Logo. Wir beginnen deshalb nicht mit Komponenten, sondern mit Tokens: Farben, Abstände, Radien, Schrift. Sie sind klein, eindeutig und in jeder Technik nutzbar. Eine Komponente ist dann im Kern eine Sammlung von Entscheidungen über Tokens. Ändert sich die Marke, ändert sich ein Token, und alles, was darauf aufbaut, zieht mit. Hardcodierte Werte im Code sind der Gegenbeweis: Jeder davon ist eine Entscheidung, die das System nicht kennt.

Regeln, die sich prüfen lassen

„Nutzt bitte immer die Tokens“ ist ein Wunsch. „Der Build schlägt fehl, wenn ein Hex-Wert im Code steht“ ist eine Regel. Wir glauben, dass ein System erst dann trägt, wenn die wichtigsten Regeln von Werkzeugen geprüft werden und nicht von Reviewern, die gerade andere Sorgen haben. Das spart Diskussionen und nimmt dem Thema das Persönliche.

Ausnahmen gehören dazu, aber sichtbar

Kein System passt auf jeden Fall. Entscheidend ist, wie mit Ausnahmen umgegangen wird. Bei uns stehen sie an einer Stelle, mit Grund. So wird aus einer Abweichung eine Entscheidung, über die man später sprechen kann, statt eines Fehlers, den niemand findet.

Für Menschen und für Agenten lesbar

Ein Punkt, der uns zunehmend wichtig wird: Das System wird nicht nur von Designerinnen und Entwicklern gelesen, sondern auch von Coding-Agenten. Ein Agent kann mit einer Regel in einer AGENTS.md, mit benannten Tokens und mit klaren Beispielen arbeiten. Mit einem Screenshot und dem Satz „sieht so ähnlich aus“ kann er es nicht. Wir glauben, dass gut dokumentierte Systeme dadurch einen Vorteil bekommen, den man beim Aufbau nur selten bedenkt.

Woran man merkt, dass es trägt

Drei Fragen, die wir uns bei einem System stellen:

1. Kann ein neues Teammitglied eine Seite bauen, ohne jemanden zu fragen?
2. Kann die Marke wechseln, ohne dass jemand Komponenten anfasst?
3. Fällt eine Abweichung auf, und steht sie mit Grund in der Liste der Ausnahmen?

Wenn zwei davon mit Nein beantwortet werden, ist es meist ein Katalog.

Und der Anfang?

Wer heute startet, muss nicht alles auf einmal bauen. Ein kleiner Satz an Tokens, drei bis vier Komponenten, die tatsächlich überall vorkommen, und eine Regel, die automatisch geprüft wird. Das ist weniger als ein Katalog und mehr als ein Styleguide. Es reicht, um zu merken, ob das Team es annimmt.

Wenn ihr wissen wollt, wie das bei uns aussieht: Mehr zu unserer Arbeit an Design Systems steht auf harwayexperience.com.

Quellen: Eigene Projekterfahrung bei HARWAY Experience und die eigene Arbeitsweise mit hex-ds (Tokens, Regeln, Ausnahmenliste). Keine externen Statistiken.

Verwandter Artikel: Das Design System als AI-Kontext-Layer.