Multibrand Designsystem für Whitelabeling
Eigenverantwortlicher Aufbau für 4+ Apps, Steigerung der Design-Effizienz um 35%. Reduktion des Kunden-Onboardings von 4 Wochen auf 3 Tage.
Projekt/ Produkt:
Account based Ticketing Whitelabel App
Ziel:
Anpassung des Designsystems an das Geschäftsmodell
Teamzusammensetzung:
UX Architekt, 2 Android Entwickler,1 IOS Developer, 2 Projektmanager, später auch 1 PO
Rolle:
UX Architekt
Warum diese Case Study wichtig ist für deine
Skalierbarkeit.
Wenn du ein Designsystem für mehrere Marken oder Whitelabel-Produkte aufbaust, kennst du wahrscheinlich diese Herausforderungen:
Jede neue Marke kostet Wochen. Ihr passt Komponenten einzeln an, statt ein System zu skalieren? Kundenspezifisches Onboarding dauert dadurch viel zu lange.
Komponenten-Wildwuchs (Redundanz-Barriere). Ohne gemeinsame Prinzipien bringt jede*r seine eigene Interpretation ein, Farben, Spacing und Patterns laufen auseinander.
Fehlende Nachvollziehbarkeit. Eure Figma-Files schaffen es nicht, Kunden und Entwickler*innen eine klare, dokumentierte Struktur zu bieten.
Was du in dieser Case Study sehen wirst
Diese Case Study zeigt, wie man auch mit einem kleinen Team ein Designsystem so restrukturiert, dass es mehrere Marken bedient und trotzdem wartbar bleibt. Du wirst Folgendes lernen:
Modulares Theming-System
Wie ich das bestehende Designsystem in modulare, themingfähige Bausteine überführt habe, um mehrere Markenidentitäten über eine gemeinsame Basis abzubilden, ohne Konsistenz zu verlieren.
Audit & Token-Restrukturierung
Ich zeige dir, wie ich das bestehende System auf redundante Komponenten- und Token-Strukturen geprüft habe, um ein flexibles, skalierbares Fundament statt schneller Einzelanpassungen zu schaffen.
Governance & Dokumentation
Wie Nummerierung, Changelogs und eine klare Figma-Architektur Kund*innen und Entwickler*innen Nachvollziehbarkeit geben, ohne die Modularität des Systems zu opfern.
💡 Skalierung ohne Chaos
Aufbau eines Multibrand-Designsystems für 4+ Whitelabel-Apps –als UX-Lead, gemeinsam mit einem Android-Entwickler.
Was geliefert wurde:
Modulares Token-System: Von starren Komponenten-Styles zu semantischen, themingfähigen Tokens für mehrere Markenidentitäten
Designsystem-Prinzipien: Gemeinsame Regeln aus Workshops, damit nicht jede:r eigene Interpretationen ins System einfließen lässt
Dokumentierte Figma-Architektur: Durchnummerierte Screens und Features mit Changelogs für Nachvollziehbarkeit gegenüber Kund:innen
Accessibility-Optimierung: Farbcodes, Layering und Kontraste nach WCAG 2.0 für Audit-Fähigkeit
Kunden-Feature-Matrix: Skalierbare Toggles, mit denen einzelne Features pro Kunde an- und ausgeschaltet werden können
Nachhaltige Skalierung: Gemeinsame Prinzipien statt Einzellösungen. Dokumentation, die Vertrauen schafft. Modularität, die mit jedem neuen Kunden mitwächst, statt jedes Mal neu gebaut zu werden.
Bereit zu sehen, wie es gemacht wurde?
Was ist Account Based Ticketing ?
Ein modernes, digitales Fahrsystem. Die Fahrkarte wird nicht mehr auf einem physischen Medium (Papier/Karte) gespeichert, sondern in einem zentralen digitalen Konto.
Konto statt Karte
Die Fahrkarte liegt nicht mehr in der Tasche, sondern lebt in einem zentralen digitalen Account.
Guthaben statt Einzelkauf
Zahlungsmethode hinterlegen oder Guthaben aufladen, statt jedes Ticket einzeln zu bezahlen.
Code statt Papier
Kontrolleure prüfen die Gültigkeit direkt über den Account-Code, nicht über ein physisches Ticket.
Was hat nicht funktioniert?
Komponentenorientierte Struktur: Die alte Struktur war stark komponentenorientiert und schwer skalierbar. Das File musste immer kopiert werden und jedes dieser Files und Anpassungen musste einzeln gepflegt werden.
Einzelwünsche statt System-Denken: Kunden forderten Funktionen häufig als Einzelwünsche an, obwohl die Inhalte inhaltlich übergreifend identisch waren.
Versionschaos bei Wachstum: Mit jedem neuen Kunden entstanden eigene Komponenten-Frames für dieselbe Funktion – Entwickler wussten nicht mehr, welche Version aktuell gültig war.
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.
💡 Business Impact
Das Geschäftsmodell basiert auf Ausschreibungen und Serviceleistungen für mehrere ÖPNV-Betreiber gleichzeitig. Jede neue Ausschreibung bedeutet einen neuen Kunden mit eigener Marke und jede zusätzliche Woche Setup-Zeit verzögert Feature Design und Arbeit an anderen Projekten und damit den Umsatz.
Bei einem Team mit nur einer Designerin multipliziert sich jede Ineffizienz mit jedem weiteren Kunden. Ohne ein skalierbares System hätte Wachstum direkt zu exponenziellem Mehraufwand statt Mehrumsatz geführt.
Probleme in der Entwicklung
Mit dem Wachstum wuchs auch das Versionschaos. Jeder neue Kunde erhielt eigene Komponenten für dieselbe Funktion. Entwickler wussten nicht mehr, welche Version aktuell gültig war.
Struktur & Architektur
Der Workshop
Durch Workshops und Mapping-Sessions identifizierten wir Pain Punkte und erstellen Designprinzipien
Das Ergebniss:
Klarheit: Eine eindeutige Navigation und Strukturierung für Entwickler und Kunden.
Konsistenz: Wiederverwendbare, token-basierte Komponenten statt redundanter Patterns.
Empathie: Volle Barrierefreiheit (WCAG 2.0), um allen Nutzern im ÖPNV gerecht zu werden.
Vorgehen
Bevor die eigentlichen Komponenten umgebaut wurden, musste ein skalierbares Fundament her. Die neue Architektur basierte bewusst auf einer modularen Systemlogik statt auf schnellen Einzelanpassungen.
Design once, scale everywhere Ein klar strukturiertes System spart langfristig Zeit, selbst wenn der initiale Aufwand zu Beginn höher ist.
Token-basierte Flexibilität Redundante Patterns wurden eliminiert, während Farben, Typografie und Spacing über semantische Variablen vereinheitlicht wurden.
Theme-Orchestrierung Die Token-Struktur wurde gezielt so aufgebaut, dass sie Multi-Brand-Skalierung sowie Light, Inverted und Dark Themes nahtlos unterstützt.
Abstimmung zwischen Design & Dev Einführung regelmäßiger Design-Dev-Meetings, um Übergaben zu vereinfachen und Missverständnisse frühzeitig aufzulösen.
Token Struktur
Der entscheidende Schritt zur echten Whitelabel-Fähigkeit war die Entkopplung der Einzelanpassungen und visuellen Ebene von einer globalen Systemschicht.
Alte Logik
Die Rollen waren direkt an eine spezifische Farbe gebunden (z. B. Icon/Action = Blue dark). Dies erzwang eine starre Kopplung, bei der das Design-System bei jedem neuen Kunden manuell für jede einzelne Rolle komplett neu konfiguriert werden musste.
Neue Logik (Globale Systemschicht)
Die Rolle (z. B. Primary, Success..) ist nun eine abstrakte Ebene, die nur noch auf einen Farbwert (z. B. Blue 800 im Master)) vom jeweiligen Kunden verweist. Das bedeutet, dass die Struktur gleich bleibt, während man im Hintergrund nur den Referenzwert austauschen muss, um die gesamte Anwendung auf eine neue Markenfarbe umzustellen.
🔎 Manchmal ist weniger mehr
Die Lösung mag für manche einschränkend wirken.
Ein stark standardisiertes System schränkt bewusste Design-Entscheidungen ein, genau das ist bei einer Whitelabel-Architektur aber gewollt. Das System musste Fehlerquellen minimieren ohne die nötige Flexibilität zu verlieren für markenspezifische Besonderheiten.
Diese Struktur stellt hier sicher, dass eben nicht zu viele Optionen nicht zu Verwirrung führen, während die Buttons als bewusste Ausnahme für Kunden-Individualisierungen dienen.
Barrierefreiheit
Bevor die finalen Komponenten gebaut wurden, musste ich sicherstellen, dass die funktionalen Kontraste über alle Markenvarianten hinweg nahtlos funktionieren. Wie lässt sich Barrierefreiheit für mehrere Mandanten sicherstellen, ohne die visuelle Qualität zu verlieren?
WCAG-Konformität
Die Architektur wurde so konzipiert, dass sie Farbkontraste über klare Vorder- und Hintergrundpaarungen strukturiert.
Diese feste Farb-Struktur ermöglicht ein extrem einfaches und fehlerfreies Abgleichen der Werte:
Logische Farbpaarungen Jedes Background-Token besitzt ein fest zugeordnetes On-Token (z. B. Primary und On-Primary), was die manuelle Kontrolle drastisch vereinfacht
Visuelle Absicherung Kontraste lassen sich über das gesamte Farbspektrum (wie Error-, Warning- oder Info-Container) auf einen Blick verifizieren und fehlerfrei anpassen
Garantierte Compliance Durch die saubere Zuordnung in der Library erreichen alle Themes (Light, Inverted und Dark) verlässlich die geforderten WCAG 2.0 (AA/AAA) Kriterien
Textskalierung & Voice Reader
Ein barrierefreies Interface muss dynamisch auf die individuellen Einstellungen der Nutzer reagieren. Komponenten müssen somit verschiedene Skalierungen abfangen Können. Am Beispiel der digitalen Karten-Anzeige wird deutlich, dass visuelle Ästhetik und technische Barrierefreiheit Hand in Hand gehen müssen.
Dazu gehört:
Dynamische Textskalierung Das Layout ist so flexibel aufgebaut, dass Schriften bei einer systemweiten Vergrößerung (z. B. durch ältere Fahrgäste) nicht abschneiden oder überlappen, sondern sauber untereinander umbrechen
Logische Voice-Reader-Reihenfolge Für Screenreader ist die Karte semantisch exakt strukturiert. Der Voice Reader liest die Daten in der logischen Reihenfolge vor (z. B. erst der kritische Status Balance low, dann der Ticketwert $0.00 ), statt ungeordnet durch die Boxen zu springen
Robuste Informations-Architektur Da wichtige Hinweise nicht rein über Farbe, sondern immer in Kombination mit klarem Text kommuniziert werden, bleibt das Ticket auch für komplett blinde oder farbenblinde Menschen vollumfänglich nutzbar
🤝 Warum Inclusive Design uns alle betrifft
Barrierefreiheit wird oft fälschlicherweise als Nischenthema für eine kleine Zielgruppe verstanden. Im ÖPNV-Alltag zeigt sich jedoch, dass gestaltete Kontraste und Anwendungen für jeden einzelnen Fahrgast wichtig sind.
Einschränkungen beim Bedienen einer App betreffen uns alle,nur in unterschiedlichen Dimensionen:
Permanente: Menschen mit Sehschwächen, Farbenblindheit oder ältere Fahrgäste, deren Sehkraft im Alter nachlässt und die auf maximale visuelle Klarheit angewiesen sind
Temporäre: Ein Fahrgast, der nach einem Arztbesuch die Augen getropft bekommen hat, seine Brille vergessen hat oder durch eine Handverletzung das Smartphone nur eingeschränkt bedienen kann.
Situative: Jeder gesunde Nutzer, der mittags bei extremer, direkter Sonneneinstrahlung am Bahnsteig steht und sein Ticket auf dem spiegelnden Display schnell und stressfrei erkennen muss. Eltern mit Quengelnden kleinen Kindern auf dem Arm.
Theme-Orchestrierung
Das System ist so aufgebaut, dass es verschiedene Themes (Light, Inverted und Dark) unterstützt. Da im Whitelabel-Modell aber nicht jeden Kunde sich die Primary-Farbe als Inverted-Theme anbietet oder nutzen möchte, habe ich komplett isolierte Tokens angelegt (Inverted Surface, Inverted Error....). So bleibt die Farb-Logik für jeden Kunden flexibel anpassbar, ohne dass die Themes sich untereinander beeinflussen oder das Dark Theme zwingend vorausgesetzt wird.
Master Library
Um das versionschaos zu eliminieren und Verkehrsbetriebe gleichzeitig zu bedienen, läuft die Verteilung über eine zentrale Library.
Die Master-Datei ist dabei die Single Source of Truth:
Jedes Update synchronisiert sich automatisch für Client A, Client B und Client C. Trotzdem bleibt das Ganze flexibel. Über integrierte Variablen kann ich spezifische Funktionen (wie Feature X) je nach Kunde einfach per Toggle ein- oder ausschalten – so bekommt jeder Verkehrsbetrieb genau die Features, das er bestellt hat angezeigt.
Der wahre Endgegner im Whitelabel-System?
“Fotos und Brand-Assets.
Während Farben und Abstände easy automatisiert sind, zerschießen Kunden-Icons/logos & Bilder schnell Theme & Layout. Ich habe dafür eine elegante Lösung entwickelt, die selbst mit den schwierigsten Assets klarkommt.
Wie die aussieht? Das erzähle ich dir am besten persönlich.”
Governance & Dokumentation
Strikte regulatorische Anforderungen und die Bedürfnisse von US-Kunden erforderten eine lückenlose, audit-fähige Dokumentation jedes Features/Flows. Die Herausforderung bestand darin, diese notwendige Bürokratie so in Figma zu integrieren, dass die Modularität des Systems und die Effizienz des Teams erhalten blieben.
Mein Ansatz:
Anstatt Dokumentation als separaten Prozess zu führen, habe ich sie direkt in die Architektur unserer Figma-Library eingebettet. Die neue Struktur sorgt dafür, dass unser Design-System nicht zum Flaschenhals wird, sondern aktiv zur Agilität beiträgt.
Einfache Skalierung & Reduktion: Neue Features lassen sich nahtlos in die bestehende Nummerierung und Navigation einfügen, ohne die Gesamtstruktur zu gefährden.
Zentrale Library-Anbindung: Über eine zentrale Library wird sichergestellt, dass Änderungen konsistent über alle Kunden-Instanzen hinweg synchronisiert werden.
Strukturelle Integrität: Die Einordnung in das übergeordnete Kunden-Framework (z. B. "Client A" -> "2.3 Card Options") schafft sofortige Transparenz für Entwickler und Stakeholder. Jeder User-Flow (z. B. 2.3.9 Transfer Balance) ist als autarke, nummerierte Einheit konzipiert.
Immer On-Track
Obwohl das System durch eine zentrale Library synchronisiert wird, erfordert die Zusammenarbeit mit unterschiedlichen Verkehrsbetrieben eine hohe individuelle Transparenz. Um sicherzustellen, dass jeder Kunde zu jedem Zeitpunkt genau nachvollziehen kann, welche Anpassungen an seiner spezifischen App-Version vorgenommen wurden, habe ich ein ergänzendes Changelog-System etabliert.
Manuelle Kunden-Dokumentation: Zusätzlich zur automatischen Library-Synchronisation werden kundenspezifische Änderungen direkt im jeweiligen Projekt-File über ein integriertes Design Changelog festgehalten.
Audit-Ready: Dieses Vorgehen garantiert, dass jeder Kunde (Client A, B oder C) eine lückenlose Historie der eigenen App-Konfiguration erhält essenziell für die behördliche Dokumentationspflicht.
Gezielte Steuerung: Während die Library die "Single Source of Truth" für das Design-System bildet, erlauben mir Variablen und Toggles, Features individuell für jeden Verkehrsbetrieb ein- oder auszuschalten. Das Changelog dient dabei als begleitende Dokumentation, die jeden dieser individuellen Zustände für den Kunden nachvollziehbar macht.
Mini-Challenge: Figma-Lizenzrestriktionen
Wir standen vor der Herausforderung, dass Lizenzrestriktionen in Figma den Zugriff auf erweiterte Funktionen (wie skaliertes Variablen-Theming) einschränkten. Anstatt dies nur als Hindernis zu sehen, haben wir es als Chance genutzt, unsere Arbeitsweise strategisch zu optimieren:
Upgrade & Skalierung: Das notwendige Upgrade ermöglichte uns erst die Nutzung eines skalierbaren Variablen-Themings.
Prozessoptimierung: Durch die Konsolidierung unserer Accounts konnten wir die Kollaboration vereinfachen und gleichzeitig die Kosten stabil halten.
Strategische Verlagerung: Diese Aufgabe erforderte eine spontane Verlagerung unserer Schwerpunkte aus übergeordneten Business-Gründen.
Outcomes
Durch die Implementierung des neuen Design-Systems konnten wir den Design- und Entwicklungsaufwand deutlich reduzieren und die Konsistenz über die gesamte Anwendung hinweg sicherstellen.
Was ich gelernt haben
Die größte Überraschung für mich war, wie viel Wissen über die Logik und die Abhängigkeiten einzelner Instanzen verloren geht, sobald man keine klaren Guidelines hat. Anfangs dachte ich, die Dateien und die Library sprechen für sich. Ich habe unterschätzt, dass ohne eine explizite Dokumentation der „Warum“-Logik hinter jeder Verknüpfung das System mit jedem Update und jedem neuen Feature immer fragmentierter wird.
⚒ Key Insights
Instanzen sind kein Selbstläufer Ohne begleitende Regeln wird das Wissen über die Anwendung einer Komponente schnell zum „Tribal Knowledge“, das bei Fluktuation oder komplexen Änderungen einfach verloren geht.
Dokumentation als Wissenssicherung Ein Changelog ist nicht nur für den Kunden da, sondern sichert das interne Wissen darüber, warum bestimmte Änderungen an Instanzen überhaupt vorgenommen wurden.
Architektur schlägt Pinsel Es ist wertvoller, ein System zu bauen, das andere (auch Entwickler) ohne Rückfragen bedienen können, als jedes einzelne Pixel-Detail in einem isolierten File zu perfektionieren.
Modularität schafft Freiheit Ein System, in dem man Features wie mit einem Baukasten zu- oder abschalten kann, macht das Produkt für den Vertrieb skalierbar, ohne dass das Design-Team bei jedem Kunden-Onboarding bei Null anfangen muss.
Lass uns besprechen, wie ich dein Team unterstützen kann
Mit über 3 Jahren internationaler und DACH-Erfahrung im UX-Produktdesign für B2B/B2B2C-SaaS-Plattformen bringe ich Expertise in skalierbaren Designsystemen, Accessibility-Compliance (WCAG 2.2 AA) und datengetriebenen Lösungen mit Business-Impact mit.
Egal ob du Hilfe bei Strategie, Usability-Problemen oder End-to-End Produktdesign brauchst, freue ich mich darauf zu besprechen, wie meine Skills dein Unternehmen voranbringen können.
🔨 Less Blabla. More Impact.