Multibrand Designsystem für Whitelabeling
Projekt/ Produkt:
Account based Ticketing Whitelabel App
Ziel:
Anpassung des Designsystems an das Geschäftsmodell
Teamzusammensetzung:
UX Designerin, 2 Android Developer, 1 iOS Developer, 2 Projektmanager, später auch 1 Product Owner
Rolle:
Konzeptionelle UX-Leitung (faktisch übernommen) – duale Studentin
Schwerpunkt 1: System-Architektur
Kontext
Ich war als einzige UX-Designerin verantwortlich für die Konzeption und den vollständigen Aufbau eines Multibrand Designsystems und Designs einer Whitelabel Account based Ticketing App die auch nativ entwickelt wurde. Account based Ticketing ist ein modernes, digitales Fahrsystem, das darauf basiert ,dass die Fahrkarte nicht mehr auf einem physischen Medium (Papier/Karte)gespeichert wird, sondern in einem zentralen digitalen Konto. Funktionen wurden von Kunden trotz übergreifender Inhalte häufig als Einzelwünsche aufgeführt. Das Team für die Überarbeitung bestand aus mir und einem Android-Entwickler. Als Basis lag bereits ein Standard Designsystem vor, welches auf Ressourcenknappheit, wechselnde Kundenanforderungen sowie verschiedene Markenidentitäten angepasst werden musste.
Account Based Ticketing Grundprinzip
Herausforderung
Das Ziel war, das bestehende Designsystem so zu restrukturieren, dass es modular, theming-fähig und langfristig wartbar ist.
Es sollte sowohl unterschiedliche Marken visuell abbilden als auch Konsistenz und Wiederverwendbarkeit über die gemeinsame Basis der Projekte hinweg sichern. Damit sollte das System unterstützend zum Geschäftsmodell (Ausschreibungs & Serviceleistung) beitragen.
Vorgehen
Ich begann mit einer Bestandsanalyse aller bestehenden Komponenten und Styles in Figma. Durch Workshops und Mapping-Sessions identifizierten wir Prinzipien für das Designsystem. Das war wichtig, da ohne gemeinsame Prinzipien jeder sonst seine eigenen Interpretationen hätte einfließen lassen.
Designsystem-Prinzipien Workshop
Das System wurde in modulare Bausteine gegliedert, die sich über Variablen thematisch anpassen ließen. Parallel führte ich regelmäßige Design-Dev-Meetings ein, um Übergaben zu vereinfachen und Missverständnisse frühzeitig aufzulösen. Um den Aufwand bei kundenspezifischen Anpassungen zu reduzieren, analysierte ich das bestehende System und identifizierte redundante Token-Strukturen. Mein Ziel war, ein flexibles Fundament zu schaffen, das sowohl Geschäftsmodell und Designsystem in Einklang miteinander bringt.
Sign in Bereich Marta (Atlanta) und OCTA (Orange County) Text im System sind Platzhalter, die originalen Brand Texte wurden mit Localize gemanaged.
Ich entschied mich bewusst für eine modulare Systemlogik statt schneller Einzelanpassungen. Diese Entscheidung basierte auf dem Prinzip „Design once, scale everywhere”. Ich vereinheitlichte redundante Muster, Farben, Typografie und Spacing über Tokens. Ein klar strukturiertes System spart dadurch langfristig mehr Zeit, selbst wenn der initiale Aufwand höher ist. Durch transparente Kommunikation, Developer Support und Dokumentation konnte ich das Team in die neue Systematik einbinden. Ein wichtiger Schritt, um Akzeptanz zu sichern.
Vorher
( exemplarische Darstellungen ) Die alte Struktur war stark komponentenorientiert und schwer skalierbar.
Nachher
In der neuen Version definierte ich ein themenbasiertes Token-System.
Outcomes
Das neue Designsystem reduzierte den Design- und Entwicklungsaufwand deutlich. Änderungen an Markenfarben oder Typografie ließen sich innerhalb weniger Minuten systemweit anwenden. Das Team arbeitete dadurch konsistenter und Rückfragen oder Rework-Phasen gingen spürbar zurück.
250+ Komponenten,Varianten
Schwerpunkt 2: Governance & Dokumentation
Kontext
Im weiteren Projektverlauf änderten sich die Anforderungen des Mutterkonzerns und der amerikanischen Kund*innen massiv. Behördliche Richtlinien verlangten detaillierte, nachvollziehbare Dokumentation jedes Features. Die Kund*innen nutzte das Figma-File ebenfalls als eigene Q&A-Quelle (ein ungewöhnlicher, aber verbindlicher Prozess). Vorhandene Design-Dokumentationen reichten dadurch nicht mehr aus, um diesen Anforderungen gerecht zu werden.
Herausforderung
Ziel war es, alle Komponenten, Screens und Feature-Flows eindeutig zu nummerieren, nachvollziehbar zu dokumentieren und gleichzeitig die Modularität des Systems beizubehalten. Die Struktur sollte Kund*innen eine klare Orientierung bieten, ohne den Designprozess zu verlangsamen.
Durchnumerierung jedes Screen/Feature Moduls
Vorgehen
Ich restrukturierte die Figma-Datei nach dem Navigations-Modell der App, um eine bessere Übersicht für Kunden möglich zu machen. Jede Seite repräsentierte nun ein Feature und enthielt zusätzlich einen Changelog, in dem jede Änderung für die Kund*innen dokumentiert wurde. Feature-Flows wurden nummeriert und über konsistente Verknüpfungen miteinander verbunden, um Navigation und Nachvollziehbarkeit zu erleichtern. Zudem optimierte ich Farbcodes, Layering und Accessibility gemäß WCAG 2.0, sodass das System barrierefrei und Audit-fähig blieb. Durch ein gezieltes Lizenzmanagement in Figma wurden ungenutzte Seats entfernt, was die Übersicht für Entwickler*innen und PMs zusätzlich verbesserte.
Vorher
Nachher
Die Entscheidung, Nummerierungen und Changelogs einzuführen, war strategisch. Sie schufen Vertrauen und Transparenz gegenüber Kund*innen, die an streng dokumentierte Prozesse gewöhnt waren. Statt die Modularität zugunsten der Dokumentation aufzugeben, kombinierten wir beides durch klare Regeln, Labels und Systemverweise. So blieb das System trotz bürokratischer Vorgaben effizient nutzbar.
Kund*innen Feature Matrix
Mini-Challenge: Figma Lizenzrestriktionen
Um das Produkt für weitere Kunden skalierbar aufzusetzen, war ein Figma-Upgrade nötig, um skalierbares Variablen-Theming nutzen zu können.
1. Accounts konsolidiert. Redundante Accounts validiert und entfernt.
2. Kollaboration vereinfacht. Wege validiert, wie Entwickler ohne Dev-Modus arbeiten konnten.
3. Kosten stabil gehalten. Kosten konnten trotz 3.-fach teurerer Einzel-Lizenzen gleich gehalten werden.
ABT Whitelabel
Outcomes
Die neue Struktur reduzierte Rückfragen der Kund*innen drastisch und verbesserte die Zusammenarbeit mit Entwickler*innen und Projektmanager*innen. Figma wurde zu einem nachvollziehbaren, dokumentierten System, das sowohl technische als auch behördliche Anforderungen erfüllte. Das Team konnte Features schneller freigeben, ohne dass UX-Qualität oder Systemkonsistenz darunter litten.
Learnings
Diese zwei Phasen im Lifecycle des Produkts haben mir gezeigt, dass gutes UX-Design nicht nur im Interface entsteht. Erst in der Struktur dahinter zeigt sich, ob ein System robust und dokumentiert ist und Vertrauen schafft, intern wie extern. Ich habe dadurch gelernt, wie wichtig es ist, Modularität, Transparenz und Pragmatismus auszubalancieren, besonders wenn Prozesse bürokratischer werden. Auch in engen Rahmenbedingungen kann UX strategisch wirken, wenn man konsequent Klarheit schafft.
