Multibrand Designsystem für Whitelabeling
Independent setup for 4+ apps, 35% increase in design efficiency. Reduction of customer onboarding from weeks to 3 days.
Project/ Product:
Account-based Ticketing White Label App
Goal:
Adapting the design system to the business model
Team Composition:
UX Architect, 2 Android Developers, 1 iOS Developer, 2 Project Managers, later also 1 PO (Product Owner)
Role:
UX Architect
Why this Case Study Matters for Your
Scalability.
If you are building a design system for multiple brands or white-label products, you probably recognize these challenges:
Every new brand takes weeks. You customize components individually instead of scaling a system? As a result, client-specific onboarding takes far too long.
Component sprawl (redundancy barrier). Without shared principles, everyone introduces their own interpretation. Colors, spacing, and patterns diverge.
Lack of traceability. Your Figma files fail to provide clients and developers with a clear, documented structure.
What You Will See in This Case Study
This case study shows how even a small team can restructure a design system so that it serves multiple brands while remaining maintainable. You will learn the following:
Modular Theming System
How I transformed the existing design system into modular, themeable building blocks to support multiple brand identities on a shared foundation without losing consistency.
Audit & Token Restructuring
I'll show you how I audited the existing system for redundant component and token structures to create a flexible, scalable foundation instead of quick one-off customizations.
Governance & Documentation
How numbering, changelogs, and a clear Figma architecture provide clarity and traceability for clients and developers without sacrificing the system's modularity.
💡 Scaling Without Chaos
Building a multibrand design system for 4+ white-label apps — as UX Lead, together with an Android developer.
What was delivered:
Modular Token System: From rigid component styles to semantic, themeable tokens for multiple brand identities.
Design System Principles: Shared rules from workshops so that not everyone introduces their own interpretations into the system.
Documented Figma Architecture: Numbered screens and features with changelogs for traceability with clients.
Accessibility Optimization: Color codes, layering, and contrasts according to WCAG 2.2 for auditability.
Client Feature Matrix: Scalable toggles to turn individual features on and off per client.
Sustainable Scaling: Shared principles instead of standalone solutions. Documentation that builds trust. Modularity that grows with every new client instead of being rebuilt every time.
Ready to see how it was done?
What is Account-Based Ticketing?
A modern, digital ticketing system. The ticket is no longer stored on a physical medium (paper/card), but in a central digital account.
ACCOUNT INSTEAD OF CARD
The ticket is no longer in your pocket, but lives in a central digital account
CREDIT INSTEAD OF INDIVIDUAL PURCHASE
Add a payment method or top up credit, instead of paying for each ticket individually.
CODE INSTEAD OF PAPER
Ticket inspectors check validity directly via the account code, not via a physical ticket.
What Didn't Work?
Component-oriented structure: The old structure was heavily component-oriented and hard to scale. The file always had to be copied, and each of these files and customizations had to be maintained individually.
Individual requests instead of system thinking: Clients frequently requested features as one-off custom requests, even though the content was functionally identical across the board.
Version chaos during growth: With every new client, separate component frames were created for the same feature. Developers no longer knew which version was currently valid.
Challenge
The goal was to restructure the existing design system to make it modular, themeable, and maintainable in the long term. It needed to visually represent different brands while ensuring consistency and reusability across the projects' shared foundation.
💡 Business Impact
The business model is based on tenders and services for multiple public transport operators simultaneously. Every new tender means a new client with their own brand, and every additional week of setup time delays feature design and work on other projects, and thus revenue.
With a team of only one designer, every inefficiency multiplies with each additional client. Without a scalable system, growth would have led directly to exponential extra effort instead of increased revenue.
Development Issues
With growth came version chaos. Every new client received custom components for the exact same feature. Developers no longer knew which version was currently valid.
Structure & Architecture
The Workshop
Through workshops and mapping sessions, we identified pain points and created design principles.
The Result:
Clarity: Clear navigation and structuring for developers and clients.
Consistency: Reusable, token-based components instead of redundant patterns.
Empathy: Full accessibility (WCAG 2.0) to accommodate all public transport users.
Approach
Before the actual components were rebuilt, a scalable foundation was required. The new architecture deliberately relied on modular system logic instead of quick one-off customizations.
Design once, scale everywhere A clearly structured system saves time in the long run, even if the initial effort is higher at the beginning.
Token-based flexibility Redundant patterns were eliminated, while colors, typography, and spacing were standardized using semantic variables.
Theme orchestration The token structure was purposefully designed to seamlessly support multi-brand scaling as well as light, inverted, and dark themes.
Alignment between Design & Dev Introduction of regular design-dev meetings to simplify handoffs and resolve misunderstandings early on.
Token Structure
The crucial step toward true white-label capability was decoupling individual customizations and the visual layer from a global system layer.
Old Logic
Roles were bound directly to a specific color (e.g., Icon/Action = Blue dark). This forced a rigid coupling where the design system had to be manually reconfigured from scratch for every single role with each new client.
New Logic (Global System Layer)
The role (e.g., Primary, Success, etc.) is now an abstract layer that simply references a color value (e.g., Blue 800 in the Master) for the respective client. This means that the structure remains the same, while behind the scenes you only need to swap the reference value to switch the entire application to a new brand color.
🔎 Sometimes Less is More
The solution might seem restrictive to some.
A highly standardized system limits conscious design choices, but that is intentionally intended in a white-label architecture. The system had to minimize sources of error without losing the necessary flexibility for brand-specific features.
This structure ensures that having too many options does not lead to confusion, while buttons serve as a deliberate exception for client-specific customizations.
Accessibility
Before the final components were built, I had to ensure that the functional contrasts worked seamlessly across all brand variants. How can accessibility be guaranteed for multiple tenants without losing visual quality?
WCAG Compliance
The architecture was designed to structure color contrasts using clear foreground and background pairings.
This fixed color structure enables an extremely simple and error-free comparison of values:
Logical color pairings Every background token has a permanently assigned on-token (e.g., Primary and On-Primary), which drastically simplifies manual checking.
Visual safeguard Contrasts across the entire color spectrum (such as Error, Warning, or Info containers) can be verified at a glance and adjusted without errors.
Guaranteed compliance Thanks to clear assignment in the library, all themes (Light, Inverted, and Dark) reliably meet the required WCAG 2.0 (AA/AAA) criteria.
Text Scaling & Voice Reader
An accessible interface must respond dynamically to users' individual settings. Components must therefore be able to handle different scaling levels. Using the digital card display as an example, it becomes clear that visual aesthetics and technical accessibility must go hand in hand.
This includes:
Dynamic Text Scaling The layout is designed flexibly so that fonts do not truncate or overlap when increased system-wide (e.g., by older passengers), but instead wrap cleanly below one another.
Logical Voice Reader Order For screen readers, the card is semantically structured with precision. The voice reader reads the data in a logical order (e.g., first the critical status "Balance low", then the ticket value "$0.00"), instead of jumping randomly through the boxes.
Robust Information Architecture Because important notices are not communicated purely through color, but always in combination with clear text, the ticket remains fully usable even for completely blind or color-blind individuals.
🤝 Why Inclusive Design Affects Us All
Accessibility is often mistakenly understood as a niche topic for a small target group. In daily public transport, however, designed contrasts and applications prove to be important for every single passenger.
Limitations when using an app affect us all, just in different dimensions:
Permanent: People with visual impairments, color blindness, or older passengers whose eyesight diminishes with age and who rely on maximum visual clarity.
Temporary: A passenger who had eye drops applied after a doctor's visit, forgot their glasses, or can only operate their smartphone with limitations due to a hand injury.
Situational: Every healthy user standing on the platform at midday in extreme, direct sunlight who needs to quickly and stress-free recognize their ticket on a reflective display. Parents carrying whining toddlers in their arms.
Theme Orchestration
The system is structured to support different themes (Light, Inverted, and Dark). However, since in a white-label model not every client's primary color works well as or is intended for an Inverted theme, I created completely isolated tokens (Inverted Surface, Inverted Error, etc.). This keeps the color logic flexibly customizable for each client, without themes interfering with one another or strictly requiring a Dark Theme.
Master Library
To eliminate version chaos and serve transport companies simultaneously, distribution runs via a central library.
The master file is the Single Source of Truth:
Every update synchronizes automatically for Client A, Client B, and Client C. Nevertheless, the whole thing remains flexible. Via integrated variables, I can easily toggle specific functions (like Feature X) on or off depending on the client – so every transport company gets displayed exactly the features that they ordered.
The true final boss in the white-label system?
“Photos and brand assets.
While colors and spacing are easily automated, client icons, logos, and images quickly break the theme and layout. I've developed an elegant solution for this that handles even the most difficult assets.
What does it look like? I'd love to tell you in person."
Governance & Documentation
Strict regulatory requirements and the needs of US clients demanded a seamless, audit-ready documentation of every feature/flow. The challenge was to integrate this necessary bureaucracy into Figma in such a way that the modularity of the system and the efficiency of the team were maintained.
My approach:
Instead of running documentation as a separate process, I embedded it directly into the architecture of our Figma library. The new structure ensures that our design system does not become a bottleneck, but actively contributes to agility.
Simple Scaling & Reduction: New features can be seamlessly integrated into the existing numbering and navigation without endangering the overall structure.
Central Library Connection: A central library ensures that changes are consistently synchronized across all client instances.
Structural Integrity: The classification into the overarching client framework (e.g., "Client A" $\rightarrow$ "2.3 Card Options") creates immediate transparency for developers and stakeholders. Every user flow (e.g., 2.3.9 Transfer Balance) is designed as an independent, numbered unit.
Always On-Track
Although the system is synchronized through a central library, collaborating with different transport companies requires a high degree of individual transparency. To ensure that every client can precisely trace at any time which adjustments were made to their specific app version, I established a complementary changelog system.
Manual Client Documentation: In addition to automatic library synchronization, client-specific changes are recorded directly in the respective project file via an integrated design changelog.
Audit-Ready: This approach guarantees that every client (Client A, B, or C) receives a seamless history of their own app configuration—essential for regulatory documentation obligations.
Targeted Control: While the library forms the "Single Source of Truth" for the design system, variables and toggles allow me to switch features on or off individually for each transport company. The changelog serves as accompanying documentation that makes each of these individual states traceable for the client.
Mini-Challenge: Figma License Restrictions
We faced the challenge that license restrictions in Figma limited access to advanced features (such as scaled variable theming). Instead of seeing this purely as an obstacle, we used it as an opportunity to strategically optimize our workflow:
Upgrade & Scaling: The necessary upgrade made the use of scalable variable theming possible in the first place.
Process Optimization: By consolidating our accounts, we were able to simplify collaboration while keeping costs stable.
Strategic Shift: This task required a spontaneous shift in our priorities due to overarching business reasons.
Outcomes
The new design system significantly reduced design and development effort. Changes to brand colors or typography could be applied system-wide within minutes. As a result, the team worked more consistently, and inquiries or rework phases decreased noticeably.
What I've Learned
The biggest surprise for me was how much knowledge about the logic and dependencies of individual instances is lost as soon as you lack clear guidelines. At first, I thought the files and the library spoke for themselves. I underestimated the fact that without explicit documentation of the "why" logic behind every connection, the system becomes increasingly fragmented with every update and new feature.
⚒️ Key Insights
Instances don't run on autopilot Without accompanying rules, knowledge about how to use a component quickly turns into "tribal knowledge" that is easily lost during turnover or complex changes.
Documentation as knowledge preservation A changelog is not only there for the client, but also secures internal knowledge about why certain changes were made to instances in the first place.
Architecture beats polish It is more valuable to build a system that others (including developers) can use without asking questions than to perfect every single pixel detail in an isolated file.
Modularity creates freedom A system where features can be toggled on or off like building blocks makes the product scalable for sales without the design team having to start from scratch with every client onboarding.
Let's discuss how I can support your team
With over 3 years of international and DACH experience in UX product design for B2B/B2B2C SaaS platforms, I bring expertise in scalable design systems, accessibility compliance (WCAG 2.2 AA), and data-driven solutions with business impact.
Whether you need help with strategy, usability issues, or end-to-end product design, I look forward to discussing how my skills can drive your company forward.
🔨 Less Blabla. More Impact.