Building and Scaling a multi-brand Design System

I was brought into a feature squad to solve a critical scaling bottleneck: our existing UI library was built for a single product, but our business model needed it to suddenly support a rapidly growing roster of corporate partnerships. Over the course of a year, I led the complete refactoring of our design system, transforming a monolithic setup into a resilient, multi-brand engine.

I was brought into a feature squad to solve a critical scaling bottleneck: our existing UI library was built for a single product, but our business model needed it to suddenly support a rapidly growing roster of corporate partnerships. Over the course of a year, I led the complete refactoring of our design system, transforming a monolithic setup into a resilient, multi-brand engine.

Scope of Work

Design System
Branding
Architecture
Tokens

The evolution

The system started as a single, over-extended Figma file. As complexity scaled, I systematically broke the architecture down into a library of smaller, highly specialised files – separating Foundations, Components, Patterns, Icons, and Email. To make theme-swapping completely seamless across these libraries, I overhauled our data structure, shifting the entire infrastructure to a 3-tier variable collection setup.

The Challenge: Eliminating Visual Regression Across Complex Partnerships

When our product ecosystem scaled to onboard multiple partner brands, the biggest technical risk was visual regression—components breaking, texts losing accessibility contrast, or backgrounds clashing during theme swaps.

Instead of creating massive maintenance debt with split asset libraries, I architected a highly resilient, 3-tier variable pipeline in Figma designed with built-in "safety nets" to guarantee layout integrity no matter how radically a partner’s brand identity shifted.

By separating raw values, thematic modes, and component execution layers, the system cleanly abstracts design choices from product logic:

1.Primitives (The Global Palette): Collection 1.
A centralised, raw data layer containing absolute values (the exact HEX codes, sizing steps, and radii metrics). Components never reference this collection directly.

2.Theme (The Multi-Brand Matrix): Collection 2.
This is where our partner brands live as distinct Variable Modes. Instead of assigning static styles, I built a matrix of intent-driven variables. When a new partnership is introduced, we simply spin up a new mode column in this collection.

3.Components (The Implementation Layer): Collection 3.
The localised component tokens that map directly to the design layers inside our master variants (like buttons, input fields, or cards), bridging our design intent directly to front-end properties.

Defensive Design: Why I Separated "Fill/On-Fill" from Global Semantics

The core innovation of this architecture is its resilience against theme-swapping failure. Many design systems map components directly to broad tokens like text-primary or surface-default. In a multi-brand world, this causes immediate layout breaks if a partner brand introduces an inverted colour scheme.

To mitigate this, I built an isolation barrier between general layouts and element states:

  • The Problem: A button mapped to a general brand-accent fill and global text-inverse works perfectly on a white theme. But if a partner theme utilises a neon yellow accent, white text instantly fails WCAG legibility contrast.

  • The Safety Net Solution: I decoupled component fills entirely from generic surface/text/icon tokens. Components are mapped strictly to strict Fill and On-Fill colour pairings inside the Theme collection.

Our React Migration

This rigid Figma structure isn't just an internal organisation method—it acts as the direct technical blueprint for our engineering squad's ongoing migration into a tokenised React system.

While I focus purely on the Figma architecture, I act as the system's data architect:

  • 1:1 Code Matching: Currently ongoing, our 3-tier variable collection is being mapped precisely to the engineers' token mapping schema (Primitives → Theme Providers → Component Overrides).

  • Frictionless Hand-off: Engineers don't need to guess colour or spacing logic. Because the structural data layout inside Figma matches their React props, a variable mode swap in design maps perfectly to an automated component update in production and allows for swifter onboarding of new partnerhsips.

Latest Projects