The handoff stopped being a file.
Part One ended on an open question: what happens when design’s code meets the production codebase? Here is the answer. Engineering wrote the production spec for the policy page from the working prototype, and the first production pull request merged behind a feature flag. Somewhere along the way, the method stopped being mine. All three of our PMs now start their projects by building something you can click.
- Role
- Senior Product Designer
- Timeline
- May – Oct 2026
- Team
- Three PMs, a UI designer, engineering
- Surfaces
- Agency onboarding · Policy page · Underwriting workbench
- 3 of 3 PMs prototyping their own requirements
- 3 projects through the full workflow
- roughly a quarter versus roughly a month
- first production PR merged behind a feature flag
Everyone was building alone
By spring, AI had made everyone on our team a builder. One PM was prototyping in Figma Make before she’d finished onboarding; she used it in her hiring exercise. Another built a working agency-onboarding app in Cursor. I was building in Claude, and I had failures to show for it: a launch-monitoring app that reported confidently and wrongly for three weeks before I shut it down, and an automated UI-review tool that looked like it saved notes and progress until we noticed it was a static page.
Agency onboarding was the clearest picture of the moment. One idea passed through four pairs of hands: the PM’s working app, my redesign, the UI designer’s polish, and two engineers who rebuilt it in the approved stack and hardened it for production. It shipped on August 5. It also got built four times, and in our own retro I called the parallel prototypes what they were: a mess.
Speed hadn’t removed the handoffs. It had made more of them, faster.
What the old process cost
The useful comparison isn’t old tools against new ones. In 2025 we had Figma Make on an agent quote-builder project too. It was a side sketch; static mocks were the plan of record.
That project’s central interaction — modules that collapsed into accordions — went to engineering as static screens. The trouble surfaced in the first days of the build, when the questions only an engineer asks (what does Back do? what happens to a half-edited module?) met a data model that couldn’t support the answers. By then the accordion component existed. It was struck from the spec, the tickets were re-cut, and the ship date moved out.
Nobody did anything wrong. The process asked its hardest questions last, after the cheapest moment to answer them had passed.
Part One measured the difference in pace: roughly a quarter versus roughly a month. This part is about where the questions moved.
The workflow that came out of it
Five stages. Each has an owner, and each hands the next one something it can click.
| Stage | Owner | Gate |
|---|---|---|
| The PM makes the requirement clickable. In whatever the PM thinks in — Figma Make, Cursor. | PM | Stakeholders have clicked it, not read about it. |
| We decide inside it. Product and design settle disagreements by clicking through the options instead of describing them. | PM + design | Each decision is written down, once. |
| Figma becomes the source of truth. The UI designer and I turn the agreed direction into the system. | Design + UI | The prototype never runs ahead of Figma for long — a rule we adopted the week it did. |
| I build working software on production shapes. Fictional data in the platform’s real wire format, every documented state reachable, tests as the contract. | Design | Nothing merges without the tests. |
| Engineering builds from it. Engineering owns architecture, security and the production stack. The prototype is the reference, not the code that ships. | Engineering | Their spec, their review. |
Stage five is built around engineering’s own position, not against it. Engineering had already set its terms for AI prototypes: useful as requirements, not production software. I agreed, and designed the handoff to respect it.
Every stage hands the next one something it can click, not something it has to interpret.
Three runs
| Stage | Agency onboarding | Policy page | Underwriting workbench |
|---|---|---|---|
| Made clickable | PM’s working app (Cursor) | PM’s structure spec → my first working version | PM’s Figma Make file |
| Decided inside it | With the agency team | With product, underwriting and servicing | With underwriting stakeholders |
| Source of truth | UI designer’s Figma | Figma, with a written protocol | UI designer’s Figma |
| Working software | My redesign; six of my commits merged in the production repo | The policy-page prototype (Part One) | A display layer built to the production team’s conventions |
| Engineering | Rebuilt and hardened | Spec written from the prototype | Adoption manifest delivered |
| Status | Live · Aug 5 | First PR merged behind a flag | Production UI queued behind an unrelated migration |
Agency onboarding was the first run, before any of the rules existed. It shipped — and it’s where design first contributed code to a production repository: six small UI commits, reviewed and merged by engineering.
The policy page was the run with the rules in place. Decisions about tab structure, banner behaviour and where billing lives were settled in the prototype before a spec existed. Sign-off was requested on September 9 with the prototype as the reference.
The underwriting workbench started with a PM’s Figma Make file, validated with underwriting stakeholders before anything went into Figma. The display layer I built for it ships with a manifest for the engineer who takes it: what to adopt, what to delete, where the seams are.
Run once, it’s a project. Run three times, by different PMs, on surfaces that share nothing but the method, it’s how the team works.
Engineering inherited it
The engineer who owns the production build wrote the policy page’s technical spec from the prototype. The tabs arrived in the same order. The banner inventory arrived word for word. So did the billing vocabulary and the ledger’s display rules, down to example amounts taken from the prototype’s fictional policies. The first production pull request — the page shell, the tab registry and all nine tabs — merged behind a feature flag, with an opt-in rollout that keeps the old page one click away, as the prototype proposed.
What engineering did not take was the code, and that was the design. They rebuilt the page in the production stack, on their own architecture. The prototype settled what the page does. Engineering owns how it runs.
The underwriting workbench went further toward shared code, under the agreement described in Part One: design authors the display components in the production team’s conventions; their pod owns the data wiring and the review. The first handoff is delivered. The production UI is waiting on a rules-engine migration, not on design.
The prototype-to-spec comparison, line by line, is on the Policy Page →
A good handoff isn’t a file engineering accepts. It’s a decision engineering doesn’t have to make again.
It stopped being mine
All three of our PMs now prototype their own requirements.
One of them pioneered it, before I’d used the tool; when I needed to move work from Figma Make into Figma, I asked her how. Another prototyped a transfers workflow on his own and brought me in to set the patterns. The third ran discovery for a new agent portal by exploring around twenty concepts with me — and the decision that came out of it was not to build a new app. It was to test the smallest piece first, against a baseline: a median of 29 days from an agent’s first login to their first quote.
In October, a PM, two engineers and I presented the approach to the whole product and engineering department. We called it Breaking the Handoff.
| What I built | What others built |
|---|---|
| The path between the stages, and the rules that hold it together | The first Figma Make experiments, by a PM |
| The Line, one public queue for all design work (Part One) | Every product decision; the PMs ruled |
| Working prototypes on production data shapes | Final UI, by the UI designer |
| The adoption agreements with engineering | Production code, by engineering |
I didn’t introduce the tool. I built the road between the people already using it.
What isn’t measured yet
This case study keeps shipped and planned in separate sentences, on purpose.
- Rework in the production build. Not measured. The policy page hasn’t launched.
- The policy page’s real scoreboard. Before the redesign, the page drew about 20,000 visits a month, and agents wrote in 60+ times a week about billing, about 30 about cancellations and about 9 about renewals. Those counts after launch are the test.
- The agent portal. The 29-day baseline exists; the experiment hasn’t run.
- Workbench code reuse. Agreed and delivered to the first handoff; not yet merged in production.
The prototypes got fast. The scoreboard is next.
What I learned
AI sped up the artifacts — the requirements, the mocks, the build. It didn’t speed up the agreement. That still takes the right people looking at the same thing, early.
So the design job moved in two directions at once. Upstream, into helping PMs think in prototypes instead of documents. Downstream, into producing something engineering can build from without reinterpreting it. The middle — drawing screens to describe a product someone else will imagine — got smaller.
What’s next is convergence: the prototype’s components mapped to the production library, a drift monitor watching parity between what design decided and what production renders, and the numbers above, measured.
Design as the governing function of a delivery organization.