Design System: ein Fundament für sieben Produkte

Ein Fundament für mehrere Produkte.

Rolle Product Designerin, federführend für das Design System · Scope Von der Agenturübergabe bis zur externen Barrierefreiheitsprüfung · Zeitraum 2021 bis 2026 · Umfang Rund 60 Komponenten, sieben Produkte und etliche Services, Designteam von vier Personen

Vertraulichkeit: Die interne Dokumentation und die reale Bibliothek kann ich nicht zeigen. Alle Abbildungen sind dafür neu erstellte, abstrahierte Darstellungen. Die Produktseite dieser Arbeit steht in einer eigenen Case Study: 3 Produkte, 1 Prozess.

Als ich anfing, gab es kein Designproblem, sondern ein Übersetzungsproblem. Eine Agentur hatte für das Redesign des Hauptprodukts schöne Konzeptscreens geliefert und eine Handvoll Basiskomponenten: zwei Buttons, eine Karte, eine Sidebar und einen Header. Damit lässt sich präsentieren, aber nichts bauen. Die Entwickler stellten immer mehr Fragen, auf die die Screens keine Antwort gaben. Was passiert beim Klick? Wie sieht das im Fehlerfall aus? Was, wenn der Text länger ist?

Genau dafür wurde ich eingestellt, als erste UI/UX-Designerin des Unternehmens.

Über fünfeinhalb Jahre ist daraus ein System für sieben Produkte und etliche Services geworden: rund 60 Komponenten, ein vollständiger Satz Fundamentals und rund ein Dutzend dokumentierter Patterns. Zeitweise habe ich an zwei bis drei Produkten gleichzeitig gearbeitet, was ständigen Kontextwechsel bedeutete und gleichzeitig der Grund war, warum ich als Einzige sehen konnte, wo dieselbe Frage in verschiedenen Produkten unterschiedlich beantwortet wurde.

Den Wechsel von Adobe XD auf Figma habe ich intern angestossen und über längere Zeit dafür geworben, danach den Neuaufbau der Bibliothek geführt. Das System hat diesen Toolwechsel überlebt und ist von einer Designerin auf ein Team von drei UI/UX-Designer:innen und einem UI/UX-Manager gewachsen.

Der Unterschied zwischen den Ebenen ist der Unterschied zwischen „wie sieht es aus" und „wann benutzt man es". Die zweite Frage kostet im Alltag mehr Zeit, deshalb hat sie den grösseren Teil der Dokumentation bekommen.

Die Bibliothek selbst ist nach Atomic Design aufgebaut, von kleinsten Bausteinen über zusammengesetzte Elemente bis zu fertigen Blöcken. Daraus ergeben sich zwei Rollen, die wir bewusst getrennt haben: Basisbausteine, aus denen sich Neues zusammensetzen lässt, und fertige Bausteine, die direkt einsetzbar sind. Für die Entwicklung war genau diese Trennung wichtig, weil sie die Frage beantwortet, ob man einen Fall selbst kombinieren soll oder ob es dafür bereits eine abgenommene Lösung gibt.

Fundamentals: Accessibility, Farbsystem, Layout, Elevation mit Schatten, Hover und Theming, Shapes, Typografie, Ikonografie, Motion, Writing.

Patterns: Buttons, Karten, Dialoge, Disabled States, Empty States, Icon States, Layout, Notifications, Tabellen, Tooltips, Upload, Textfelder, Formulare, Hochkontrastmodus.

Die folgenden drei Beispiele zeigen, wie im System entschieden wurde. Zu jeder Entscheidung gehört, was sie gekostet hat.

Entscheidung. Alle Elemente sind eckig, nur schwebende Elemente sind abgerundet.

Begründung. Unsere Oberflächen sind Werkzeuge, und visuelle Dichte hat Vorrang. Viele runde Formen hätten die Produkte weicher und in der Fläche unruhiger gemacht.

Der Preis. Weniger gestalterische Wärme, und eine Festlegung, die sich später nur mit hohem Aufwand ändern lässt.

Mit Ablaufdatum dokumentiert. In der Doku steht ausdrücklich, dass die Entscheidung für die aktuelle Produktlandschaft gilt und neu zu bewerten ist, falls die Produkte einmal in einer Anwendung zusammenlaufen. Eine festgehaltene Entscheidung ist nur hilfreich, wenn auch festgehalten ist, wovon sie abhängt.

Entscheidung. Vier Uploadmodi und Ergebnisdarstellungen, ausgewählt über den Anwendungsfall statt über den Geschmack.

Begründung. In einem Produkt will die Person nach dem Hochladen weiterarbeiten, in einem anderen sehen, dass es geklappt hat, und sofort etwas austauschen. Ohne Regel ist das in jedem Produkt anders gelöst worden.

Der Preis. Ein Pattern, das man lesen muss, bevor man die Komponente einsetzt.

Entscheidung. Wiederkehrende Fragen bekommen einen Entscheidungsbaum in der Dokumentation statt einer Regel im Fliesstext.

Begründung. Eine Regel muss man kennen, einen Baum kann man durchlaufen. Diskussionen, die früher eine halbe Stunde dauerten, waren damit oft in zwei Minuten erledigt.

Der Preis. Bäume veralten schneller als Prinzipien und müssen gepflegt werden.

Die schwierigste Entscheidung des Systems steckt in einem Zielkonflikt: Unsere Produkte sind mandantenfähig, die Kundenorganisationen wollen ihre eigenen Farben setzen, und genau das kann Kontraste zerstören, ohne dass es jemand merkt.

Die Lösung trennt konsequent zwischen variabel, nicht variabel und automatisch. Die Kundenorganisation wählt Primär- und Sekundärfarbe, Hintergrund und Flächen. Schriftstil und Ikonografie bleiben fest. Die Schriftfarbe wird aus der gewählten Farbe berechnet und auf Schwarz oder Weiss gesetzt, sodass Text unabhängig von der Kundenwahl lesbar bleibt.

Der schwierigste Teil war nicht die Idee, sondern ihre Vermittlung. Ein System, in dem sich eine Farbe aus einer anderen ergibt, ist für alle Beteiligten ungewohnt. Tragfähig wurde die Lösung erst durch Dokumentation und Beispiele, und sie ist dort entstanden, wo Design und Technik gemeinsam gerechnet haben.

Extern geprüft. Das Hauptprodukt wurde nach BITV 2.0 und WCAG 2.1 umgesetzt und von Project Alliance geprüft. Geprüft wurden Tastaturbedienung über die Tab-Navigation, Screenreader-Unterstützung, Kontraste sowie Verhalten bei Zoom und unterschiedlichen Bildschirmgrössen.

Für das System bedeutete das eine dauerhafte Arbeitsweise statt einer einmaligen Prüfung: sichtbar unterscheidbare Zustände, Fokuszustände als Teil der Definition und nicht der Umsetzung, und ein eigenes Pattern für einen Hochkontrastmodus. Der Zusammenhang zur Farblogik ist direkt. Ohne die berechnete Schriftfarbe hätte jede Kundenorganisation die Kontrastwerte unbeabsichtigt aushebeln können.

Das System hing an einer Kette, die vom Entwurf bis zur Prüfung durchlief. Jede Station hatte einen eigenen Zweck und eine eigene Zielgruppe.

Für die Umsetzung gab es eine technische Komponentenübersicht, in der die Bausteine abgebildet und immer aktuell waren. Darin schaut die Entwicklung im Alltag nach.

Für das Verständnis gab es Confluence, aufgebaut als eigener Bereich mit Grundlagen, Styleguide, Design Patterns, Komponenten und Anleitungen. Dort standen die Fundamentals im Detail, die Prinzipien, die Patterns, die Entscheidungsbäume und vor allem das Warum. Diese Ebene richtete sich an Stakeholder, Produktmanagement und Designteam, wurde aber auch von der Entwicklung gelesen.

Ein Format zieht sich durch fast alle Patterns: Do und Don't nebeneinander, mit einem echten Beispiel und einer Begründung. Nicht „so sieht es richtig aus", sondern „so sieht es falsch aus, und das passiert dann". Das hat mehr Fragen im Vorfeld abgefangen als jede Beschreibung.

Das System bedient zwei sehr unterschiedliche Welten: das dichte Werkzeug der Berater:innen und die reduzierte Ansicht der Kund:innen. Die Arbeitsweise war immer dieselbe. Zuerst die Beraterseite gestalten, weil dort die Funktionalität entsteht, dann fragen, was die Kundenseite davon wirklich braucht, und den Rest weglassen.

Das aufschlussreichste Ergebnis daraus: Für die Kundenansicht brauchte es keine eigenen Komponenten. Neue Anforderungen kamen ausnahmslos aus der Beraterperspektive. Die Kundenseite ist eine strenge Auswahl aus demselben Baukasten. Das war nicht geplant, es hat sich als Muster herausgestellt und die Pflege des Systems erheblich vereinfacht.

Wir haben eine eigene Ikonografie aufgebaut, und die Schwierigkeit lag nicht im Zeichnen. Icons, die einen Zustand anzeigen, müssen im ganzen System dasselbe bedeuten. Ob ein durchgestrichenes Auge heisst „der Inhalt ist verborgen" oder „klicke hier, um zu verbergen", ist keine Geschmacksfrage, sondern muss einmal entschieden und überall gleich gehalten werden. Für Sichtbarkeit, Sperren, Favorisieren und ähnliche Fälle haben wir festgelegt, welches Symbol welchen Zustand zeigt und welche Aktion ein Klick auslöst.

Solange ich allein gearbeitet habe, war das System ein Werkzeug. Mit dem Team wurde es eine Frage der Vermittlung. Neue Regeln habe ich vorgestellt und begründet, denn eine Regel, deren Grund niemand kennt, wird beim ersten Zeitdruck umgangen.

Beide neu dazugekommenen Designer:innen haben eigene Prinzipien und Patterns eingebracht, die wir gemeinsam geschärft und finalisiert haben. Ich habe ihre Arbeit am System gereviewt und den Feinschliff gemacht, weil ich als Einzige Designerin den Blick über alle Produkte und über das alte Komponentensystem hatte. Diese Verantwortung war ausdrücklich so gewollt: Mein Manager hat mir die fachliche Führung des Systems anvertraut.

Das System war nie fertig, und ich halte das für die interessantere Erkenntnis. Die Dokumentation lag auf zwei Plattformen, verlinkt, aber nicht zusammengeführt. Der Plan, daraus eine einzige Design-System-Seite zu machen, ist am Tagesgeschäft gescheitert.

Zwei Dinge würde ich heute anders machen. Erstens früher dokumentieren, auch schlecht. In der Anfangsphase existierten viele Prinzipien nur in meinem Kopf, und jede spätere Person musste sie neu erfragen. Zweitens das Farbkonzept von Anfang an gemeinsam mit der Technik entwickeln, statt es zu entwerfen und dann übersetzen zu lassen. Die tragfähige Lösung ist genau dort entstanden, wo beide Seiten zusammen gerechnet haben.

Ein Design System aufzubauen, das eine Person allein pflegt, ist eine Sache. Eines aufzubauen, das über fünfeinhalb Jahre mitwächst, einen Werkzeugwechsel überlebt, sieben Produkte trägt, zwei gegensätzliche Nutzergruppen bedient, fremdes Branding zulässt und dabei eine externe Barrierefreiheitsprüfung besteht, ist eine andere.

Ein Design System ist Infrastruktur. Wenn es gut ist, fällt es niemandem auf, und trotzdem hängt daran, wie schnell und wie verlässlich alle anderen arbeiten können. Die wertvollste Designarbeit ist oft die, die andere befähigt.