Rebuilding trust at scale

The problem

When I joined, the design team and the engineering teams were all 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.

Documentation lived in scattered Confluence pages and outdated PDFs. Because design work wasn't connected to how the codebase was actually structured, developers had learned to work around us rather than with us.

That dynamic became my brief.

The environment

The platform 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 with no room for slow feedback loops or rework cycles.

The design team was large. Around 20 designers supporting 30+ development teams, fully remote, across multiple contractor firms. Each contractor had separate reporting lines and working norms. There was no standing forum for cross-functional work. Every decision that crossed org lines required ad hoc negotiation.

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, one slice of a very large product. But the systemic problems weren't confined to my slice. Staying in my lane while the broader dysfunction compounded didn't feel like an option.

I embedded myself in developer channels and planning sessions. Not to insert design opinions. To listen. That earned enough trust to start proposing changes. I advocated for structured focus areas within the design team and took on Operations and Tooling myself, where my frontend knowledge gave me credibility to bridge the gap between design workflow and engineering reality. My scope expanded from that focus area to leading the entire UX team.

That's not a typical path to design leadership. But it's the one that made the work that followed possible.

The work

1. Change management

   Moving the team without stopping the ship

   Migrating 20 designers and 30+ dev teams from Axure to Figma. Everyone was heads-down on a nationally critical application at the time. Rather than mandate a switch, I made the transition opt-in and incremental. Adoption by proof, not policy.

2. Design system

   Building the design system from the codebase up

   I led a thorough audit of the frontend: thousands of lines of code and style files, reviewed collaboratively with designers and engineers. What emerged was a clear picture of where inconsistencies lived and where a token-based system could create genuine leverage.

3. Structural fix

   The chapter model: making cross-functional work stick

   A biweekly working group co-led with the tech lead, with a live shared agenda. The chapter gave design and engineering a consistent forum: cross-contractor, cross-discipline, solving problems together instead of around each other.

Outcomes

The metrics tell part of the story. Design-system-compliant screens went from approximately 35% to 75%. Defects in QA dropped by half. Developer onboarding sped up by 30%. CSS payload shrank by 20%. But the number that mattered most wasn't in any dashboard.

When I joined, design wasn't trusted as a problem-solving function. By the time I left, it was embedded in engineering planning and seen as a strategic contributor. Not a delivery bottleneck.

The chapter model was running independently. Engineers were defaulting to the design system. The shift didn't happen because of tooling. It happened because we rebuilt the relationship between two teams who needed each other and didn't know how to work together yet.