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.
How it started
The conversation that kicked it off
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.
The audit
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.
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.
After
Rationalised primitives
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 by framing the debt as a roadmap risk rather than a design problem, the decision stuck — and we didn't have to revisit it.
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.
Outcome
On the first release after publishing, UI inconsistency tickets dropped by 30% — flagged by the engineering lead as a direct result of having a stable token foundation. Design QA time increased too, but in the right direction: the team now had a shared language to actually interrogate consistency, creating visibility that hadn't existed before. The PM noted that the first publication of Figma, Storybook, and Confluence in sync was the first time he'd properly understood how the design system worked — a cross-functional clarity win that showed up in how the whole team talked about components from that point on.
The new library has fewer components than the old one — intentionally. The goal was atomic foundations that other teams could build on, not a system only we could maintain.
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.
What I took from this
Framing debt as business risk got the room onside. Keeping momentum with no immediate payoff was the harder part. And the button that broke the plan was the best thing that could have happened — it meant we fixed the actual problem, not the symptom.