Design System entwickeln,
das euer Team benutzt
Ich baue Design Systems für Produktteams, die keine Konzern-Abteilung dafür haben: Audit, Tokens, Komponenten in Figma und Code, Dokumentation und Übergabe. So schlank, dass es gepflegt wird — und so stabil, dass es trägt.
Das Problem
Drei Button-Varianten, die fast gleich aussehen. Ein Figma-File mit 14px Padding, ein Code mit 12px. Jedes neue Feature wird von Grund auf gestaltet, weil niemand weiß, was es schon gibt. Das Produkt wächst, die Konsistenz nicht — und jeder Onboarding-Tag eines neuen Teammitglieds beginnt mit „Wo finde ich …?".
Die Lösung
Ein Design System in der Größe, die zu eurem Team passt: wenige klare Tokens, die Kern-Komponenten in allen Zuständen, eine Dokumentation, die gelesen wird, und ein Pflegeprozess, der 30 Minuten pro Woche kostet statt ein Refactoring-Wochenende pro Quartal. Ich baue es mit euch, nicht für euch — damit es nach der Übergabe weiterlebt.
Wann sich Design System Beratung lohnt
Startups nach dem MVP
Das Produkt läuft, aber jeder Screen sieht ein bisschen anders aus. Bevor das dritte Feature-Team anfängt, braucht es eine gemeinsame Basis.
Mittelstand mit gewachsener Software
Eine Anwendung, die über Jahre entstanden ist, mit Dutzenden Varianten desselben Elements. Ein Audit zeigt, was konsolidiert werden kann — ohne Big-Bang-Relaunch.
Produktteams ohne Systems-Rolle
Ihr habt Designer und Entwickler, aber niemanden, der das System als Aufgabe hat. Ich baue es auf und übergebe es so, dass eine Person es nebenbei pflegen kann.
Design System aufbauen in vier Phasen
Je nach Ausgangslage vier bis zwölf Wochen. Jede Phase endet mit etwas, das ihr behalten könnt — auch wenn ihr danach allein weitermacht.
Audit & Inventar
Bevor ein Token definiert wird, wird sichtbar gemacht, was es schon gibt. Das Inventar ist meist ernüchternd — und genau deshalb die beste Argumentationshilfe für die Phasen danach.
- Interface-Inventar: alle Buttons, Inputs, Farben, Schriftgrößen nebeneinander
- Drift-Analyse zwischen Figma und Code
- Bewertung von Barrierefreiheit und Kontrast im Bestand
- Empfehlung: reparieren, konsolidieren oder neu aufsetzen
Fundament: Tokens & Prinzipien
Wenige, klar benannte Tokens für Farbe, Typografie, Abstand, Radius und Schatten — als Figma Variables und als Code-Variablen aus derselben Quelle.
- Farbsystem mit semantischen Rollen und geprüften Kontrasten
- Typo-Skala, Spacing-Skala, Radien, Elevation
- Naming nach Funktion, nicht nach Aussehen
- Optional: Dark Mode als zweites Token-Set
Komponenten & Patterns
Die Kern-Komponenten, die 80 % eurer Oberflächen abdecken — in jedem Zustand, in Figma und abgestimmt mit eurer Entwicklung. Patterns kommen dazu, sobald sie sich wiederholen.
- Button, Input, Card, Navigation, Dialog in allen States
- Figma-Komponenten mit Properties und Variables
- Abstimmung mit der Entwicklung: Tailwind-Theme oder CSS-Variablen
- Erste Patterns: Formular, Empty State, Tabelle, Bestätigung
Dokumentation & Übergabe
Ein System, das nur ich verstehe, ist keins. Am Ende steht eine Dokumentation, die gelesen wird, und ein Pflegeprozess, der in euren Alltag passt.
- Dokumentation in Notion, Zeroheight oder Storybook — was ihr schon nutzt
- Do’s & Don’ts pro Komponente statt Prosa
- Owner-Rolle und wöchentliche Pflege-Routine definiert
- Follow-up nach vier Wochen: Was hakt, was fehlt?
Woran ihr merkt, dass es hält
Die meisten Design Systems scheitern nicht am Aufbau, sondern an dem, was danach kommt. Vier Regeln, nach denen ich arbeite.
Klein anfangen
Zehn Tokens, die jeder kennt, schlagen fünfzig, die niemand findet. Das System wächst mit dem Produkt, nicht vorweg.
Eine Quelle
Figma Variables und Code-Variablen kommen aus derselben Definition. Drift ist der Anfang vom Ende jedes Systems.
Zugänglich ab Default
Kontrast, Fokus-Ring, Touch-Größe und Screenreader-Label sitzen in der Komponente — und multiplizieren sich über jedes Feature.
Übergabe ist Teil der Arbeit
Ich bin am Ende nicht mehr da. Deshalb gehören Owner, Routine und Dokumentation zum Auftrag, nicht zum Nachspann.
Was ihr am Ende in der Hand habt
- Ein Interface-Inventar mit klarer Konsolidierungs-Empfehlung
- Design Tokens als Figma Variables und als Code — aus einer Quelle
- Kern-Komponenten in allen Zuständen, in Figma und mit der Entwicklung abgestimmt
- Eine Dokumentation, die euer Team liest, plus Pflege-Routine mit Owner
- Barrierefreiheit, die in den Komponenten steckt, statt in jedem Screen einzeln geprüft wird
Wie ich über Design Systems denke
Design System entwickeln: Aufbau für kleine Teams
Fünf Schritte, die häufigsten Fehler und warum Pflege wichtiger ist als Vollständigkeit.
Lesen →TokensFarbsysteme im Webdesign
Von der Markenfarbe zu semantischen Tokens, States und Themes — mit Audit-Checkliste.
Lesen →TokensTypografie im Product Design
Skalen, Zeilenhöhe und Typo-Tokens, die Design-Datei und Code zusammenhalten.
Lesen →ÜbergabeDesign Handoff
Welche vier Artefakte die Übergabe braucht, damit aus Screens ein Produkt wird.
Lesen →Häufige Fragen zur Design System Beratung
Let's Work Together
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.