Design mit System – Die Geburt des mittwald Design Systems

Wir schreiben das Jahr 2023. Das mStudio wird 1 Jahr alt und wir stellen fest: Unser erstes Design System hatten wir nie wirklich als richtiges Design System geplant. Es ist einfach gemeinsam mit dem mStudio gewachsen. Wir haben Komponenten entwickelt, sobald wir sie brauchten. Das funktionierte erstaunlich lange, brachte aber irgendwann immer mehr Probleme mit sich.

Keine Accessibility, keine gute Developer Experience, kaum Dokumentation. Einfach ein wilder Haufen an Komponenten, die nach Bedarf entstanden sind.

Also entschieden wir schnell: Wir brauchen ein neues durchdachtes Design System. Eines, das langfristig funktioniert, nachhaltiger ist und sowohl Designern als auch Entwicklern die Arbeit erleichtert. Das war die Geburtsstunde von flow. Doch wie sind wir dabei vorgegangen? In diesem Artikel werfen wir gemeinsam einen Blick auf die wichtigsten Learnings.

Bevor wir eintauchen, kurz zur Einordnung: Ein Design System ist die Grundlage, auf der ein Produkt gestaltet und gebaut wird. Es besteht aus wiederverwendbaren Komponenten (z. B. Buttons, Formularfeldern, Listen), aus grundlegenden Design-Entscheidungen wie Farben, Abständen und Schriftgrößen sowie aus Regeln und Dokumentation, die beschreiben, wann und wie man das alles einsetzt.

Designer und Entwickler arbeiten mit denselben Bausteinen und sprechen dabei dieselbe Sprache. Features müssen dadurch nicht jedes Mal neu gestaltet, sondern können aus geprüften, barrierefreien und konsistenten Komponenten zusammengesetzt werden. Das spart Zeit, sorgt für ein stimmiges Gesamtbild und macht Änderungen einfacher, weil sie zentral umgesetzt werden können.

Im ersten Schritt haben wir ein klassisches Reverse Engineering durchgeführt. Was machen andere Design Systeme? Wie lösen sie bestimmte Probleme und vor allem: Warum genau so?

Dafür haben wir uns intensiv mit etablierten Design Systemen beschäftigt und dabei vor allem 4 Fragen gestellt:

• Welche Komponenten sind essenziell? Welche Bausteine tauchen in fast jedem Design System auf und gehören damit auch bei uns zur Grundlage?
• Welche Varianten braucht eine Komponente wirklich? Zum Beispiel bei Buttons: Wann braucht es unterschiedliche Ausprägungen und welchen Zweck erfüllen sie?
• Wie ist das Fundament aufgebaut? Wie gehen andere Systeme mit Farben, Abständen und Typografie um? Daraus ist unter anderem unsere Token-Struktur entstanden.
• Wie wird Wissen vermittelt? Wie erklären andere, wann eine Komponente eingesetzt werden soll und warum?

Aus diesen Erkenntnissen haben wir unsere Anforderungen an flow abgeleitet: eine klare Token-Struktur, essenzielle Komponenten mit sinnvollen Varianten und eine Dokumentation, die nicht nur das Wie, sondern auch das Wann und Warum erklärt.

Und genau deshalb ist Reverse Engineering bis heute ein wichtiger Teil unserer Arbeit. Wir übernehmen nicht einfach, was andere machen. Wir versuchen zu verstehen, welches Problem dahintersteckt und warum eine Lösung funktioniert. Erst dann entscheiden wir, ob sie auch zu flow passt.

Einen Button wird niemand neu erfinden. Man kann ihn höchstens schlechter machen, weil man Dinge wie Barrierefreiheit, Tastaturbedienung oder ARIA-Attribute vergisst.

Deshalb setzen wir auf sogenannte Headless-Komponenten. „Headless" bedeutet, dass die Komponenten zunächst komplett ohne Design kommen. Sie bringen nur die Funktionalität und das Verhalten mit. Das eigentliche Aussehen legen wir später darüber. Dadurch bleibt das Design flexibel und kann jederzeit angepasst werden.

Konkret haben wir uns bewusst für React Aria entschieden. Es wird von Adobe entwickelt und gepflegt, legt großen Wert auf Barrierefreiheit und ist seit Jahren in großen Anwendungen im Einsatz. Im Gegensatz zu vielen klassischen UI-Bibliotheken gibt uns React Aria die volle Kontrolle über Markup, Struktur und Styling, während Interaktionslogik und Barrierefreiheit bereits umgesetzt sind. Genau diese Freiheit war für uns entscheidend, weil unser Design System auf möglichst kleinen, kombinierbaren Bausteinen aufbauen sollte.

Eine gemeinsame Sprache zwischen Design und Entwicklung ist einer der wichtigsten Bausteine eines Projekts. Erst wenn beide Seiten über dieselben Begriffe sprechen, entsteht ein gemeinsames Verständnis.

Design Tokens übersetzen grundlegende Designentscheidungen wie Farben, Abstände oder Schriftgrößen in genau diese gemeinsame Sprache. Ein Token besteht dabei aus 2 Teilen: einem Namen und einem Wert. Statt überall einen konkreten Hexwert zu verwenden, bekommt eine Farbe so zum Beispiel einen sprechenden Namen.

Der Wert eines Tokens kann aber nicht nur eine Farbe oder ein Abstand sein, sondern auch ein anderer Token. So lässt sich eine Struktur mit mehreren Abstraktionsebenen aufbauen. Die Global Tokens bilden als reine Rohwerte unsere Grundpalette. Sie vererben sich weiter in die Alias Tokens, die den Werten eine Bedeutung geben. Aus “Hosting Blue” wird die “Primärfarbe”, dabei verweisen wir immer nur, statt Werte fest zu hinterlegen. Weitere Alias-Ebenen ordnen die Werte konkreten Varianten wie Solid oder Outlined zu und sorgen dafür, dass Farben harmonieren und barrierefrei lesbar bleiben. Ganz oben treffen schließlich die Component Specific Tokens Entscheidungen, die nur für eine einzelne Komponente gelten.

Damit die Namen dabei selbsterklärend bleiben, folgt jeder Token einem dreistufigen Schema von allgemein zu spezifisch: Context, Common Unit und Clarification.

• Context– die grobe Einordnung: Worum geht es überhaupt? Das kann eine Farbfamilie sein (hosting-blue), eine Bedeutungsebene (primary) oder eine konkrete Komponente (alert).
• Common Unit – die Kategorie innerhalb des Contexts: Welche Eigenschaft ist gemeint? Zum Beispiel eine Variante (solid, outline), ein Sizing oder ein Styling-Aspekt wie solid-background-color oder info-outline-border-color.
• Clarification – die feinste Spezifizierung: der konkrete Wert oder Zustand. Das kann eine numerische Abstufung sein (800) oder ein State wie default, hover oder disabled.

Am Beispiel alert--info-outline-border-color--default ist alert der Context, info-outline-border-color die Common Unit und default die Clarification. So lässt sich der Verwendungszweck fast wie ein Satz ablesen, ohne den Code zu kennen: "Die Rahmenfarbe der Info-Outline-Variante einer Alert-Komponente im Normalzustand."

Durch Design Tokens ist flow deutlich wartbarer geworden und unterstützt Designer und Entwickler dabei, Komponenten gemeinsam zu entwickeln. Sie helfen, ein Design in klare Muster herunterzubrechen und diese direkt im Code abbildbar zu machen.

Große Komponenten, die alles können sollen, klingen im ersten Moment praktisch. In der Realität werden sie aber schnell kompliziert und schwer wartbar. Das war auch eines der größten Learnings aus unserem alten Design System: Viele Komponenten waren auf einen einzigen Anwendungsfall zugeschnitten und außerhalb dieses Kontexts kaum wiederverwendbar.

Unser Ziel war deshalb, möglichst kleine, modulare Komponenten zu bauen, die sich flexibel miteinander kombinieren lassen. So wächst flow Stück für Stück aus seinen eigenen Bausteinen heraus.

Richtig mächtig wird dieser Ansatz aber erst durch einen zweiten Gedanken: Komponenten sollten ihren Kontext verstehen und sich entsprechend selbst anordnen. Statt bei jeder Verwendung zahlreiche Einstellungen vornehmen zu müssen, erkennt eine Komponente, in welcher Umgebung sie eingesetzt wird, und passt Aussehen und Verhalten automatisch an.

Ein gutes Beispiel ist unsere IllustratedMessage, die Komponente, mit der wir etwa leere Zustände oder Hinweise darstellen. Setzt man ein Icon hinein, muss man ihm nicht manuell sagen, dass es jetzt groß und in einer passenden Farbe erscheinen soll. Das Icon erkennt selbst, dass es sich innerhalb einer IllustratedMessage befindet, und ordnet sich entsprechend an: größere Darstellung, passende Einfärbung, korrekter Abstand.

Technisch lösen wir das über React Context. Eine übergeordnete Komponente stellt Informationen über ihren Kontext bereit, die enthaltenen Komponenten lesen diesen aus und reagieren darauf.

Das Ergebnis sind Komponenten, die sich zusammenstecken lassen und trotzdem in jedem Kontext das Richtige tun, ohne dass man als Entwickler jede Kombination von Hand konfigurieren muss.

Dokumentation macht selten Spaß. Trotzdem gehört sie zu den wichtigsten Bestandteilen eines Design Systems. Dabei geht es nicht nur darum zu erklären, wie eine Komponente verwendet wird, sondern auch warum wir bestimmte Entscheidungen getroffen haben.

Deshalb halten wir wichtige Architektur- und Design-Entscheidungen direkt in GitHub-Issues fest. So lässt sich auch Monate später noch nachvollziehen, warum wir einen bestimmten Weg gewählt haben, statt dieselben Diskussionen immer wieder von vorne zu beginnen.

Für die eigentliche Nutzung der Komponenten setzen wir auf einen Styleguide. Dort beschreiben wir, welche Varianten es gibt, wann sie eingesetzt werden sollten und welche Gestaltungsprinzipien dahinterstehen. Das sorgt dafür, dass Komponenten nicht nur technisch wiederverwendbar sind, sondern auch konsistent eingesetzt werden.

Wir haben unser Design System auf GitHub veröffentlicht: github.com/mittwald/flow. Dort dokumentieren wir nicht nur Entscheidungen, sondern pflegen auch unsere Roadmap. So können alle Nutzer des Design Systems jederzeit sehen, woran wir arbeiten, neue Ideen einbringen oder bestehende Entscheidungen hinterfragen.

Am Ende ist ein Design System kein fertiges Produkt, das irgendwann abgeschlossen ist. Es lebt davon, dass Menschen es nutzen, hinterfragen und gemeinsam weiterentwickeln.

Mit der Version flow 1.0 erreichen wir einen wichtigen Meilenstein. Für uns bedeutet die Version 1.0 vor allem eines: Stabilität. Das Design System ist nicht mehr nur eine Sammlung von Komponenten, sondern eine verlässliche Grundlage für die tägliche Arbeit. Nutzer des Design Systems sollen darauf vertrauen können, dass Komponenten langfristig bestehen bleiben und sich nicht unerwartet verändern.

Dafür haben wir klare Regeln für den Lebenszyklus von Komponenten entwickelt und uns intensiv mit Versionierung und Abwärtskompatibilität beschäftigt.

Trotzdem ist ein Design System nie wirklich fertig. Es entwickelt sich mit jedem Feature, jeder neuen Komponente und vor allem durch das Feedback der Menschen weiter, die täglich damit arbeiten. Die Version 1.0 ist deshalb nicht das Ende unserer Arbeit, sondern der Beginn einer neuen Phase: einer stabilen Basis, auf der wir gemeinsam weiterbauen können.

Schau gern selbst vorbei – in der Dokumentation unter flow.mittwald.de.