IN SHORTOur design system was built for one app. Then it had to carry many: other brands, other platforms, from mobile to TV. On a team of four, we chose a federated model and split the system into three layers so no team has to fork it, and I built a plugin that cut documentation from 3 days to 1. It’s piloting now, with 278+ components and docs and about 700 tokens.
Visuals on this page are recreated to respect confidentiality. The structure and decisions are real; the brand and values are not.
A good house, built for one family.
The old design system worked. It was solid, consistent, and everyone on the main app knew how to use it. But it was built for exactly one product.
As the company grew, other teams started knocking: a second brand, a web portal, a landing page, an internal admin tool. Each time, they had two bad options.
…until they broke.
…and design the same button again.
That was the opportunity. If the system could serve every product from one shared base, new teams wouldn't start from zero — and the company would finally look like one company.
The ask sounded like one thing. It was really three stretches at once — and the hard part was making them work together without “one system” meaning nothing.
Each brand needs its own colour, shape and icon style, without forking the system.
Mobile app, web, and later TV — each with different sizes and rules.
Customer products, and internal tools like CMS that need density, not delight.
Where did components break the moment another product used them? Usually where business logic was baked into what should have been plain UI.
Designers kept describing the same tension: the rules kept things consistent, but blocked anything new.
Google, Kayak, Ford and Superlógica all run multi-brand systems. We studied how they layer tokens and keep a shared core.
The consistency-versus-flexibility paradox.
I led a brainstorm to turn the research into one sentence the team could commit to: every brand and platform built from a single shared base, while each product keeps its own identity. That meant four requirements.
Different identities and technical rules on the same base.
Teams set local tokens without touching the global base.
No business logic baked in, so components travel between products.
For assets several teams use, but that aren't universal enough for the base.
Before any tokens or components, we had to decide how the system would be run. Everything else depends on it.
Each product runs its own system. No central team.
Where it breaks: Everyone reinvents the same things; consistency drifts.
One central team owns the system for every product.
Where it breaks: The team becomes a bottleneck, far from each product's needs.
A central team owns the shared core; a DS designer in each product owns its local layer.
Where it breaks: Needs clear rules on who decides what.
We chose the hybrid: the central team gets time to build the shared core, and each product’s design system designer knows its users far better than we could. The cost is coordination, and that’s what the structure is for.
The answer was a structure in three tiers, each with a clear owner.
We started with two: a pure base, and each product on top. But some things, like shared icon sets and brand logos, kept falling between them. So we added Center: shared, but not universal.
Base tokens are the full pool, primitives are raw values, semantic tokens say what they're for. One brand can be blue and another orange without a single component changing.
The old system sorted colours by type: primary, secondary, tertiary. But a designer never thinks “I need a secondary colour”; they think “I need a background for this card”. So we grouped colours by where they go.
“Which one is secondary again?”
“I need a background” → open Background.
Icons rebuilt in several styles, so each product keeps its character while drawing from one library.
Whenever a designer needed something a component didn’t offer, they detached it, and the copy stopped receiving updates. Multiply that across products and a system slowly stops being a system.
Around the same time, Figma shipped two features that fit the problem exactly: slots, so a component can leave space for custom content and stay connected, and extended collections, so a product can extend the base variables instead of copying them.
Custom content means breaking the link. Library updates never arrive. Brand values get copied and drift.
Custom content goes in the slot. Updates still flow through. Brand values sit in an extended collection on top of the base.
With more than 278 components, each needing its own page, writing documentation by hand was slow — and pages drifted the moment a component changed. So I built a Figma plugin, CML Doc Generator. Select a component, run it, and it generates a structured doc page in the same layout every time.
It took several versions: Figma’s plugin API is strict about auto layout, and most of the work was making generated pages look hand-made.
Now the docs follow the components, instead of chasing them.
A system only exists if developers can build with it, so we didn’t wait until the end to show them. While we were still shaping the tokens, foundations and components, we checked with developers how each piece should be structured: how to name things, how components are put together, and whether a behaviour we wanted was actually buildable. By handoff, every Figma token matched a variable in code one-to-one. Two of those conversations:
“These names are too long to type fifty times a day.”
Lighter, faster to implement, and much less guessing for the people building it.
“Cards come in many sizes. Can each one have its own corner radius?”
Developers built a quick proof of concept and confirmed it worked, before we committed to it in the design. Asking first meant no promise the code couldn’t keep.
I’d been helping the TV team with concepts, and they asked for the system to reach TV too, so they wouldn’t maintain a separate one. TV is a different world: people sit far away and move one step at a time with a remote. No tapping, only focus.
The hardest question was focus: fill it, outline it, or make it bigger? Good TV apps use all three. The answer came from what each component actually is.
Posters and cards have room around them. Growing makes the picture the hero.
Buttons, tabs and menus sit in tight rows. Enlarging them would push their neighbours.
One rule per kind of component, not one rule for everything.
Because the layers were already there, TV slotted in as its own product kit on the same base — not a second system to maintain.
Two projects are piloting the system. Real products found real gaps, and some parts are being adjusted. That’s what a pilot is for.
The hybrid model was built for exactly this: product teams bring requests, the central team decides where they live.
Min and max sizes for components, and how many lines text runs before it truncates. Real content is messier than our specs.
A new component, logo or icon — each sorted into Base, Center or the product's own kit.
Teams ask how to use something the right way. Every question points at a gap in the docs, and goes back into them.
A new product starts from the kit, not from zero.
The signal I'd watch is how long it takes a new team to ship its first screen, and how few components get detached along the way.
I rewrote the timeline two or three times, and it still slipped — urgent product work kept cutting in, and I wasn't firm enough about protecting the plan. Next time I'd agree up front what is allowed to interrupt, and say no to the rest.
Some of our best decisions came from Figma's limits, and from its new features. Knowing the tool deeply is how a system survives daily use.
Every unexpected case from the pilots made the system better. Governance isn't a rulebook; it's how teams ask for change.
A design system isn't finished when it's built. It's finished when the next team doesn't have to start from zero.