Neilson Financial Services operates across multiple brands in the insurance and financial products space. Each brand has its own visual identity – different colour palettes, different typography, different personality. When I joined as Design Systems Lead, the company's approach to managing this multi-brand reality was brute force: a separate design system for each brand.

Brand A had its own Figma library. Brand B had its own. Brand C had its own. Each library contained the same fundamental components – buttons, cards, forms, navigation – but implemented independently with brand-specific styling baked directly into the components.

The engineering side mirrored this structure. Separate codebases. Separate component libraries. Separate build pipelines. The same <Button> component existed in three or four slightly different implementations, each maintained independently.

This approach had worked when the company had two brands. By the time I arrived, it was cracking under the weight of growth.

What was at stake: Every new brand launch meant rebuilding the design system from scratch. Every component update meant making the same change in multiple places – and hoping nothing was missed. Every design review caught inconsistencies that shouldn't have existed, because the same designer worked across brands but used different component libraries for each. The maintenance burden was growing linearly with brand count, and the company was actively planning to add more brands.

The mathematics of the situation were simple and damning:

N brands x M components = exponential maintenance.

If you have 4 brands and 50 core components, you're maintaining 200 component implementations. When you update the interaction pattern of a modal, you make the change four times. When you add a new component, you add it four times. When you find a bug, you fix it four times – and you'd better not miss one.

But the cost wasn't just maintenance hours. It was consistency erosion.

No shared language. The same component had different names across brand libraries. Brand A's PrimaryButton was Brand B's ActionButton was Brand C's CTAButton. The underlying component was functionally identical, but the naming divergence meant designers switching between brands had to relearn the vocabulary each time.

No shared patterns. Interaction patterns drifted. Brand A's modal had a close button in the top-right corner. Brand B's had it in the top-left. Not because of a deliberate brand decision – because two different designers built them independently and never compared notes.

No shared code. Engineers couldn't reuse component code across brands. A bug fix for Brand A's date picker didn't automatically apply to Brand B's, even though the underlying logic was identical. Teams were solving the same problems independently, burning engineering hours on work that had already been done.

Design reviews caught problems too late. By the time a design review flagged that Brand B's form validation pattern was inconsistent with Brand A's, the implementation was already in progress. Fixing it meant rework, not prevention.

[IMAGE PLACEHOLDER: "The Multiplication Problem" Diagram]

The solution was architecturally elegant and organisationally challenging: separate the thing that changes (brand identity) from the thing that doesn't (component structure and behaviour).

I proposed a unified architecture built on three layers:

Layer 1: Global Tokens The foundational design decisions that are brand-agnostic – spacing scale, border radius scale, elevation levels, responsive breakpoints. These are the physics of the design system. They don't change between brands because they're not about visual identity – they're about spatial consistency and structural hierarchy.

Layer 2: Brand Tokens The values that express each brand's visual identity – primary colour, secondary colour, font family, heading weight. Each brand gets its own token set. Brand A's color.primary resolves to a deep navy. Brand B's resolves to a vibrant teal. The token name is the same. The value is different. The component doesn't need to know which brand it's rendering for – it just references color.primary and the token layer handles the rest.

Layer 3: Component Tokens The mapping between generic token names and specific component properties – button.background maps to color.primary, button.text maps to color.on-primary. This layer is what makes theming composable. Change the brand token values, and every component updates automatically. No per-component overrides. No manual reskinning.

The component library itself becomes brand-agnostic. The <Button> component doesn't know about navy or teal. It knows about color.primary. The brand token set decides what color.primary means. Each brand becomes a skin – a set of token values applied to the same structural components.

The key insight was that brand differentiation in financial services lives almost entirely in the token layer. Brands don't need fundamentally different buttons – they need the same button in their colour palette. They don't need different form patterns – they need the same patterns in their typography. The structural and behavioural layer is shared. The visual expression layer is not. The token architecture makes that separation explicit and enforceable.

[IMAGE PLACEHOLDER: "Token Architecture" Layered Diagram]

The transition wasn't a big-bang migration. It was deliberate, category by category, validated with each brand team at every step.

Phase 1: The Audit

I started by auditing every brand library to answer two questions:

1. What's actually shared across brands? (Structure, behaviour, interaction patterns)
2. What's genuinely different? (Not accidentally different – intentionally, meaningfully different for brand reasons)

The audit revealed what I suspected: ~90% of the component structure was identical across brands. The differences were overwhelmingly in the visual expression layer – colours, fonts, spacing values, border treatments. The few genuinely structural differences (Brand A had a unique mega-menu that other brands didn't use) could be handled as component variants, not separate implementations.

Phase 2: Token Architecture Design

I designed the three-layer token system: global → brand → component. The naming convention was critical – it had to be intuitive enough for designers to use without a reference guide, specific enough for engineers to implement without ambiguity, and extensible enough to accommodate brands that didn't exist yet.

I chose a semantic naming approach over a descriptive one. color.primary instead of color.navy. spacing.md instead of spacing.16. This meant the token names described their role, not their value – which is exactly what makes theming work. The value can change. The role stays the same.

Phase 3: Component Migration

I migrated components one category at a time, starting with the highest-volume components (buttons, inputs, cards) and working toward the more specialised ones (mega-menus, data tables). For each category:

1. Define the component's token interface – which tokens does it consume?
2. Build the unified component in the shared library
3. Create the brand token sets that make it look correct for each brand
4. Validate with each brand team – does this still feel like their brand?
5. Deprecate the brand-specific component once the unified version is approved

The validation step was non-negotiable. Brand teams needed to feel ownership of their visual identity, not that it was being homogenised. The conversation was always: "Your brand identity is preserved – we're just changing where it's defined. It lives in your token set now, not baked into each component."

Phase 4: Documentation and Contribution Model

I created contribution guidelines for the unified system – how to add a new component, how to extend the token set for a new brand, how to propose a structural change that affects all brands. The system needed to be maintainable by people who didn't design it, which meant the documentation had to be more than a reference – it had to teach the mental model.

[IMAGE PLACEHOLDER: "Migration Timeline" Flow]

[IMAGE PLACEHOLDER: "Before/After Architecture" Comparison]

Quantified:

• ~60% reduction in component maintenance effort – one implementation instead of N copies per component
• Brand onboarding reduced from weeks to days – new brands apply a token set to the existing library instead of rebuilding from scratch
• Engineering code sharing enabled for the first time – the same component codebase serves all brands, with token-driven theming handling visual differences
• Design review rework dropped significantly – inconsistencies between brands became structurally impossible for token-driven properties

Qualitative:

• Designers switching between brands no longer needed to relearn component names and patterns – the shared vocabulary reduced cognitive load
• Brand teams retained ownership of their visual identity through their token sets – the transition didn't feel like homogenisation
• New component proposals became conversations about the system, not about a specific brand – raising the level of design discourse
• Engineers went from fixing the same bug four times to fixing it once – the frustration reduction was immediate and vocal

The seed that grew: This project fundamentally shaped how I think about design systems. The insight that design systems are infrastructure – not libraries – came from watching a token-driven architecture eliminate entire categories of problems that a library-based approach couldn't touch. The three-layer token architecture I designed here was the conceptual ancestor of the 1,800+ token system I'd later manage at enterprise scale. The migration methodology – category by category, validated with stakeholders at each step – became my default approach for any large-scale design system change.

On knowing when to propose a structural change: The siloed approach wasn't stupid – it was a reasonable solution at a smaller scale. The skill wasn't seeing that it was broken (everyone could see that). The skill was articulating why a structural change was the right response versus incremental improvements, and having the design vocabulary to propose a specific alternative architecture. "It should be better" is a complaint. "Here's a three-layer token architecture that separates brand identity from component structure" is a proposal.

On managing the human side of system changes: Brand teams were protective of their visual identity, and rightfully so. The biggest risk in this project wasn't technical – it was the perception that their brand was being commoditised. Framing the change as "your identity is preserved, just relocated to a more powerful place" made the difference between resistance and buy-in. The token set gives brand teams more control, not less – they can change every visual property without touching the component code.

On the design-system-as-infrastructure conviction: This project is where I started believing – really believing, not just saying – that design systems are infrastructure. Not because I read it in an article, but because I watched a well-designed infrastructure layer (the token architecture) eliminate problems that no amount of library maintenance could fix. That conviction has shaped every systems decision I've made since.