Design Systems für kleine Teams: Aufbau, Pflege und realistische Erwartungen

Warum kleine Teams ein anderes Design-System brauchen

Wer „Design System" hört, denkt zuerst an Carbon von IBM, Polaris von Shopify oder Material Design von Google. Hunderte Komponenten, eigene Dokumentations-Websites, ganze Teams nur für die Pflege. Für ein Startup mit drei Leuten oder ein Freelancer-Projekt wirkt das wie ein Schloss, in dem nie jemand wohnen wird.

Trotzdem braucht jedes Produkt — egal wie klein — ein Design-System. Die Frage ist nicht ob, sondern welches: wie groß, wie streng, wie dokumentiert. Ein gutes Design-System für kleine Teams unterscheidet sich grundlegend von einem Konzern-System. Es ist leichter, pragmatischer und akzeptiert, dass es nie „fertig" sein wird.

Ein Design-System ist kein Dokument, kein Figma-File und kein Storybook. Es ist die Übereinkunft eines Teams darüber, wie ihr Produkt aussieht, sich anfühlt und funktioniert. Alles andere sind nur Werkzeuge, um diese Übereinkunft sichtbar zu machen.

1. Was ein Design-System wirklich ist (und was nicht)

Die drei Schichten

Ein funktionierendes Design-System besteht aus drei Schichten, die oft verwechselt werden — und genau diese Verwechslung ist der häufigste Grund, warum kleine Teams an ihrem System scheitern.

• Tokens: Die kleinsten Bausteine — Farben, Schriftgrößen, Abstände, Radien, Schatten. Maschinenlesbar und plattformübergreifend nutzbar
• Komponenten: Konkrete UI-Elemente wie Buttons, Inputs, Cards, Modals — gebaut aus den Tokens
• Patterns: Wiederkehrende Lösungen für bestimmte Probleme — Login-Flows, Empty States, Onboarding-Sequenzen

Tokens sind die Grammatik, Komponenten das Vokabular, Patterns die Sätze. Wer mit Komponenten anfängt, ohne Tokens definiert zu haben, baut auf Sand. Wer Patterns dokumentiert, bevor die Komponenten stabil sind, dokumentiert Wackelbauten.

Was ein Design-System nicht ist

Genauso wichtig wie die Definition ist die Abgrenzung. Ein Design-System ist kein Style-Guide (der ist statisch und beschreibt nur Aussehen), kein Komponenten-Bibliothek allein (das ist nur die Code-Hälfte) und keine Dokumentation für ihrer selbst willen. Es ist das lebendige System, in dem Design-Entscheidungen getroffen, festgehalten und wiederverwendet werden.

Praxis-Tipp: Wenn dein „Design-System" hauptsächlich aus einer schönen Notion-Seite besteht, die niemand öffnet, ist es kein System — es ist ein Friedhof. Ein echtes System wird täglich benutzt, sonst ist es nicht eines.

2. Der pragmatische Aufbau in fünf Schritten

Schritt 1: Audit vor Architektur

Bevor du auch nur einen Token definierst, mach ein Interface-Inventar: Screenshot jeder existierenden Seite oder jedes Screens, alle Buttons nebeneinander, alle Schriftgrößen aufgelistet. Du wirst erschreckt sein, wie viele Varianten desselben Elements existieren — und genau das ist der Wert dieser Übung. Sie macht den Wildwuchs sichtbar.

Schritt 2: Tokens definieren — knapp und konkret

Beginne mit den minimalen Tokens, die du wirklich brauchst. Für ein typisches Startup-Produkt reichen anfangs:

• Farben: 1 Primärfarbe, 1 Akzentfarbe, 4–5 Grautöne, je 1 Farbe für Erfolg, Warnung, Fehler — fertig
• Typografie: 1–2 Schriftarten, 5–6 Größen-Stufen mit definierter Line-Height
• Spacing: Eine 4er- oder 8er-Skala (4, 8, 16, 24, 32, 48, 64) — keine Zwischenwerte
• Radien: 2–3 Werte (z. B. 4px, 8px, 16px) — kein Wildwuchs
• Schatten: 2–3 Stufen (subtil, mittel, prominent) — mehr verwirrt nur

Tokens werden zu früh überfeinert. Lieber mit zehn klaren Werten anfangen und bei Bedarf erweitern, als mit fünfzig Tokens, die niemand mehr im Kopf hat.

Schritt 3: Kern-Komponenten zuerst

Die ersten Komponenten sind immer dieselben — und kein Zufall. Diese fünf decken in den meisten Produkten 80 % der Oberflächen ab:

• Button — in 2–3 Varianten (Primary, Secondary, Ghost) und 2 Größen
• Input-Feld — mit Label, Hint-Text, Fehlerzustand
• Card — als Container für gruppierte Inhalte
• Navigation — Top-Bar, Tab-Bar oder Sidebar je nach Produkt
• Modal/Dialog — für fokussierte Interaktionen

Erst wenn diese fünf wirklich stabil und in jedem State (Default, Hover, Focus, Active, Disabled) durchdacht sind, lohnt es sich, an den nächsten Komponenten zu arbeiten.

Schritt 4: Patterns dokumentieren, sobald sie sich wiederholen

Patterns entstehen organisch. Sobald du dasselbe Problem zum dritten Mal löst, schreib auf, wie. Ein Login-Pattern, ein Empty-State-Pattern, ein Bestätigungs-Dialog-Pattern — solche Wiederholungen sind die wahren Kandidaten für Dokumentation. Vorher zu schreiben ist Theorie, danach zu schreiben ist Praxis.

Schritt 5: Pflege als Routine, nicht als Projekt

Das ist der Schritt, den 90 % aller kleinen Teams unterschätzen. Ein Design-System ist nie fertig - es lebt mit dem Produkt. Plane wöchentlich 30 Minuten für Wartung ein: neue Komponenten dokumentieren, alte aktualisieren, Inkonsistenzen aufräumen. Wer Pflege als Sonderprojekt einplant, wird sie nie machen.

Faustregel: Ein Design-System verdoppelt seinen Wert mit jeder Iteration und seinen Aufwand mit jedem ungepflegten Monat. Kleine, regelmäßige Pflege schlägt jedes große „Refactoring-Projekt".

3. Werkzeuge: Was kleine Teams wirklich brauchen

Figma als Single Source of Truth

Für die meisten kleinen Teams ist Figma mit Variables und Component-Properties die richtige Wahl. Variables ermöglichen echte Token-Definitionen (Farben, Spacings, sogar konditionale Werte für Dark Mode), Component-Properties machen Komponenten kompakt und nutzbar. Das war vor zwei Jahren noch nicht möglich — heute ist es Standard.

Eine sinnvolle Figma-Struktur:

• Library-File „Foundations": Tokens, Farben, Typografie, Spacing-Skala
• Library-File „Components": Wiederverwendbare Komponenten in allen States
• Library-File „Patterns": Beispiel-Screens für wiederkehrende Flows
• Project-Files: Konkrete Produkt-Designs, die aus den Libraries konsumieren

Dokumentation: Notion oder Zeroheight

Pure Figma reicht nicht — du brauchst einen Ort für Worte, Regeln und Do's & Don'ts. Für kleine Teams sind die schlanksten Optionen am besten: Notion (kostengünstig, flexibel, schon im Stack), Zeroheight (spezialisiert für Design-Systeme, integriert mit Figma) oder Storybook (wenn das Entwicklerteam ohnehin damit arbeitet). Keine eigene Doku-Website bauen, bevor das System nicht stabil ist.

Code-Seite: Tailwind oder CSS-Variables

Auf der Code-Seite gibt es zwei pragmatische Wege: Entweder Tailwind mit konfiguriertem Theme (dann sind deine Tokens direkt im Code verfügbar) oder CSS-Custom-Properties in einer zentralen Datei. Beides ist leichtgewichtig, beides synchronisierbar mit Figma-Variables — über Tools wie Tokens Studio oder Style Dictionary.

Anti-Tipp: Bau dir keine eigene Komponentenbibliothek mit React und Storybook auf, wenn dein Produkt nur drei Screens hat. Das ist Vorbereitung auf Wachstum, das vielleicht nie kommt — und blockiert Ressourcen, die im Produkt fehlen.

4. Die häufigsten Fehler kleiner Teams

Fehler 1: Das Über-System

Der häufigste Fehler ist, dass kleine Teams ein System bauen, das für eine 50-Personen-Organisation gedacht ist. Hundert Tokens, dreißig Komponenten, ausführliche Naming-Konventionen — und nichts davon wird benutzt, weil niemand es überblickt. Klein anfangen, organisch wachsen ist die einzige Strategie, die in der Praxis funktioniert.

Fehler 2: Das Zwei-Welten-System

Design und Code laufen auseinander. Im Figma-File steht ein 12px-Padding, im Code 14px. Im Figma-File ist die Primary-Farbe #0A8E85, im Code #0A9890. Solche Drift-Effekte schleichen sich unbemerkt ein und entwerten das System komplett. Die Lösung: regelmäßige Synchronisations-Checks — am besten automatisiert über Token-Pipelines.

Fehler 3: Komponenten ohne States

Eine Button-Komponente, die nur einen Default-Zustand hat, ist keine Komponente. Sie ist eine optische Illusion. Jede interaktive Komponente braucht mindestens fünf States: Default, Hover, Focus, Active, Disabled. Plus optional Loading und Error. Wer das im Design-System nicht definiert, definiert es später hundertmal im Produkt — inkonsistent.

Fehler 4: Naming aus dem Bauch

Tokens und Komponenten brauchen klare Namen, sonst wird das System unverständlich. Schlechte Namen: blue-1, blue-2, button-new, card-v3. Gute Namen beschreiben Funktion statt Aussehen: color-primary, color-text-secondary, button-primary, card-elevated. Wenn du die Primärfarbe morgen von Blau auf Grün änderst, soll der Name immer noch passen.

Fehler 5: Kein Owner

Auch in kleinen Teams braucht das Design-System einen klaren Verantwortlichen. Nicht zwingend eine Vollzeit-Rolle, aber eine Person, die Updates freigibt, Inkonsistenzen anspricht und das System zusammenhält. Ohne Owner zerfasert jedes System binnen Monaten in einen Wildwuchs.

5. Design-System und Accessibility: Der Multiplikator-Effekt

Ein Design-System ist der stärkste Hebel für Accessibility, den ein kleines Team hat. Wenn deine Button-Komponente einmal richtig gebaut ist — ausreichender Kontrast, sichtbarer Fokus-Ring, semantisches HTML, Screenreader-Label — multipliziert sich diese Qualität über jede Verwendung im Produkt. Umgekehrt verbreiten schlechte Defaults schlechte Barrierefreiheit über jeden Screen.

Konkret bedeutet das im Token-System:

• Kontrast-bewusste Farb-Tokens: Nicht nur „primary", sondern auch „on-primary" (welche Textfarbe auf Primärfläche funktioniert)
• Fokus-Token: Eine definierte Fokus-Farbe, die in allen interaktiven Komponenten konsistent eingesetzt wird
• Touch-Target-Mindestgrößen: Spacing-Tokens, die garantieren, dass interaktive Elemente nicht unter 44×44 Punkte fallen
• Motion-Token: Eine prefers-reduced-motion-respektierende Animationsklasse

Seit dem Barrierefreiheitsstärkungsgesetz (BFSG) ist Accessibility in Deutschland nicht mehr optional — und ein Design-System ist der effizienteste Weg, Compliance ins Produkt einzubauen, ohne jeden Screen einzeln zu prüfen. Wer tiefer einsteigen will, findet in meinem Artikel zu Barrierefreiheit im UX-Design eine ausführliche Einordnung der WCAG-Prinzipien und der konkreten Pflichten aus dem BFSG.

6. KI im Design-System-Prozess

KI-Tools verändern auch die Design-System-Arbeit, und zwar nicht nur als Marketing-Begriff. Drei sinnvolle Einsatzfelder aus der Praxis:

• Inventarisierung: Multimodale KI kann bestehende Screens auf Inkonsistenzen analysieren — „Hier sind drei Button-Varianten, die fast gleich aussehen — bewusst oder Drift?"
• Token-Vorschläge: Eine bestehende Marken-Welt beschreiben und KI nach passenden Spacing-Skalen, Farb-Verhältnissen oder Typo-Hierarchien fragen — als Sparring, nicht als Ersatz
• Dokumentations-Drafts: Komponenten-Dokumentation als Erst-Entwurf generieren lassen — und dann redigieren, statt vor leeren Notion-Seiten zu sitzen

Was KI nicht kann: Das eigentliche System-Denken. Welche Hierarchie für deine Marke richtig ist, welche Patterns deine Nutzer brauchen, welche Prinzipien dein Team gemeinsam tragen will — das bleibt menschliche Strategiearbeit. Eine breitere Einordnung, wo KI im UX-Workflow überhaupt sinnvoll greift, findest du in meinem Überblick zu KI-Tools im UX-Prozess sowie in der nüchternen Praxis-Bewertung von Claude Design im UX-Workflow.

Beispiel-Prompt für Inkonsistenz-Audit: „Hier sind Screenshots von zehn Buttons aus unserem Produkt. Liste alle visuellen Unterschiede (Größe, Padding, Radius, Farbe) auf und zeige mir, welche davon Drift sind und welche bewusst unterschiedlich sein könnten."

7. Wie du Stakeholder vom System überzeugst

Kleine Teams haben oft das Problem, dass ein Design-System als Luxus wahrgenommen wird — Zeit, die im Produkt fehlt. Die Argumentation muss dann konkret und wirtschaftlich sein:

• Geschwindigkeit: Neue Features entstehen aus existierenden Komponenten in Tagen statt Wochen
• Konsistenz: Weniger Bug-Reports zu „warum sieht das hier anders aus als dort"
• Onboarding neuer Teammitglieder: Ein klares System verkürzt die Einarbeitung dramatisch
• Skalierbarkeit: Wenn das Team wächst, gibt es schon eine gemeinsame Sprache
• Compliance-Vorbereitung: BFSG, DSGVO, Branchenstandards — alles einmal im System gelöst statt überall einzeln

Die ehrliche Argumentation: Ein Design-System ist eine Infrastruktur-Investition. Genau wie CI/CD, automatisierte Tests oder Logging zahlt es sich nicht in Woche eins aus, sondern in den Monaten danach — und exponentiell mit jedem Feature, das auf der Basis entsteht.

Fazit

Ein Design-System für ein kleines Team ist kein abgespecktes Konzern-System, sondern ein anders gedachtes Werkzeug: leichter, pragmatischer, organisch wachsend. Wer das versteht, baut sich ein Asset, das mit dem Produkt mitwächst. Wer den falschen Maßstab anlegt, baut sich eine Doku-Wüste, die niemand pflegt.

Die wichtigsten Takeaways:

• Drei Schichten klar trennen: Tokens, Komponenten, Patterns — jede mit eigener Logik
• Klein anfangen, organisch wachsen: Lieber zehn solide Tokens als fünfzig vergessene
• Pflege als Routine, nicht als Projekt: Wöchentliche 30 Minuten schlagen jedes Refactoring-Wochenende
• Naming nach Funktion, nicht nach Aussehen: „color-primary" statt „blue-3"
• Accessibility als Multiplikator: Im System gelöst, im ganzen Produkt gewonnen
• Owner definieren: Auch in kleinen Teams braucht das System eine klare Verantwortung
• KI als Sparring nutzen: Inventur, Drafts, Reviews — aber nicht als Strategieersatz

Ein gutes Design-System ist die unsichtbare Architektur eines Produkts. Es macht Designer schneller, Entwicklung sauberer und Nutzer-Erlebnisse konsistenter. Für kleine Teams gilt das besonders — denn sie können sich Inkonsistenz und Drift am wenigsten leisten.