A design system doesn't live in Figma: it lives wherever developers pull from. So I stopped handing over files and drove the system into the codebase itself.
Give a fragmented platform a single source of truth, and, harder, get it adopted across a dev team shipping features on old components, because updating UI was on nobody's roadmap. The stakeholder brief was 'make the platform feel modern.' For a product sold to institutional investors, that brief isn't cosmetic: a dated, inconsistent UI quietly undercuts credibility with exactly the buyers it's trying to win. The real job was closing the gap between a design system that existed and a product that ignored it.
We didn't have no system. We had a system that died at the repo boundary.
We'd built style guides and a Figma component library. But the moment design shipped a new card, grid, or dropdown, it went nowhere: the 8 developers kept pulling old components straight from their repo, because functionality was the priority and UI never made the roadmap. Two designers produced a modern system; eight developers each reached for whatever was already in code. New components in some places, old in others, consistency nowhere.
That asymmetry made drift structural, not sloppy. And it surfaced hardest at handoff. With the prototype saying one thing and the repo saying another, every handoff became a reconciliation problem: is this the new card, or the one already in code? Developers weren't confused because the designs were unclear. They were confused because there was no single source of truth to build against, the exact thing a design system is supposed to be. The blast radius was the platform's spine: grids, dropdowns, icons, sections, cards, backgrounds, breadcrumbs, tags, across a product serving fund managers and investors.
Handing over Figma files hadn’t worked, so I stopped treating this as a design problem and went looking for the root cause in their code. What I found explained everything: components were hardcoded in some places and built as ad-hoc parent components in others. There was no shared foundation to update, so a redesign in Figma had nothing to attach to on the dev side.
That reframed the whole effort. This was never “make a better library.” It was “give the codebase a spine, then drive the system in one component at a time, at every place it’s used.” I inventoried the drift (colours, buttons, type styles, spacing), mapped old-vs-new usage across screens, and used it to plan the rollout, not to decorate a deck.
There was nothing shared to update against, so a redesign in Figma had nowhere to land until the codebase had its own spine.
A single 'redesign everything' story would never get scheduled against a team shipping features on old components.
Figma files alone had already failed to move anyone. Whatever came next had to work without opening Figma.
I attacked the adoption gap from both ends. From the code side: a per-component rollout engineered around how the platform was actually built. From the source-of-truth side: a machine-readable design spec that let the system be consumed by anyone, dev or PM, without opening Figma. The spec is what finally crossed the boundary a component library never could.
I drove the strategy, the variable/token architecture, the button system, the spec, dev ideation and implementation discussions, design reviews, and gap-tracking. A supporting designer maintained the system and helped surface gaps under me.
A modern system lived in Figma, an old product lived in production. Developers pulled from their repo; new and old components collided across screens; handoffs stalled on which source to trust; spacing, padding, and type were all over the place, even with the Figma files in hand.
A tokenised system rolled into the codebase one core component at a time, backed by a spec developers could integrate and PMs could build from, so consistency landed in production, not just in design files.
I rebuilt the foundation as structured variables, colour, corner radius, spacing, typography, so the platform could inherit one source of truth instead of a catalogue of one-offs. This is the layer everything else attaches to.
The diagnosis set the strategy. Because components were hardcoded and ad-hoc, I couldn’t just publish a library and wait, I had to drive each one in. Rather than pitch one enormous “update the whole UI” story that would never clear the roadmap, I sequenced the system into the work: for each core component (grids, icons, typography, labels) I created a Jira story that mapped every place it was used so it could be updated app-wide, then squeezed those stories into the feature stream the team was already committed to. 8 component stories, 50-80 screens of impact, run in monthly stints. Directionally it worked: developers started pulling the correct components, and the UI began updating in production.
Each gap became a Jira story that mapped every usage site, so a component updated everywhere at once, not screen by screen.
The move that crossed the boundary. I built a design-guideline spec in Claude that encoded the system in a format non-designers and machines could build from: hex values with when-to-use rules, radii, spacing, typography, background and alert/message types, the full tags-and-labels system (neutral vs. status, size variants), icon sizes, tooltips, a dedicated AI colour palette (purple) so AI features stayed on-brand, and AG Grid specs, precisely what dev kept getting wrong. Screenshots gave it intent, not just values. Developers integrated it into code to get spacing, padding, and type right; PMs used it to generate on-brand mockups on their own.
The design system as a spec, not a screen, encoded so a developer could integrate it and a PM could build from it without opening Figma.
A 2-person design team can’t sit in every early conversation. The spec meant it didn’t have to. PMs began handling roughly 60% of early concepts themselves, real mockups instead of rough sketches and soft PRDs, freeing design for the complex, flow-heavy work (agentic AI, involved due-diligence functionality). Iteration compressed: three real variations fast, where before it was low-fi wireframes. And stakeholder approvals sped up, because live mockups landed where rough designs left people squinting.
Beyond the numbers: the system stopped dying at handoff and started landing in production, and the design team’s time shifted from firefighting early ideation to the high-intervention work that actually needed a designer.
(The mockup and PM-concept figures are behavioural estimates from watching the team’s workflow shift, not instrumented analytics.)
The lesson was about timing and escalation, not craft. I always knew the gap existed. It was organizational (a hard-to-reach dev team, UI off the roadmap), not a design-quality problem. Next time I’d surface that structural gap to leadership far sooner, and start the per-component rollout in smaller, earlier stints instead of carrying multiple threads at once. The system was never the hard part. Getting the org to treat adoption as a shared responsibility was, and that’s the conversation I’d force earlier.