Building for multi-brand: what changes and what doesn't

When a design system needs to support multiple brands, the conversation usually starts with tokens. Color tokens get swapped per brand. Typography tokens get swapped per brand. The components stay the same, the surface skin changes. Easy.

It's never that simple, and the reason it isn't has nothing to do with tokens.

What's actually different between brands

If your brands really just differ in palette and typeface, tokens are the answer. Most real multi-brand situations involve more than that. Different brands have different visual languages. One is dense and editorial, one is spacious and minimal, one is playful and uses heavy illustration. These differences live in proportions, in motion behavior, in component density, in shape. They live below the token layer.

This is the first decision you have to make explicitly. Are your brands cosmetic variants of one underlying system, or are they meaningfully different visual approaches that share some components and not others? The answer determines the shape of the system.

Cosmetic variants can ride on the same component library with theme tokens. Different visual approaches need different component implementations for the parts that differ, and a shared foundation only for the parts that are genuinely common.

The shared foundation

Even brands that look quite different usually share some things. Accessibility primitives. Form interaction patterns. Keyboard behavior. The structure of how cards stack or how modals open. The technical foundations.

This is what the design system should own across brands: the layer where deviation would cost more than it would buy. A modal that traps focus differently per brand is a maintenance nightmare and an accessibility hazard. A button that handles keyboard activation differently per brand is the same. Standardize the behaviors, vary the appearances.

The hard part is drawing the line. Where does behavior end and appearance begin? Animation timing is sometimes brand. Sometimes it's behavior. Component density is sometimes brand. Sometimes it's a different layout system entirely. Each design system team has to answer these for their own context. The answers should be explicit, not implicit, and they should be in the documentation.

Where token systems break down

The standard token model works for color and typography and spacing. Primitive tokens at the base, semantic tokens that map to primitives, brand themes that swap which primitives the semantics reference. It breaks down for shape.

A brand whose card has 4px radius is different from a brand whose card has 24px radius, but the difference cascades. The 4px brand needs different shadow tokens because the soft shadow that fits the 24px card looks wrong on a 4px card. It needs different motion behavior because a card with sharp corners moves differently than a card with soft corners. The "just swap the radius token" approach produces an output that technically works and visually looks wrong.

The fix is acknowledging that shape isn't a single-axis token swap. It's a coordinated set of tokens that have to move together, with relationships that need to be designed at the brand-system level, not the individual-token level.

Documentation across brands

A single-brand system has one set of docs. A multi-brand system has a coordination problem: where does the brand-specific guidance live, where does the cross-brand guidance live, and how do consumers know which applies to them.

The setup that fails is one giant doc site with every brand's guidance interleaved. Consumers building for one brand have to filter through documentation for other brands they don't care about. The setup that fails differently is fully separate doc sites per brand with no shared documentation, where the foundations get out of sync and accessibility patterns drift.

The version that works in practice has shared documentation for the foundations and component APIs, with brand-specific docs layered on top showing how each brand uses the components. Consumers default to their brand's doc set and can drill into the shared foundations when they need to.

The team structure question

Multi-brand systems force an organizational decision most teams put off. Who owns the cross-brand foundation? Who owns each brand's expression?

The two failure modes mirror each other. If everyone owns everything, decisions get blocked because every change requires consensus across brands that don't agree. If each brand owns its own version, the shared foundation rots because nobody is responsible for it.

The setup that works is a small foundation team that owns the cross-brand pieces with explicit authority, and brand teams that own their respective expression layers. The foundation team makes decisions and the brand teams either adapt or escalate. Without that structure, you end up with three brands that all use the system selectively and a foundation that pleases nobody.

When not to do this

If your brands are different enough that they need substantially different interaction patterns, substantially different shape languages, and substantially different motion behaviors, they're not actually one design system with multiple themes. They're two design systems that happen to share an org chart.

The honest call is to build separate systems with shared primitives where it makes sense (accessibility tokens, color science, maybe some foundational components), and stop pretending they're the same system. This is unpopular because it sounds like more work, but it's less work than maintaining the fiction that brands which keep diverging are actually unified.

The right question isn't "can we make this a multi-brand system." It's "is the cost of unifying lower than the cost of keeping them separate." Sometimes it isn't. The system that tries to be everything to multiple brands often ends up being inadequate for all of them.