The Problem
When I joined, the design team and the engineering team were both working hard and getting in each other's way.
Designers were producing work that didn't map to the actual codebase. Developers were too busy shipping to explain why. The result was a steady accumulation of impractical designs, frustrated engineers making UX decisions without input, and a growing sense on both sides that the other team simply didn't get it.
I had a candid conversation with a tech lead early on that made the dynamic concrete. The designers couldn't keep up. The developers didn't have time to close the gap. And nobody knew how to make a meaningful impact on a platform that 20,000+ people depended on every day.
That conversation became my brief.
The Environment
The platform itself raised the stakes considerably. It processes 85% of all US immigration and asylum cases — a nationally critical system used by 20,000+ people daily, many of them making consequential decisions about people's lives. It ran on continuous deployment, meaning teams were shipping to production constantly. There was no room for slow feedback loops or rework cycles.
The design team was large by any standard — around 20 designers supporting 30+ development teams across a fully remote organisation. But size wasn't the advantage it sounds like. Without shared focus areas, tooling, or process, a large team can fragment just as easily as a small one. Ours had.
Designers worked in Axure — a tool that didn't reflect the actual frontend architecture. Documentation lived in scattered Confluence pages and outdated PDFs. There was no single source of truth. And because design work wasn't connected to how the codebase was actually structured, developers had learned to work around us rather than with us.
The trust deficit wasn't personal. It was structural. And structural problems don't get fixed by working harder — they get fixed by changing the system.
My Role
I joined as a senior individual contributor — one designer responsible for one slice of a very large product. That was the job.
But the systemic problems I described weren't confined to my slice. They were everywhere. And staying in my lane while the broader dysfunction compounded didn't feel like an option.
So I started looking beyond my immediate scope. I embedded myself in developer channels and planning sessions — not to insert design opinions, but to listen. I wanted to understand what was actually slowing people down, and I wanted developers to see that at least one designer was genuinely curious about their world.
That earned enough trust to start proposing changes. I advocated for structured focus areas within the design team — a way to reduce chaos and create clearer ownership. I took on the Operations and Tooling focus area myself, where my frontend knowledge gave me credibility to bridge the gap between design workflow and engineering reality.
The work gained traction. My scope expanded — first to leading the Operations focus area, then to leading the entire UX team. By the time I was responsible for the whole practice, I had already spent months on the ground understanding exactly where the friction lived.
That's not a typical path to design leadership. But it's the one that made the work that followed possible.
The Work
Moving the team without stopping the ship
The first challenge wasn't design — it was change management. Migrating 20 designers and 30+ development teams from Axure to Figma sounds straightforward. In practice, everyone involved was heads-down shipping a nationally critical application. Nobody had slack in their schedule for a tooling transition, and nobody was going to prioritise it unless they could see a direct benefit to their own work.
So rather than mandate a switch, I made the transition something people could opt into incrementally. I worked change into the edges of existing workflows — starting with the teams most frustrated with the status quo, demonstrating wins early, and letting adoption build through proof rather than policy. It took patience and consistent forward motion over months, but it landed with genuine buy-in rather than reluctant compliance.
Building the design system from the codebase up
Once we had shared tooling, the deeper problem became visible: design work still wasn't connected to how the frontend was actually built. To fix that, I needed to understand the codebase — not as a developer, but well enough to design with it rather than against it.
I led a thorough audit of the frontend — thousands of lines of code and style files, reviewed collaboratively with both designers and engineers. As AI tooling became available, I used it to accelerate the analysis. What emerged was a clear picture of where inconsistencies lived, where hardcoded values were creating maintenance bottlenecks, and where a token-based system could create genuine leverage.
I developed the CSS token strategy myself — grounded in industry best practices, shaped by what similar organisations had done, and tested against our specific constraints through research, workshops, and deliberate trial and error. The goal wasn't a perfect system on paper. It was a system developers would actually adopt.
The chapter model: making cross-functional work stick
Tooling and systems were necessary. But the deeper problem — the trust deficit between design and engineering — needed a structural solution, not just better artifacts.
I established a cross-functional chapter: a biweekly working group co-led by myself and the tech lead, with a live working agenda that tracked our shared initiative. The chapter gave design and engineering a consistent forum to solve problems together rather than around each other. It created shared ownership of outcomes. And it turned what had been a fragmented, reactive relationship into a collaborative one with real momentum.
As the application scaled — taking on more users, more complexity, more deployment pressure — the chapter became the mechanism that kept design and engineering moving in the same direction.
Outcomes
The metrics tell part of the story. Fewer defects in QA, faster developer onboarding, a smaller CSS payload, near-universal developer adoption, faster component migration, and a dramatic reduction in UI inconsistencies across the platform.
But the number that mattered most wasn't in any dashboard.
When I joined, design wasn't trusted as a problem-solving function. Developers worked around us. Designers worked in isolation. By the time I left, design was embedded in engineering planning, the chapter model was running independently, and UX was seen as a strategic contributor — not a delivery bottleneck. That shift didn't happen because of a design system. It happened because we rebuilt the relationship between two teams who needed each other and didn't know how to work together yet.
What I Learned
The biggest lesson wasn't about design systems or tooling. It was about where leverage actually lives in a complex organisation.
You can have the right process, the right tools, and the right instincts — and still make no impact if the people around you don't trust that design is worth investing in. Building that trust, especially in an environment under pressure, requires something design school doesn't teach: the patience to listen before you propose, the diplomacy to bring sceptics along, and the willingness to make other people's problems your own before you ask them to make yours theirs.
I also learned that I work best at the intersection of design and engineering — not as a developer, but as someone who understands enough about how things are built to have credible conversations with the people building them. That's what I'm continuing to develop. It's why I sought out Checkly after years in government work. And it's the kind of environment I'm looking for next.