Design-Guide statt Bauchgefühl: Wie ein Design-System Teams schneller macht

Jede neue Anwendung beginnt mit denselben Fragen: Welche Farbe hat der Button? Steht das Label über dem Eingabefeld oder darin? Wie sieht der Datepicker aus? Ohne Design-Guide beantwortet jedes Projekt diese Fragen neu – und am Ende sieht keine App aus wie die andere. Genau hier setzt ein Design-System an.

Vom Styleguide zum Product Design System

Angefangen hat es bei mir ganz klassisch: mit einem Styleguide für interne Business-Apps. Die ersten Screens, ein erstes Set an Komponenten und viele offene Fragen. Daraus ist Schritt für Schritt ein Product Design System in Figma gewachsen – eine gemeinsame Bibliothek, aus der Design und Entwicklung dieselben Bausteine ziehen.

Ein guter Design-Guide besteht für mich aus drei Ebenen:

• Fundamentals: Farben, Typografie und ein Layout-System mit Grid – die Basis, auf die sich alles andere stützt.
• Komponenten: Buttons, Eingabefelder, Dropdowns, Datepicker & Co. – jeweils mit allen Zuständen wie Default, Hover, Pressed und Disabled.
• Guidelines: Zu jeder Komponente eine Beschreibung mit Zuständen, Maßen, Verhalten und Einsatzregeln. Erst sie macht aus einer Sammlung schöner Screens ein System.

Kleine Entscheidungen, große Wirkung

Die spannendsten Diskussionen entstehen bei scheinbar kleinen Details. Ein paar Beispiele aus der Praxis:

• Die Pfeile im Datepicker: Nebeneinander oben rechts lassen sie sich schneller klicken, wenn man durch mehrere Monate springt. Links und rechts am Rand sind sie dagegen auf den ersten Blick intuitiver. Ein „Richtig“ gibt es nicht – aber es braucht eine Entscheidung, die dann überall gilt.
• Lesbarkeit vor Pixel-Treue: Einen Standard-Datepicker habe ich von 12 auf 14 Pixel Schriftgröße umgebaut. Die Tagesfelder wachsen dabei von 28 auf 32 Pixel, das ganze Element von 221 auf rund 256 Pixel Breite – ein bisschen mehr Platz, deutlich bessere Bedienbarkeit.
• Regeln bewusst brechen: Bei einem Split-Button habe ich das Hover-Padding von 16 auf 10 Pixel reduziert, weil der Hover-Effekt sonst bis an den Bildschirmrand gereicht hätte. Wichtig ist, solche Ausnahmen zu dokumentieren.
• Labels über dem Eingabefeld: Sie bleiben sichtbar, auch während man tippt. Den Platzhalter nutze ich dann nicht, um das Label zu wiederholen, sondern höchstens für ein Beispiel oder ein Format.

Farben so anlegen, dass neue Themes leicht bleiben

Eine der wichtigsten Grundsatzfragen lautet: Wie legt man Farben für die verschiedenen Zustände einer Komponente an? Ich habe zwei Wege gegenübergestellt:

1. Eine Grundfarbe plus Transparenz: Alle Button-Zustände referenzieren eine einzige Farbe, Hover und Disabled werden über die Deckkraft gesteuert. Das sind weniger Farbwerte – wer später anpasst, muss aber an zwei Stellen ran: an der Farbpalette und an der Hauptkomponente.
2. Eigene Farbwerte je Zustand: Active, Hover und Disabled bekommen jeweils einen eigenen Eintrag – für Hintergrund und Text. Das sind mehr Einträge, dafür lässt sich alles zentral in einer Farbpalette ändern.

Das Ziel ist in beiden Fällen dasselbe: möglichst wenig Aufwand, wenn die Komponenten an ein neues Farbtheme angepasst werden sollen. Dazu gehört auch, die Zielplattform mitzudenken. SharePoint arbeitet zum Beispiel standardmäßig mit 14 Pixel Schriftgröße, während viele Design-Systeme auf 16 Pixel (1 rem) und ein festes Grid setzen. Solche Unterschiede sollten früh geklärt werden – nicht erst, wenn die ersten Komponenten gebaut sind.

Ein Design-System ist ein Produkt – plane es auch so

Ein Design-System wird nie „fertig“. Deshalb behandle ich es wie ein eigenes Produkt:

• Backlog statt Zuruf: Alle Komponenten landen als Aufgaben auf einem Board.
• Realistisch planen: Für die ersten Komponenten – bei uns Eingabefelder und Buttons – haben wir die tatsächlich benötigte Zeit festgehalten. Daraus entsteht eine Timeline, die man auch halten kann.
• Feste Abstimmungstermine: Ein regelmäßiges Weekly für offene Fragen verhindert, dass Entscheidungen liegen bleiben.
• Wissen sammeln: Eine gemeinsame Linksammlung zu Benennung, Layout-Tipps und Best Practices hilft allen, die am System mitarbeiten.

Was es bringt

Der Effekt eines Styleguides zeigt sich schnell: Im Designteam fließt weniger Zeit in Grundsatzentscheidungen über Farben, Schriften und Komponenten. Neue Anforderungen lassen sich leichter umsetzen, weil das System mitwächst. Und für die Nutzer:innen entsteht ein konsistentes Erlebnis über alle Anwendungen hinweg – sie finden sich sofort zurecht.