Turning a CEO-Level Crisis into a New Way of Working

Using a high-pressure moment to prove that designers who get closer to code, powered by AI, create faster and better outcomes.

My Role: Director of UX Product Design. In practice: strategist, first prototyper, infrastructure builder, and trainer.

Core Outcome: Proved a new AI-powered workflow by shipping the solution myself, then scaled it across the team. Prototype-to-test cycles dropped 50%. Multiple high-impact features launched from work that originated in design, not engineering.

Why This Matters (Up Front)

AI is a massive lever for product teams. But most organizations treat it as a novelty or a side experiment. This project proved what happens when you take it seriously: designers who can get closer to code, using AI and modern tools, create value that's hard to argue with.

I didn't pitch this as a transformation initiative. I pitched it as the fastest way to solve a problem the CEO cared about. The transformation was the side effect.

The Situation

A high-visibility feature request was failing. The company's top Coaches have close access to the President, who oversees them directly. Enough complaints about this issue made their way to the President that it escalated to the CEO as well. The conventional response would have been to throw more design cycles at it, iterate through the usual process, and hope to land something acceptable in a few weeks.

I saw a different opportunity. The crisis created urgency and executive attention, which meant I had room to try something that would normally face resistance: fundamentally changing how the design team built and delivered work.

My bet was that if I could solve this specific problem faster and better by using AI to get closer to working code, the results would make the case for changing how the whole team operated.

What I Did

1. Proved it myself first

Before asking anyone else to change how they worked, I led the first project using the new approach.

I partnered with engineering to understand their tech stack so anything I built could hand off cleanly. Then I wrote the initial prototype code myself using AI, producing a realistic, data-populated feature that was ready for user testing in days instead of weeks.

The result: engineering used over 80% of the prototype code in production, which is a big part of why it shipped so fast. But more importantly, it became a concrete example of what was possible when a designer could move from concept to working code without waiting in a handoff queue.

2. Built the infrastructure to make it repeatable

A one-off success isn't useful unless others can do it too. So I built the system that would make this way of working accessible to the whole team.

Migrated our design system to TailwindCSS, in partnership with engineering. This aligned design output with how engineering actually built things, so prototypes weren't throwaway artifacts. They were starting points for production code.

Secured a shared Git repository. This gave designers a centralized place to build, test, and host coded prototypes. A sandbox where they could experiment without risk and where their work was visible to engineering.

Created a prompt template library. Standardized prompts for common tasks like generating mock data, UX copy, and component scaffolding. This lowered the barrier for designers who were new to AI-assisted workflows and kept output quality consistent.

3. Trained the team and made it stick

Infrastructure only works if people use it. I ran training sessions on Git, coding fundamentals, accessibility standards, and how to work effectively with AI tools. The goal wasn't to turn designers into engineers. It was to give them enough technical fluency to build realistic prototypes and hand off work that engineering could actually use.

The cultural shift was important too. I framed this as designers gaining leverage, not taking on extra work. When someone could go from idea to testable prototype in a day instead of waiting two weeks for an engineering sprint, they felt the difference immediately.

Results

This changed how the design team operated and how the rest of the company perceived what design could do.

What This Project Shows

I used a crisis to create an opening for change, then proved the new approach myself before asking anyone else to adopt it. The 50% speed improvement matters, but the real outcome was building a team that could move from idea to working software without the usual bottlenecks.

This is the same pattern across all my work: find the real leverage point, prove it works by doing it, then make it repeatable.