Most design systems begin with good intentions: one product, one brand, and one set of components built to support a team that moves fast.

But a scaling org doesn’t care about your system’s good intentions.

Over time, new needs emerge. New teams, new domains, new visual expressions. Your original brand pushes in one direction, but a new one pushes in another. What once felt clear now feels fragile. People start asking:

“Do we need a separate system for that?”

The instinct is to fork. To duplicate. To build a system per brand, per team, per use case. But this only leads to entropy: systems drift, ownership blurs, and adoption drops.

I’ve seen this pattern unfold inside fast-moving orgs and helped teams avoid (or recover from) the fork trap. What worked wasn’t “more rules” or “better tokens.” It was shifting the architecture from a single source of truth to a connected network of systems, each built with purpose, and all linked by a shared foundation.

The fork temptation

It usually starts small. Someone adds a few overrides for a brand variant. A theme gets stitched onto the main codebase. Tokens get copied, renamed, and overridden. It works, for a while, until it doesn’t.

I recently worked on a project that tackled exactly this: multiple brands and teams were expanding simultaneously, each needing their own voice, each pushing against a centralised system that couldn’t bend without breaking.

They didn’t need two systems; they needed alignment and clarity.

We stepped back and audited what was shared. We separated structure from style and shifted from a single stretched system to multiple domain-specific systems, all aligned through tokens and intent.

Here’s how it worked.

A better model: Shared systems, not silos

The scalable model isn’t one bloated system with endless theming.

It’s multiple focused systems, such as Product and Marketing. Each spanning their different brands, built for their respective contexts, and all connected by a shared foundation.

Think of it like this:

  • Start with a foundation: colours, spacing, typography, motion, iconography, illustrations, font files, photography
  • Layer on semantic tokens where they diverge: system-specific meaning on top of shared values
  • Build domain-specific components: each using its own semantic token set as well as the foundations
  • Connect everything via a governance layer: shared naming, guidance, comms, and structure

Avoid forking by building a framework.

Step 1: Audit what’s already shared

Before changing anything, audit what you’ve already got.

In the case I mentioned, we found that each system was using the same colour library, but diverging in typography and spacing. Although they were fundamentally the same in that they used the same typeface, one of the systems had more styles and employed different semantic naming. This led to duplicated tokens and an overall struggle to map decisions across systems or switch between brands seamlessly.

What we did instead:

  • Defined core design primitives without attaching meaning derived from the foundations across both systems and brands
  • Made it visible what was truly shared vs what was being improvised

👉 Tip: Start by mapping colour values across systems. It’s often the clearest overlap.

Step 2: Create system-specific semantic tokens

Here’s where most teams trip up: they try to define one set of semantic tokens for every brand or system.

But meaning depends on context.

The exact value might serve as a primary button background in Product and a secondary callout in Editorial. That’s why each system needs its own semantic layer, even if it uses the same base values.

These layers also allow for multi-brand theming within a central system. For example, if both of your systems support both brand A and brand B, semantic layering makes it easy to extend meaning without breaking structure.

Step 3: Let each system express itself without duplication

Once the semantics are clear, each system can express its needs visually and structurally without duplicating effort.

We didn’t create separate sets of components for each system; doing so would have undermined the whole setup. Instead, we built and maintained a centralised component library, treated as part of the system foundations. These components were flexible enough to support multiple use cases, thanks to the semantic tokens and system-specific type libraries that fed into them.

Each team (Product, Editorial, or beyond) could pull from this shared foundation of icons, illustrations, font files, base components and extend them through their patterns and semantic layers.

What makes this scalable isn’t duplication, it’salignment: shared structure, shared naming, and token flexibility that allows each team to work the way they needed.

✨ If your component library is full of conditionals, you don’t need more components; you need clearer semantic separation.

Step 4: Use a central layer to connect, not control

We didn’t centralise ownership, we centralised structure.

  • Naming patterns across domains
  • Rules for introducing new tokens
  • The shared design primitives library (including icons, colour values, photography guidelines)
  • Documentation and onboarding for all systems

That small connective layer allowed each domain team to move fast, build confidently, and still stay aligned.

What made this sustainable

The success of this setup wasn’t just in the structure; it was in how the teams operated within it. Systems didn’t just co-exist; they grew in parallel, learning from each other, sharing back improvements, and leaning on the shared core without being limited by it. This approach unlocked faster iteration, clearer ownership, and ultimately, stronger outcomes across both brands.

  • We didn’t try to future-proof everything; we designed for the current need, with a structure that could adapt
  • We avoided decision bottlenecks by giving each system autonomy
  • We connected systems through purpose, not visuals, meaning they could flex without breaking
  • We reduced duplication by defining ownership, not by enforcing centralisation
  • We separated foundations from semantics, and semantics from component implementation

The result

Instead of one bloated system or two disconnected forks, we built a networked system structure:

  • Editorial could move at campaign speed across both brands
  • Product had a clean, stable component set that scaled between personal and business contexts
  • And everyone spoke the same design language

Because everything started with shared foundations, not shared assumptions.

If you’re facing this now…

You don’t need to rebuild each time, you need:

✅ A clear audit of what’s shared✅ A token model that allows flexibility and meaning per system✅ Domain-specific systems, not just brand themes✅ A governance layer that supports autonomy, not control

Want to see this applied in practice?Here’s the full case study of how I did this at Wise →