Design Systems für kleine Teams: Wann es sich lohnt und wie du klein anfängst
Wann sich ein Design System für kleine Teams lohnt und wie du es in zwölf Wochen aufbaust: von der UI-Inventur über Design Tokens bis zu den ersten zehn Komponenten.
Der Button auf der Startseite hat abgerundete Ecken, der im Einstellungsdialog nicht. Das Formular im Onboarding nutzt ein anderes Grau als das im Kundenkonto. Und in jedem zweiten Review wird wieder diskutiert, wie groß der Abstand zwischen Label und Eingabefeld sein soll. Fast jedes Produkt sammelt mit der Zeit solche kleinen Abweichungen an.
Ein Design System soll genau das lösen. Viele kleine Teams schrecken aber davor zurück, weil sie an die Systeme großer Konzerne denken, mit eigener Website und eigenem Pflegeteam. Dieser Artikel zeigt, wann sich ein Design System für ein kleines Team lohnt und wie du es in überschaubaren Schritten aufbaust. Dazu begleitet er ein fiktives, aber typisches Team durch die ersten zwölf Wochen.
Design System, Styleguide, Komponentenbibliothek: Was ist was?
Die drei Begriffe werden oft durcheinandergeworfen, meinen aber Unterschiedliches. Ein Styleguide beschreibt das visuelle Erscheinungsbild: Farben, Schriften, Logo-Verwendung, oft auch Tonalität. Er sagt, wie etwas aussehen soll, setzt aber selbst nichts um.
Eine Komponentenbibliothek ist eine Sammlung wiederverwendbarer UI-Bausteine, also Buttons, Eingabefelder oder Dialoge. Sie kann in Figma liegen, im Code oder idealerweise an beiden Orten. Eine Bibliothek beantwortet die Frage „Was gibt es?“, aber nicht unbedingt „Was passt wann?“.
Ein Design System verbindet beides und ergänzt das, was die Zusammenarbeit trägt: gemeinsame Grundwerte (die sogenannten Design Tokens), Komponenten in Design und Code, Regeln für deren Einsatz und eine Vereinbarung, wie das Ganze gepflegt und weiterentwickelt wird.
Ein hilfreiches Denkmodell dafür ist Atomic Design von Brad Frost. Es zerlegt Oberflächen in Atome (etwa ein Label oder ein Eingabefeld), Moleküle (ein Suchfeld aus Label, Input und Button), Organismen (eine komplette Kopfzeile) sowie Templates und Seiten. Der Gedanke, von kleinen Bausteinen zu größeren Einheiten zu denken, passt gut zu einem schrittweisen Aufbau. Mehr dazu findest du im Artikel Was ist Atomic Design?
Woran du merkst, dass dein Team eins braucht
Nicht jedes Team braucht sofort ein Design System. Ein frühes Produkt, das sich noch jede Woche grundlegend ändert, profitiert oft mehr von schnellen Prototypen als von festen Regeln. Es gibt aber ein paar deutliche Signale, dass die Zeit reif ist.
Das erste Signal sind sichtbare Inkonsistenzen. Wenn du drei Screens nebeneinanderlegst und auf Anhieb verschiedene Buttonhöhen, Grautöne oder Fehlermeldungsstile findest, merken das auch die Nutzer:innen. Jede Abweichung wirft Fragen auf: Ist das klickbar? Gehört das zusammen?
Das zweite Signal sind wiederkehrende Diskussionen. Wenn im Team regelmäßig dieselben Fragen auftauchen, etwa wie ein deaktivierter Zustand aussieht oder ob Fehlermeldungen über oder unter dem Feld stehen, fehlt eine gemeinsame Quelle für solche Entscheidungen.
Das dritte Signal ist eine zähe Übergabe zwischen Design und Entwicklung. Wenn Entwickler:innen Abstände aus Figma abmessen, Farbwerte einzeln kopieren oder bei jedem neuen Feature nachfragen müssen, welche Variante gemeint ist, wird jede Übergabe zur Übersetzungsarbeit.
Wenn zwei dieser drei Signale zutreffen, lohnt sich der Einstieg in der Regel. Das Ziel ist dann konkret: weniger Abweichungen, kürzere Diskussionen, schnellere Übergaben.
Warum der Ansatz großer Unternehmen bei kleinen Teams scheitert
Große Organisationen bauen Design Systems oft als eigenes Produkt mit eigenem Team, eigener Roadmap und umfangreicher Dokumentationswebsite. Das ist dort sinnvoll, weil viele Produktteams dasselbe System nutzen. Für ein kleines Team passt das nicht.
Das Hauptproblem ist Kapazität. Sollen zwei Designer:innen nebenbei ein vollständiges System mit allen Zuständen und Dokumentationsseiten aufbauen, bleibt meist das System liegen. Übrig bleibt eine halbfertige Bibliothek, die niemand nutzt. Dazu kommt, dass große Systeme Situationen abdecken, die ein kleines Team gar nicht hat, etwa mehrere Marken oder viele Plattformen.
Der bessere Weg folgt dem Gedanken von Lean UX: kleine Schritte, schnell nutzbare Ergebnisse, regelmäßig überprüfen, was wirklich hilft. Ein Design System für ein kleines Team beginnt nicht mit einem Konzeptpapier, sondern mit dem, was im Produkt schon da ist.
Das Beispielteam: Ausgangslage
Stell dir ein Team vor, das eine SaaS-Anwendung zur Terminbuchung für Arztpraxen und Therapiezentren entwickelt. Zum Team gehören zwei Designer:innen, vier Entwickler:innen und eine produktverantwortliche Person. Das Produkt ist drei Jahre alt, hat rund vierzig Screens und ist in einem gängigen JavaScript-Framework gebaut. Die Figma-Datei mit „Komponenten“ ist eher eine Ablage für Kopien als eine gepflegte Bibliothek.
Das Team vereinbart, zwölf Wochen lang etwa einen Tag pro Woche in das System zu investieren. Je eine Person aus Design und Entwicklung übernimmt die Hauptverantwortung, alle anderen tragen bei, wenn sie ohnehin an den betroffenen Stellen arbeiten. Das ist der wichtigste Erfolgsfaktor: Das System entsteht parallel zur Produktarbeit, nicht stattdessen.
Woche 1 und 2: Inventur der bestehenden UI
Bevor das Team irgendetwas Neues gestaltet, schaut es sich an, was es schon gibt. Die Designer:innen machen Screenshots aller wichtigen Screens und schneiden die UI-Elemente aus. Buttons kommen auf ein Board, Eingabefelder auf ein anderes, Farben, Schriftgrößen und Abstände jeweils auf eigene Flächen. Parallel durchsucht eine Person aus der Entwicklung den Code nach fest eingetragenen Farb- und Pixelwerten.
Das Team findet elf verschiedene Blautöne, sieben Button-Varianten mit drei unterschiedlichen Höhen, fünf Eckenradien und Abstände in fast jedem denkbaren Pixelwert zwischen 3 und 40. Niemand hat das bewusst entschieden. Es ist über drei Jahre einfach passiert.
Die Inventur hat zwei Effekte. Erstens liefert sie die Grundlage für alle weiteren Entscheidungen, weil du siehst, welche Muster tatsächlich verwendet werden und welche nur einmal vorkommen. Zweitens überzeugt sie Skeptiker:innen besser als jede Präsentation.
Woche 3 und 4: Design Tokens zuerst
Design Tokens sind benannte Werte für die kleinsten Design-Entscheidungen: eine Farbe, eine Schriftgröße, ein Abstand, ein Radius. Statt #1D4ED8 schreibst du color-primary, statt 16 Pixel space-4. Ändert sich ein Wert, änderst du ihn an einer Stelle, und Design und Code ziehen nach.
Zwei Ebenen: Basis-Tokens und semantische Tokens
Bewährt hat sich eine Trennung in zwei Ebenen. Basis-Tokens beschreiben die verfügbare Palette, also zum Beispiel color-blue-600 oder color-gray-500. Semantische Tokens beschreiben, wofür ein Wert eingesetzt wird, etwa color-primary, color-text-muted oder color-border-strong. Semantische Tokens verweisen auf Basis-Tokens.
In Komponenten verwendet das Team ausschließlich semantische Tokens. Will es später den Primärton anpassen oder einen dunklen Modus ergänzen, ändert es nur die Zuordnung, nicht jede Komponente. Eine dritte Ebene mit komponentenspezifischen Tokens wie button-primary-background lohnt sich erst, wenn es dafür einen konkreten Bedarf gibt.
Die ersten Tokens des Beispielteams
Aus elf Blautönen werden drei Basiswerte, aus dem Wildwuchs an Abständen eine Skala auf Basis von 4 Pixeln. Die erste Version sieht so aus:
- Farbe:
color-primary(verweist aufcolor-blue-600,#1D4ED8),color-text(#111827),color-text-muted(#4B5563),color-border-strongfür Eingabefelder (#6B7280),color-danger(#B91C1C) undcolor-surface(Weiß). - Typografie: eine Schriftfamilie, vier Größen von
font-size-sm(14 px) bisfont-size-xl(24 px), zwei Schriftstärken (regulär und fett) und eine Zeilenhöhe für Fließtext. - Abstände:
space-1(4 px),space-2(8 px),space-3(12 px),space-4(16 px),space-6(24 px),space-8(32 px). - Radien:
radius-sm(4 px) für Eingabefelder und Buttons,radius-md(8 px) für Karten und Dialoge,radius-fullfür Pillen und Avatare.
Das sind gut zwanzig Tokens. Mehr braucht es zu Beginn nicht. Lücken werden später über den Änderungsprozess ergänzt. Die Namen lauten in Figma und im Code gleich und sind ohne Erklärung verständlich.
Bei der Auswahl der Farben prüft das Team direkt die Kontraste. Der bisher verbreitete hellere Blauton #3B82F6 erreicht mit weißer Schrift nur etwa 3,7:1 und liegt damit unter den 4,5:1, die die WCAG für normalen Text verlangen. Das dunklere #1D4ED8 kommt auf etwa 6,7:1. Ähnlich bei den Eingabefeldern: Ein sehr helles Grau als Rahmen hebt sich kaum vom Hintergrund ab. Für Ränder, die ein Bedienelement erkennbar machen, sehen die WCAG mindestens 3:1 vor, deshalb bekommt der Rahmen einen eigenen, kräftigeren Token.
Tokens in Figma und im Code synchron halten
In Figma bilden Variablen diese Werte ab. Es gibt sie für Farben, Zahlen, Texte und boolesche Werte, und über sogenannte Modes lassen sich verschiedene Kontexte wie Hell und Dunkel abbilden. Das Team legt je eine Sammlung für Basis- und semantische Tokens an, die semantischen Variablen verweisen auf die Basis-Variablen. Wer noch zwischen Werkzeugen schwankt, findet im Vergleich Sketch vs Figma in 2026 Orientierung.
Im Code landen die Tokens als CSS Custom Properties, also etwa --color-primary. Damit beide Seiten nicht auseinanderlaufen, legt das Team eine Datei fest, die als einzige Quelle gilt. Ein guter Kandidat dafür ist eine JSON-Datei im Format der Design Tokens Community Group (DTCG). Diese Community-Gruppe beim W3C hat im Oktober 2025 die erste stabile Version ihrer Spezifikation veröffentlicht. Sie beschreibt, wie Tokens mit $value und $type notiert werden und wie ein Token mit geschweiften Klammern auf einen anderen verweist, etwa {color.blue.600}. Ein offizieller W3C-Standard ist das nicht, aber ein herstellerneutrales Format.
Aus dieser Datei erzeugt ein Build-Schritt die CSS-Variablen, etwa mit einem Werkzeug wie Style Dictionary oder einem kleinen eigenen Skript. Den Abgleich mit Figma übernimmt ein Plugin oder ein Export. Wichtiger als das Werkzeug ist die Regel: Ein Token wird zuerst in der Quelldatei geändert und dann in beide Richtungen verteilt. Anfangs geht das auch manuell, solange es feste Verantwortliche gibt.
Am Ende der vierten Woche sind die häufigsten fest eingetragenen Werte ersetzt. Viele kleine Abweichungen sind verschwunden, ohne dass jemand einen Screen neu gestaltet hat. Genau deshalb kommen Tokens zuerst.
Woche 5 bis 8: Die ersten zehn Komponenten
Jetzt geht es an die Bausteine. Die Inventur zeigt, welche Komponenten am häufigsten vorkommen und am stärksten abweichen. Meist ergibt sich eine ähnliche Liste:
- Button (primär, sekundär, Text-Button)
- Link
- Eingabefeld mit Label, Hilfetext und Fehlermeldung
- Auswahlliste (Select)
- Checkbox und Radio-Button
- Karte (Card)
- Hinweisbox (Alert) für Info, Erfolg, Warnung und Fehler
- Dialog (Modal)
- Navigation
- Tabs oder eine einfache Seitenkopfzeile, je nach Produkt
Das Team baut nicht alle zehn gleichzeitig, sondern zwei bis drei pro Woche, und zwar dort, wo gerade ohnehin Produktarbeit ansteht. Steht ein neues Formular für die Patientenaufnahme an, entstehen Eingabefeld, Select und Checkbox genau dafür und werden sofort im echten Produkt getestet.
Bei den Varianten gilt: so wenig wie möglich. Der Button bekommt drei Varianten und zwei Größen, nicht sieben und vier. Jede Variante kostet Pflege in Design, Code und Dokumentation. Deshalb fragt das Team bei jeder neuen: Gibt es mindestens zwei konkrete Stellen im Produkt, die sie brauchen? Wenn nicht, wartet sie.
In Figma spiegelt jede Komponente die Struktur im Code: gleiche Namen, gleiche Eigenschaften, gleiche Varianten. Heißt eine Eigenschaft im Code variant mit den Werten primary, secondary und text, heißt sie in Figma genauso.
Barrierefreiheit gehört in die Komponente
Ein großer Vorteil eines Design Systems ist, dass du Barrierefreiheit einmal sauber löst und sie dann überall mitbekommst. Das klappt aber nur, wenn sie von Anfang an eingebaut ist.
Für das Beispielteam bedeutet das: Jeder interaktive Baustein bekommt einen sichtbaren Fokuszustand, definiert über einen eigenen Token wie color-focus-ring. Die WCAG verlangen, dass der Tastaturfokus sichtbar ist, und ein deutlicher Fokusring hilft allen, die mit Tastatur navigieren. Farbkontraste sind über die Tokens bereits geprüft. Fehlermeldungen im Eingabefeld werden nicht nur rot eingefärbt, sondern zusätzlich mit Text und Symbol gekennzeichnet und dem Feld programmatisch zugeordnet.
Wo es möglich ist, nutzt das Team native HTML-Elemente: ein echtes button-Element statt eines klickbaren div, ein echtes select, solange keine besonderen Anforderungen dagegen sprechen. Der Dialog erhält eine Fokusführung, die beim Öffnen in den Dialog springt, beim Schließen zum auslösenden Element zurückkehrt und sich mit der Escape-Taste schließen lässt. Klickflächen sind mindestens 24 mal 24 Pixel groß, was der Mindestanforderung der WCAG 2.2 entspricht. Jede Komponente wird vor der Freigabe einmal nur mit Tastatur und einmal mit Screenreader durchgespielt. Das dauert wenige Minuten und verhindert, dass ein Fehler später in vierzig Screens steckt.
Dokumentation: nur so viel wie nötig
Viele Design Systems scheitern an zu viel Dokumentation, nicht an zu wenig. Lange Beschreibungen veralten schnell und werden selten gelesen. Das Beispielteam nutzt deshalb eine kurze, feste Vorlage für jede Komponente. Sie liegt im Code-Repository als Markdown-Datei neben der Komponente, ein Link darauf steht in der Beschreibung der Figma-Komponente.
Die Vorlage hat fünf Abschnitte:
- Wofür: ein bis zwei Sätze, wann die Komponente eingesetzt wird.
- Varianten: welche es gibt und wann welche passt.
- Do: zwei bis drei Beispiele für den richtigen Einsatz, etwa „Pro Ansicht nur ein primärer Button“.
- Don’t: zwei bis drei typische Fehler, etwa „Keinen Text-Button für destruktive Aktionen wie Löschen“.
- Barrierefreiheit: was die Komponente bereits erledigt und was beim Einsatz noch zu beachten ist, etwa ein aussagekräftiger Linktext.
Mehr nicht. Entscheidend ist, dass die Dokumentation dort liegt, wo die Leute ohnehin arbeiten. Eine eigene Dokumentationswebsite lohnt sich erst, wenn mehrere Teams das System nutzen.
Für Tokens reicht eine Namensregel: Kategorie, Rolle, gegebenenfalls Zustand, also etwa color-text-muted oder color-primary-hover.
Woche 9 und 10: Governance light
Governance klingt nach Gremien und Freigabeschleifen, muss für ein kleines Team aber nur drei Fragen beantworten: Wer entscheidet? Wie kommt eine Änderung ins System? Woran erkennt man, was sich geändert hat?
Wer entscheidet
Im Beispielteam entscheiden die beiden Hauptverantwortlichen aus Design und Entwicklung gemeinsam. Sie sind keine Türsteher:innen, sondern Ansprechpersonen, die Doppelungen verhindern und das System übersichtlich halten. Die Rolle wechselt alle sechs Monate, damit Wissen nicht an einzelnen Personen hängt.
Wie eine Änderung abläuft
Ein Beispiel: Eine Entwicklerin baut eine Terminübersicht und braucht dafür einen Button mit Symbol ohne Text. Den gibt es im System noch nicht. Statt selbst einen zu bauen, legt sie im Ticketsystem einen Änderungswunsch an: Was wird gebraucht, wo wird es eingesetzt, gibt es bereits ähnliche Stellen im Produkt?
In der wöchentlichen, halbstündigen System-Runde gibt es drei mögliche Ergebnisse: Eine bestehende Komponente deckt den Fall schon ab. Oder der Bedarf taucht wahrscheinlich öfter auf, dann wird die Erweiterung gemeinsam gestaltet, umgesetzt und dokumentiert. Oder es ist ein Einzelfall, der bewusst lokal bleibt. Im Fall der Terminübersicht entscheidet sich das Team für einen Icon-Button als neue Variante, mit Pflicht für ein unsichtbares Label für Screenreader.
Dringende Fälle müssen nicht warten: Wer es eilig hat, baut lokal und meldet den Bedarf trotzdem. So blockiert das System nie die Produktarbeit.
Versionierung
Damit alle wissen, was sich ändert, versioniert das Team die Komponentenbibliothek nach dem Prinzip der semantischen Versionierung. Eine Fehlerbehebung erhöht die letzte Stelle (1.2.0 auf 1.2.1), eine neue Komponente oder Variante die mittlere (1.2.1 auf 1.3.0), eine nicht abwärtskompatible Änderung wie ein umbenannter Token die erste (1.3.0 auf 2.0.0). Zu jeder Version gibt es ein paar Sätze im Changelog. Bei Breaking Changes bleibt der alte Token für eine Übergangszeit als veraltet markiert bestehen. Das DTCG-Format sieht dafür sogar eine eigene Eigenschaft $deprecated vor.
Woche 11 und 12: Adoption messen
Ein Design System ist erst dann erfolgreich, wenn es genutzt wird. Das Team misst deshalb nach zwölf Wochen mit einfachen Mitteln, wie weit es gekommen ist.
Im Code zählt eine Person per Suche, wie viele fest eingetragene Farb- und Pixelwerte noch außerhalb der Token-Dateien stehen, und vergleicht die Zahl mit der Inventur. Eine Linter-Regel für CSS kann neue Hex-Werte außerhalb der Token-Dateien künftig direkt anmerken. Außerdem zählt das Team, wo die neuen Komponenten schon im Einsatz sind und wie viele alte Varianten noch existieren.
Auf der Design-Seite prüfen die Designer:innen, wie viele aktuelle Screens in Figma auf Bibliothekskomponenten basieren und an wie vielen Stellen Komponenten von der Bibliothek abgelöst wurden. Diese abgelösten Stellen zeigen, wo dem System etwas fehlt.
Mindestens genauso wichtig sind qualitative Signale. Das Team fragt in der Retrospektive: Sind Übergaben schneller geworden? Gibt es weniger Rückfragen zu Abständen und Farben? Tauchen die alten Grundsatzdiskussionen noch auf? Wenn ja, hat sich der Aufwand gelohnt, auch ohne vollständige Migration. Danach gilt: Wer einen Screen anfasst, stellt ihn auf das System um.
Typische Fehler und wie du sie wieder einfängst
Die folgenden Fehler sind in kleinen Teams häufig, lassen sich aber meist ohne Neustart korrigieren.
Bauen für das Regal
Das Team baut Komponenten, weil sie „in ein Design System gehören“, nicht weil das Produkt sie braucht. Zum Einfangen hilft eine einfache Regel: Neue Komponenten entstehen nur zusammen mit einem konkreten Feature. Was nach zwei Monaten nirgends im Einsatz ist, wird archiviert.
Zu viele Varianten
Jeder Sonderwunsch wird zur neuen Variante, bis der Button zwölf Ausprägungen hat und niemand mehr weiß, welche wann passt. Die Lösung ist ein Variantenaudit: alle Varianten auflisten, Nutzung zählen, selten genutzte zusammenführen oder entfernen. Danach gilt wieder die Regel mit den zwei konkreten Einsatzorten.
Keine Adoption
Das System existiert, aber die Entwickler:innen bauen weiter eigene Lösungen. Meist ist das System dann als reines Design-Projekt entstanden, oder die Komponenten sind im Alltag umständlich. Frag direkt nach den Gründen und beseitige zwei, drei konkrete Hürden. Oft sind es Kleinigkeiten wie fehlende Eigenschaften oder unklare Namen.
Tokens nach Aussehen benannt
Ein Token heißt color-blue-button und wird dann auch für Links und Icons verwendet. Zum Einfangen führst du semantische Tokens ein, lässt die alten als Verweise bestehen und markierst sie als veraltet. Nach ein bis zwei Versionen werden sie entfernt.
Die große Migration
Das Team beschließt, alle Screens auf einmal umzustellen, und blockiert damit wochenlang die Produktentwicklung. Besser ist der schrittweise Weg: zuerst Tokens im ganzen Produkt, dann Komponenten Screen für Screen, immer dort, wo gerade gearbeitet wird. Gerät eine große Migration ins Stocken, lohnt es sich, sie bewusst zu stoppen und auf diesen Weg umzuschwenken.
Checkliste für den Start
- Die drei Signale prüfen: Inkonsistenzen, wiederkehrende Diskussionen, zähe Übergaben.
- Je eine verantwortliche Person aus Design und Entwicklung benennen und feste Zeit einplanen.
- Inventur der bestehenden UI in höchstens zwei Wochen erstellen.
- Basis-Tokens und semantische Tokens für Farbe, Typografie, Abstände und Radien festlegen und Kontraste prüfen.
- Eine Token-Quelldatei definieren und Figma-Variablen sowie CSS-Variablen daraus ableiten.
- Die ersten rund zehn Komponenten entlang laufender Features bauen, mit Fokuszustand und Tastaturbedienung.
- Pro Komponente eine kurze Dokumentation mit Zweck, Varianten, Do, Don’t und Barrierefreiheit anlegen.
- Änderungsprozess, wöchentliche System-Runde und Versionierung vereinbaren.
- Nach zwölf Wochen Adoption messen und in der Retrospektive besprechen.
Fazit
Ein Design System ist für kleine Teams kein Luxus, wenn es klein beginnt und eng am Produkt bleibt. Statt eines großen Plans brauchst du eine ehrliche Inventur, eine Handvoll gut benannter Tokens und die Komponenten, die dein Produkt ohnehin am häufigsten nutzt. Barrierefreiheit gehört von Anfang an dazu, weil sie sich über das System automatisch verbreitet.
Nach zwölf Wochen hat das Beispielteam kein fertiges System, aber ein nützliches. Übergaben laufen schneller, und Diskussionen über Grautöne sind selten geworden. Genau das ist der Punkt: Ein Design System ist nie fertig, aber es kann ab der ersten Woche helfen.