A single Figma design system powering a multi-brand Auto & Home Insurance app across partner organisations through modes, tokens, and branching.
The brief was ambitious: design a single insurance app for Auto & Home coverage that could be white-labelled and rebranded for multiple partner organisations — each with their own distinct brand identity, visual language, and guidelines — without rebuilding the product each time.
My responsibility was to architect and build the Figma design system from the ground up, defining how the parent white-label app would serve as the source of truth, and how each partner brand would inherit and override it through Figma's Modes and Variables system.
Every partner brand had distinct colour palettes, typography choices, iconography styles, and component expectations. The real challenge was keeping one unified codebase in Figma while allowing each brand to feel completely native — without duplicating components 4× over or letting the system drift into inconsistency over time.
The project unfolded in four distinct phases — from auditing each partner's brand guidelines to publishing the branched deliverables.
Gathered brand guidelines from each partner — colour systems, typography scales, spacing rules, icon styles, and component expectations. Mapped every visual decision to a design token, creating a complete token taxonomy that could absorb any brand's values.
Built the core white-label component library in Figma — every screen, component, and pattern for the Auto & Home insurance flow. Designed using only token-referenced values so nothing was hardcoded. This parent system became the single source of truth for all branches.
Used Figma's Variable Modes to define a separate mode for each partner brand. Each mode maps the same token set to that brand's specific values — colours, radius, type, shadows. Switching the mode on a frame instantly re-skins the entire design to that partner's brand with zero manual rework.
Created a dedicated Figma branch for each partner brand from the parent file. Each branch inherits all components and layouts, with the brand's mode applied. Brand-specific overrides or unique components live only in that branch — keeping the parent clean and the partner branches in sync when the main file updates.
Understanding how the parent system relates to each branch is what makes this approach scalable. Here's the architecture at a glance.
From global tokens to partner-specific branches — one consistent chain of inheritance.
As partner brand requirements evolved, adding new tokens or changing variable structures risked breaking previously set modes. Establishing strict naming conventions and token categories early on — and documenting every change — was critical to keeping all modes stable simultaneously.
When core components or flows updated in the parent file, each branch needed to be reviewed for merge conflicts. Establishing a branching protocol — with structured merge reviews and a clear changelog — prevented partner-specific overrides from being overwritten accidentally.
Each component potentially needed to look different per brand — not just in colour, but sometimes in shape, size, or hierarchy. Managing this through Modes and Variants (rather than duplicating components) required disciplined component architecture so variants remained maintainable at scale.
Each partner supplied brand guidelines at varying levels of specificity. Some had full design tokens; others just a PDF with hex codes. Standardising these into a shared token taxonomy — without losing brand fidelity — required close collaboration with brand managers and several rounds of review.
Beyond the numbers, the system fundamentally changed how the team scales. A new partner brand can now be onboarded into the design system in hours — not weeks — because the entire product is already built; only the brand token values need to be defined and applied as a new mode.
Token naming is architecture. The names you give your tokens become the shared language between design and engineering. Investing time early in a logical, scalable taxonomy saves enormous pain when adding modes or updating values later.
Branches need governance. Figma branching is powerful but requires discipline. Without clear merge protocols and documented branch ownership, drift happens fast. A lightweight branching guide turned out to be as important as the components themselves.
Design systems are a product, not a deliverable. The system only delivers value if it's maintained, communicated clearly to partners, and updated when the product evolves. Treating it as an ongoing product — with changelogs, documentation, and review cycles — made all the difference.
Modes reduce decision fatigue. Before Modes, every brand review meant opening a different file. Modes made switching contexts instantaneous — which directly improved the quality and speed of brand partner feedback sessions.