Was ist ein Designsystem und wie baut man es auf?

Kurz gesagt

Ein Designsystem ist ein gemeinsamer Baukasten, damit Ihr Team nicht jeden Screen neu zeichnet. Wie ein Button in welchem Zustand aussieht und unter welchem Namen er im Code aufgerufen wird, steht an einer einzigen Stelle.

Therese Fessenden von der Nielsen Norman Group definiert es so: ein vollständiger Satz von Standards aus wiederverwendbaren Komponenten und Mustern, um Design im großen Maßstab zu steuern. Ich sage es kürzer: dieselbe Entscheidung nicht zweimal treffen.

Das System ist keine Figma-Datei. Die Figma-Datei ist die Kopie des Systems auf der Designseite. Das eigentliche System sind die Komponenten, die im Code leben. Auch die Dokumentation dazu und die Menschen, die sie pflegen, gehören zum System.

• Meiner Meinung nach lohnt es sich auch für ein kleines Team, aber nicht in der ersten Woche. Der Nutzen zeigt sich, wenn das Produkt wächst.
• Die kleinste Einheit des Systems sind benannte Werte, die man Design Tokens nennt.

Designsystem, Styleguide und Komponentenbibliothek: der Unterschied

Styleguide, Komponentenbibliothek und Designsystem werden oft verwechselt. Der Grund: Die ersten beiden stecken im dritten. Laut NN/g enthält das Repository eines Designsystems meist einen Styleguide, eine Komponentenbibliothek und eine Musterbibliothek.

Teil	Was es beschreibt	Beispiel
Styleguide	Markenregeln, inhaltliche Richtlinien wie die Tonalität, visuelle und Interaktionsstandards.	„Überschriften in Bricolage Grotesque, Fließtext in Instrument Sans.“
Komponentenbibliothek	Einzelne Teile der Oberfläche. Jeder Eintrag hat Name, Beschreibung, Eigenschaften, Zustände samt Standard und ein Codebeispiel.	Button: primär, sekundär; normal, deaktiviert.
Musterbibliothek	Anordnungen und Vorlagen, in denen Komponenten zusammen eine Aufgabe lösen.	Adressformular, Screen mit leerer Liste.
Designsystem	All das, plus das Team und die Regeln, die es steuern.	Wann eine Komponente dazukommt, wer sie freigibt.

NN/g merkt an, dass die Begriffe Komponenten- und Musterbibliothek manchmal synonym verwendet werden. Trotzdem gibt es einen Unterschied. Eine Komponente ist ein einzelnes Teil, ein Muster ist die Art, wie Teile zusammenkommen.

NN/g betont noch einen Punkt: Das System ist so gut wie das Team, das es steuert. Eine Komponentenbibliothek ohne Verantwortlichen wird aus meiner Sicht mit der Zeit zu einem Archiv, dem niemand traut.

Wann braucht man es also? Laut NN/g schafft ein Designsystem den meisten Wert, wenn ein Unternehmen jahrelange, sich wiederholende Designarbeit erwartet. Für einen Proof of Concept oder einen frühen Prototyp zahlt sich ein vollständiges System kurzfristig sehr wahrscheinlich nicht aus.

Alles von Grund auf zu bauen, ist auch nicht der einzige Weg. NN/g nennt drei: ein fertiges System so übernehmen, wie es ist, es anpassen oder ein eigenes bauen. Übernehmen ist der billigste und schnellste Weg. Je mehr Sie anpassen, desto höher die Kosten, ein eigenes System kostet am meisten Zeit und Geld.

Schichten: Token, Komponente, Muster, Seite

Ein Designsystem in Schichten zu denken, macht sichtbar, was wovon abhängt. Ich nutze vier Schichten, und jede stützt sich nur auf die darunter.

1. Schicht 1TokenBenannte Werte: Farbe, Abstand, Schriftgröße, Eckenradius.--accent
2. Schicht 2KomponenteEin einzelnes Teil, das Tokens liest: Button, Badge, Formularfeld, Karte..btn--primary
3. Schicht 3MusterKomponenten, die zusammen eine Aufgabe lösen: Bezahlformular, leerer Zustand.Adressformular
4. Schicht 4SeiteDer Screen, auf dem Muster mit echtem Inhalt nebeneinander stehen./kasse

Abbildung: Jede Schicht nutzt nur die Schicht darunter. Ändert sich ein Token, wandert die Änderung nach oben in alle Seiten.

1. Token

Ein Token ist ein Name für einen Wert. Statt #FF6B3D schreiben Sie --accent. Das Formatdokument, das die Design Tokens Community Group im Oktober 2025 veröffentlicht hat, definiert einen Token als Paar aus mindestens einem Namen und einem Wert.

Dasselbe Dokument erlaubt auch, dass ein Token auf einen anderen Token zeigt. Das nennt man Alias. Der Token „Akzentfarbe“ zeigt zum Beispiel auf den Token „Orange 500“. Ändert sich die Markenfarbe, ändert sich eine Zeile. Die Arten von Tokens und das Dateiformat beschreibe ich gesondert im Glossareintrag zu Design Tokens.

2. Komponente

Eine Komponente ist ein Teil, das Tokens liest und eine einzige Aufgabe erfüllt: Button, Badge, Formularfeld. Eine gute Komponente kennt keine Rohfarbe, nur Tokens. Deshalb sieht sie auch in einem dunklen Bereich richtig aus.

Beim Entwerfen einer Komponente werden am leichtesten die Zustände vergessen. Dabei sieht der Nutzer den Button auch, wenn er im Fokus ist oder das System auf eine Antwort wartet. Jeder dieser Zustände gehört zur Komponente.

3. Muster

Ein Muster ist eine Verbindung von Komponenten, die eine Aufgabe des Nutzers löst. Ein Adressformular aus Label, Feld, Fehlermeldung und Button ist ein Beispiel. Die Regeln für Formulare habe ich im Muster Formulardesign gesammelt.

4. Seite

Auf der Seite kommen Muster mit echtem Inhalt zusammen. Hier zeigt sich auch, ob das System taugt. Ein langer Produktname oder eine leere Liste deckt Lücken im System sofort auf.

Brad Frosts Buch Atomic Design von 2016 schlägt ein ähnliches Modell vor: Atome, Moleküle, Organismen, Templates und Seiten. Frost schreibt, dass diese Stufen keine Schritte sind, die man nacheinander abarbeitet, sondern ein mentales Modell, das man zusammen denkt. Meine vier Schichten sind eine vereinfachte Form dieses Modells.

Ein Designsystem aufbauen: Schritt für Schritt

Ein System von Grund auf zu bauen, beginnt nicht wie ein großes Designprojekt. In Ihrem Produkt steckt schon ein verborgenes System, es ist nur unordentlich. Der erste Schritt ist, es sichtbar zu machen.

1. Erstellen Sie ein Inventar. Brad Frost nannte das 2013 ein Interface-Inventar (interface inventory): eine gesammelte Liste der Teile, aus denen das Produkt besteht. Von jeder Komponentenart machen Sie Screenshots und gruppieren sie auf einer Seite. Laut Frost geht es nicht darum, jedes Exemplar zu erfassen, sondern die unterschiedlich aussehenden Varianten zu sammeln.

2. Zeigen Sie die Inkonsistenzen. Ist das Inventar fertig, sehen Sie viele verschiedene Buttons nebeneinander, die dieselbe Aufgabe haben. Frost schreibt, dass es wichtig ist, bewusste von unbewussten Abweichungen zu trennen. Laut ihm hilft das Inventar auch, Vorgesetzte oder Kunden von einem System zu überzeugen.

3. Legen Sie die Tokens fest. Zählen Sie Farben, Schriftgrößen, Abstände und Eckenradien, und fassen Sie ähnliche zusammen. Schreiben Sie zuerst die Rohwerte (primitive Tokens), dann die Namen mit Bedeutung (semantische Tokens). Prüfen Sie in diesem Schritt auch den Kontrast. Dafür können Sie den Kontrastrechner nutzen.

4. Beginnen Sie mit der meistgenutzten Komponente. Bauen Sie nicht alle auf einmal. Das Inventar zeigt Ihnen, welches Teil sich am häufigsten wiederholt. Schreiben Sie für jedes Varianten und Zustände auf, dann programmieren Sie es.

5. Schreiben Sie die Dokumentation neben die Komponente. Laut NN/g enthält ein Eintrag in der Komponentenbibliothek Name, Beschreibung, Eigenschaften, Zustände und ein Codebeispiel. Ich ergänze eine Zeile: wann man sie nicht nutzt.

6. Regeln Sie die Governance von Anfang an. Wer fügt eine neue Komponente hinzu, wer gibt sie frei, wie wird eine alte entfernt? NN/g schreibt, dass das System ständige Pflege und Aufsicht braucht. Sonst veraltet es und zerfasert.

Zur Teamgröße hat NN/g eine Empfehlung: mindestens ein Interaktionsdesigner, ein visueller Designer und ein Entwickler. Gibt es diese Rollen im Unternehmen, kommen ins ideale Team noch eine Forscherin oder ein Forscher in Teilzeit, eine Architektur- und eine Content-Rolle hinzu. NN/g empfiehlt außerdem eine Führungskraft als Sponsor, die Geld und Ressourcen bereitstellt.

In einem kleinen Start-up liegen all diese Rollen bei ein oder zwei Personen. Das ist kein Problem. Wichtig ist, dass alle wissen, wem das System gehört.

Schieben Sie Barrierefreiheit beim Aufbau nicht nach hinten. Ist eine Komponente einmal richtig gebaut, funktioniert sie überall, wo sie genutzt wird. WCAG-Kriterien auf Komponentenebene zu testen, ist für mich billiger, als Seite für Seite zu korrigieren.

Funktioniert das System?

Am einfachsten sehen Sie, ob Ihr System trägt, wenn Sie beobachten, wie ein neuer Screen entsteht. Setzt das Design neue Screens überwiegend aus fertigen Teilen zusammen, funktioniert das System.

Das Gegenzeichen ist ebenso leicht zu sehen. Kopiert die Entwicklung eine Komponente und ändert sie, statt sie zu nutzen, deckt die Komponente einen Bedarf nicht ab. Lesen Sie das nicht als Fehler, sondern als Wunsch an das System.

Einmal im Monat suche ich im Code nach Rohfarben und Rohmaßen. Jeder Fund zeigt entweder einen fehlenden Token oder einen Screen, der aus dem System gefallen ist.

Von Figma zum Code

Ein Designsystem ist erst dann ein System, wenn es auch im Code mit denselben Namen lebt. Heißt ein Button in Figma „Primary/Large“ und im Code BigBlueButton, übersetzt das Team jeden Tag.

Figma baut diese Brücke mit Variablen (variables). Die Figma-Hilfe definiert Variablen als wiederverwendbare Werte, die man auf verschiedene Designeigenschaften anwenden kann. Dasselbe Dokument schreibt, dass Variablen und Modi genutzt werden können, um Design Tokens umzusetzen.

Modi lösen das Thema Themes. Sie geben einer Variablen pro Modus einen eigenen Wert, etwa für helles und dunkles Theme. Im Code entspricht das demselben Token-Namen, der in einem anderen Theme einen anderen Wert bekommt.

Mein Ablauf sieht so aus:

1. In Figma schreibe ich Token-Namen genauso wie im Code. color/accent wird im Code zu --accent.
2. Die Variantennamen der Komponente gleiche ich mit den Modifier-Namen im Code ab: in Figma „Primary“, im Code btn--primary.
3. Die Entwicklung kann im Dev Mode beim Inspizieren eines Elements auch auf Variablen zugreifen. Figma beschreibt das in einem eigenen Hilfeartikel.
4. Den Code mache ich zur einzigen Quelle der Wahrheit. Figma folgt dem Code, nicht umgekehrt.

Der letzte Punkt ist nicht jedermanns Wahl. Manche Teams nehmen Figma als Maßstab. Aber was beim Nutzer ankommt, ist der Code. Laufen Figma und Code auseinander, sieht der Nutzer immer den Code, deshalb nehme ich den Code als Maßstab.

Figma erlaubt auch, Variablen über die REST API zu lesen und zu schreiben. In der Dokumentation gibt es ein Beispiel für eine GitHub Action, die Variablen mit der Codebasis abgleicht. In kleinen Teams braucht man das oft nicht. Sind es nur eine Handvoll Tokens, reicht auch der Abgleich von Hand.

Ausprobieren: Mini-Komponentenset

Das Set unten besteht aus drei Komponenten: Button, Badge und Karte. Alle lesen dasselbe Token-Set. Wählen Sie eine Komponente, eine Variante und einen Zustand, dann sehen Sie, wie ein Eintrag in der Komponentenbibliothek zu lesen ist.

Ausprobieren: Mini-Komponentenset

Zur Kasse

Code: class="btn btn--primary"

Button, primär, normal. Für die Hauptaktion des Screens. Pro Screen gibt es einen primären Button, der Nutzer muss nicht suchen, was er drücken soll.

Im Normalzustand ist der Button bereit. Das Label sagt, was beim Drücken passiert.

Ein kleines Set aus den Komponenten dieser Website. Wählen Sie Komponente, Variante und Zustand: Vorschau, Codezeile und Nutzungshinweis ändern sich zusammen. Weil ein Badge nicht angeklickt wird, sind seine Zustände gesperrt.

Alle Nutzungshinweise aus der Demo stehen in der Tabelle unten. Jeder Eintrag in der Komponentenbibliothek sollte mindestens so viel sagen.

Komponente	Variante	Wann man sie nutzt
Button	Primär	Die Hauptaktion des Screens. Davon gibt es einen pro Screen.
Button	Sekundär	Die zweite Option neben der Hauptaktion. Wirkt ruhiger.
Button	Warnung	Schwer umkehrbare Aktion. Das Label sagt klar, was passiert.
Badge	Primär	Abgeschlossener oder positiver Zustand, etwa „Versendet“.
Badge	Sekundär	Neutrales Etikett, etwa „Entwurf“.
Badge	Warnung	Zustand, der einen Schritt vom Nutzer erwartet, etwa „Zahlung offen“.
Karte	Primär	Ein einzelnes hervorgehobenes Thema. Die Füllfarbe sorgt dafür, dass es zuerst gelesen wird.
Karte	Sekundär	Gewöhnlicher Eintrag in einer Liste.
Karte	Warnung	Inhalt, der einen Schritt vom Nutzer erwartet.

Zustände sind so wichtig wie Varianten. Der Fokusring zeigt Tastaturnutzern zum Beispiel, wo sie auf der Seite sind. Der Ladezustand verhindert einen zweiten Klick, damit dieselbe Anfrage nicht zweimal rausgeht.

Der ARIA-Leitfaden des W3C (APG) empfiehlt für Umschalt-Buttons mit den zwei Zuständen gedrückt und nicht gedrückt das Attribut aria-pressed. Laut Leitfaden soll sich das Label eines solchen Buttons nicht ändern, wenn sich der Zustand ändert. Die Auswahl-Buttons in der Demo halten sich daran.

Häufige Fehler

Das System für eine Bibliothek halten. Eine Figma-Datei oder ein npm-Paket zu veröffentlichen, heißt nicht, ein System zu bauen. Ist nicht klar, wer es pflegt, veraltet die Bibliothek mit der Zeit.

Zeichnen, ohne ein Inventar zu erstellen. Neue Komponenten, die ohne Blick auf das bestehende Produkt entstehen, fügen den alten Buttons nur einen weiteren hinzu. Zählen Sie zuerst, was da ist.

Nur den Normalzustand entwerfen. Werden Fokus, deaktiviert, Fehler und Laden nicht gezeichnet, erfindet die Entwicklung sie selbst. Auf jedem Screen erscheint ein anderes Ladezeichen.

Rohwerte in die Komponente schreiben. Steht im Button #FF6B3D, braucht ein dunkles Theme oder eine Markenänderung in jeder Komponente eine eigene Korrektur. Die Komponente sollte nur den semantischen Token lesen.

Tokens nach Farbe benennen. Ein Token namens --orange lügt, sobald die Marke lila wird. Semantische Tokens beschreiben die Funktion: --accent, --text-muted.

Aus jedem Wunsch eine Komponente machen. Was nur einmal auf einem einzigen Screen vorkommt, ist keine Komponente. Ein Teil nehme ich erst ins System auf, wenn es an mindestens zwei Stellen genutzt wird.

Die Dokumentation auf einer eigenen Website vergraben. Eine Doku-Seite, die niemand öffnet, ist so gut wie keine. Die Regel sollte direkt neben dem Code der Komponente stehen.

Farbe zum einzigen Hinweis machen. Ein rotes Badge allein sagt nicht „Es gibt ein Problem“. Wer Farben schlecht unterscheidet, liest den Text, und auch der Screenreader liest den Text. Nennen Sie den Zustand immer auch in Worten.

Meine Notiz

Auch die Seite, die Sie gerade lesen, ist mit einem Designsystem gebaut. Das System von ux.center besteht aus vier Schichten, und jede stützt sich nur auf die darunter: Tokens, Komponenten, Sektionen und Seite.

Die Tokens liegen in einer einzigen Datei in zwei Ebenen. Auf der ersten Ebene stehen Rohwerte, etwa Creme-, Tinten- und Orangetöne. Auf der zweiten stehen die semantischen Namen, die die Komponenten lesen: --bg, --text, --accent. Ein dunkler oder farbiger Bereich (Mood) ändert nur diese zweite Ebene.

Für Komponenten gilt eine einfache Regel: Jede Komponente hat eine CSS-Datei und eine Python-Funktion. Heute sind es 24 Komponentendateien, Button, Badge und Karte aus der Demo gehören dazu. Keine kennt eine Rohfarbe, deshalb funktionieren sie auch in einem dunklen Bereich.

Darauf bauen die Sektionen auf. Jede Sektion der Startseite bringt ihr eigenes Markup-Modul, ihre Stildatei und bei Bedarf ein Bewegungsskript mit. Das Build-Skript fasst alles der Reihe nach in einer CSS- und einer JS-Datei zusammen.

Am wertvollsten ist für mich ein Testwerkzeug. Vor und nach jeder Änderung, die das Aussehen nicht ändern soll, zeichne ich auf Desktop und Mobil Stil und Box jedes Elements auf. Erst wenn beide Aufzeichnungen genau gleich sind, gilt die Arbeit als fertig. Ein System zu erhalten, kostet mehr Mühe, als es zu bauen.

Wenn Sie ein solches System für Ihr Produkt bauen oder ein bestehendes in den Code bringen wollen, ist der Design & Ship Sprint genau dafür da. Design und Code liefere ich in Ihr Repository.