Design Systems · Cross-functional

Unifying a
design system

Untangling three conflicting design systems to build a single source of truth. Short stakes, clear scope, no jargon — just foundations that the whole team could finally trust.

Key outcome
3 conflicting systems → 1 unified foundation
Design Systems Cross-functional Ongoing
⬡
Hero visual — diagram showing 3 systems converging to 1 Best option: a clean Figma frame showing the colour primitive comparison pages. Shows the whole story at a glance. Could also be your colour comparison page screenshot.
Section 2 — The situation
Product context
The app that grew faster than its foundations
Our app was built fast — rushed to market in a way that left significant UX and development debt in its wake. Three separate design systems had emerged over time, each calling different tokens for colour, spacing, and type. New teams had no single source of truth. The problems were visible every day.
flows into
Section 3 — How it started
The conversation that kicked it off
Not a formal brief — a shared problem
It started with a post-release debrief with the head of engineering. No formal handoff, no ticket raised. Just two people recognising the same problem and choosing to own it together. I was asked to evaluate the current state and find a path forward.
Section 4 — The audit
⬜
Image: Figma sandbox — colour primitive comparison
Your chroma mapping or side-by-side colour pages. Shows the scale of the problem and the analytical approach. Place here, early in the work section.
Approach
Colour first, then everything else
I screenshotted every page of the app and brought everything into Figma. Mapped all primitives against the parent company's system. Found a broken theming layer we didn't know existed. Then evaluated in sequence: colour → type → spacing → radius → icons. Working closely with developers throughout, we kept the audit grounded in what was actually in the codebase — not just what was in Figma.
Section 5 — The moment that changed everything
Pivot point
The button that broke the plan
I started on the first component. One button revealed the foundations were compromised — broken token paths, a rogue theming layer, primitives mapped as semantics. I documented everything and reframed the scope. This wasn't a component problem. It was a foundations problem.
Before
Token chaos
Screenshot of the broken mapping — the conflicting tokens, the theming layer mess. Raw is fine here.
After
Rationalised primitives
Your published Figma primitive set. Clean, structured. The visual contrast does the work.
Section 6 — The hard call
Decision
"Slow down to speed up"
I had to frame the debt as a roadmap risk, not just a design problem. Got engineering onside first — they understood the cost better than anyone. Then brought the business along by speaking their language: time saved, consistency gained, reduced regression risk. It took longer to start than I wanted. But it stuck.
"If we don't fix the foundations now, every component we build on top will need to be rebuilt later."
Section 7 — What we built
Figma
Rationalised primitive library. Single source of truth for design. Every token mapped, named consistently, and connected to the codebase.
Storybook
Published and in sync with tokens. Dev reference that matches design — so what engineers see is what ships.
Confluence
Full token documentation. Built for onboarding, not just records — so new team members can understand the system without having to ask.
⬜
Image: Storybook or Confluence screenshot
Even a small crop signals this wasn't just a Figma exercise — it was cross-functional and documented. Place after describing what was built.
Section 8 — The bigger picture
Strategic context
Designing for an uncertain future
Every token decision was made with the acquisition in mind. We knew we'd eventually need to converge with our parent company's design system — but we didn't know when, or on what terms. So I mapped our primitives against theirs from the start, flagging where we'd aligned and where we'd diverge. Parent company alignment now has a clear path. The work is ongoing — and that's the point.
Section 9 — What I took from this
Reflection
The real version
Framing debt as business risk. Keeping momentum with no immediate payoff. Making decisions without full information. The button that broke the plan was the best thing that could have happened — it meant we fixed the actual problem, not the symptom.