Wie du als Freelancer oder Startup ein wartbares Design-System aufbaust, ohne dich an Konzern-Vorbildern zu verheben — mit Aufwand, Kosten und der Frage, wann du dir Hilfe holen solltest
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.
Dieser Artikel zeigt, wie du ein Design System entwickelst, das zu einem Team von zwei bis zehn Leuten passt: was es ist und was nicht, der Aufbau in fünf Schritten, die Werkzeuge, die häufigsten Fehler, was das Ganze an Zeit kostet — und woran du erkennst, ob du es allein baust oder dir Hilfe holst.
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.
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 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.
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.
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.
Beginne mit den minimalen Tokens, die du wirklich brauchst. Für ein typisches Startup-Produkt reichen anfangs:
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. Wie du die beiden größten Token-Gruppen im Detail herleitest, steht in eigenen Artikeln: Farbsysteme im Webdesign für die Palette bis hin zu semantischen Rollen, Typografie im Product Design für Skala und Zeilenhöhe. Und wenn ein zweites Farbschema dazukommen soll, zeigt Dark Mode richtig umsetzen, warum das nur mit Tokens sauber geht.
Die ersten Komponenten sind immer dieselben — und kein Zufall. Diese fünf decken in den meisten Produkten 80 % der Oberflächen ab:
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.
Patterns entstehen organisch. Sobald du dasselbe Problem zum dritten Mal löst, schreib auf, wie. Ein Login-Pattern, ein Empty-State-Pattern, ein Formular-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.
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".
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:
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.
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.
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.
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. Und ein Handoff, der Tokens statt Pixelwerte übergibt.
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.
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.
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.
Die Frage nach dem Aufwand kommt in jedem Erstgespräch, und die ehrliche Antwort ist: weniger, als die meisten befürchten — und mehr, als sich mit einem Sprint erledigen lässt. Für ein Produkt mit einer Handvoll Screens und einem Team von zwei bis fünf Leuten haben sich diese Größenordnungen bewährt:
Zusammen also grob vier bis zwölf Wochen Kalenderzeit, je nachdem, ob jemand das in Vollzeit macht oder neben dem Produkt. Ein bestehendes, verwildertes System aufzuräumen ist oft schneller als ein neues zu bauen, weil das Inventar dann meist schon zeigt, welche zwei von fünf Button-Varianten überleben.
Was den Aufwand nach oben treibt, ist fast nie die Zahl der Komponenten. Es sind drei Dinge: mehrere Plattformen (Web und native App gleichzeitig), ein Dark Mode ab Tag eins und ein Entwicklerteam, das erst überzeugt werden muss. Was ihn nach unten drückt: ein Team, das sich auf fünf Komponenten einigen kann, bevor es die sechste diskutiert.
Faustregel für die Budgetfrage: Wenn ein neues Feature heute länger als einen Tag braucht, nur weil Buttons, Inputs und Abstände jedes Mal neu entschieden werden, zahlt sich das System nach dem dritten Feature aus. Rechne das gegen die Personentage oben — meist ist die Antwort klar.
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:
prefers-reduced-motion-respektierende AnimationsklasseSeit 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.
KI-Tools verändern auch die Design-System-Arbeit, und zwar nicht nur als Marketing-Begriff. Drei sinnvolle Einsatzfelder aus der Praxis:
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."
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:
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.
Die meisten kleinen Teams können ein Design-System selbst aufbauen — wenn eine Person die Zeit dafür wirklich bekommt und nicht nur zugesprochen. Alles, was in diesem Artikel steht, reicht dafür als Anleitung. Es gibt aber drei Situationen, in denen sich externe Hilfe lohnt, und zwar nicht, weil das Team es nicht könnte, sondern weil es schneller und günstiger ist:
Sinnvoll ist dann meist kein Komplettauftrag, sondern ein Audit als Einstieg: In ein bis zwei Wochen entsteht das Inventar mit einer klaren Empfehlung, und danach entscheidet das Team, ob es den Aufbau allein macht oder begleitet. Genau so biete ich das an — die Phasen, Zeiträume und was am Ende in der Hand bleibt, stehen auf der Seite zur Design System Beratung.
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:
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.
Weiterlesen: Die beiden größten Token-Gruppen im Detail: Farbsysteme im Webdesign und Typografie im Product Design. Wie sich ein System auf Accessibility auswirkt, steht in Barrierefreiheit im UX-Design. Ein Beispiel aus der Praxis ist der Redesign-Case für PlusPublish.
Du willst ein Design-System aufbauen oder ein bestehendes aufräumen? Wie ich dabei vorgehe, steht unter Design System Beratung — oder schreib mir kurz, worum es geht.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Der Text wurde mit KI auf Rechtschreibung und Grammatik geprüft. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Design Systems
Von der Komponenten-Inventur bis zur Übergabe: Ich baue Design Systems, die Teams tatsächlich benutzen — Audit in zwei Wochen, Aufbau in vier bis zwölf.
Warum die Übergabe zwischen Design und Entwicklung kein Termin ist, sondern eine Arbeitsweise — und welche Artefakte im kleinen Team wirklich tragen
Warum Farbwahl im Product Design 2026 keine Bauchentscheidung mehr ist — und wie du semantische Farbrollen, Kontrast und Themes so aufbaust, dass Marke, UX und Barrierefreiheit gleichzeitig funktionieren
Warum Typografie in Web und App eine eigene Designdisziplin ist — und wie du Type-Systeme, Hierarchie und Lesbarkeit so aufbaust, dass sie Marke, UX und Performance gleichzeitig stärken
Du planst ein digitales Produkt, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.