March 2, 2026
We stopped handing off Figma files and started handing off working prototypes. Here's the workflow that made that possible and what it changed about how we design.
The problem with traditional handoff
The pipeline worked. The design file didn't speak its language.
Every traditional handoff has a translation layer… the gap between what the designer meant and what the engineer builds. Redlines help. Annotations help. But neither of them is the thing.
AI changed the equation. If a model can read a well-structured design file and generate working UI code, the handoff artifact doesn't have to be documentation anymore. It can be software.
The system
Five design inputs. One production build.
Understanding the full pipeline shaped every decision. My scope was the design inputs — the FE pipeline consumed them.
Technique 01
Redesigned FigJam nodes as structured data objects, not labels
A box labeled "Dashboard" tells a human enough. A machine needs a schema.
Screen name: human-readable title of the view
Route path: the URL route this screen maps to
Frame link: direct link to the corresponding Figma frame
Description: plain-language context for what this screen does
Technique 02
Organized the Figma file to mirror the codebase directory
Sections named by route path. Frames named by state. A 1:1 match across FigJam, Figma, and the codebase — no interpretation required.
Technique 03
Every interactive element got an element ID in its layer name
When the FigJam node references #createNewButton, that exact string exists in the Figma layer panel. The MCP server queries by ID and gets one unambiguous result.
Technique 04
Generated the PRD directly from the design file
Because the file was structured correctly, the PRD could be extracted rather than written. That eliminated the transcription layer where human error normally lives.
FigJam flow + Figma frames → Figma Make
Validate prototype output matches design intent
Copilot generates a custom PRD extraction prompt
Prompt → Figma Make → structured PRD output
PRD feeds into the template repository as the first input to the staged pipeline
05
Understanding the Staged
Prompting Pipeline
One of the most important things I had to wrap my head around as the designer was how the FE's build process actually worked, because it directly shaped every design decision I made…
aside from that fact I found it pretty cool.
— Rather than asking the LLM to generate the entire product in a single prompt, the build process was deliberately broken into discrete, sequential stages.
06
MCP for Live Design Context
Beyond the PRD, we connected an MCP (Model Context Protocol) server directly to the Figma file to give the LLM a live query channel into our design at build time rather than relying on a static export.
What this enabled on the design side:
The AI could pull frame data, component states, and element IDs in real time
Route structure and naming conventions became a queryable schema, so hard file hygiene became a requirement.
What this changed about
how we ship
Zero
Transcription errors between design intent and AI input created a lossless handoff.
1:1
Parity between Figjam node names, Figma layer names, and code element IDs across the full pipeline.
Live
Design file became a real-time data source via MCP — not a static export that goes stale overnight
Full
End-to-end loop from design file → prototype → PRD → production build, no manual re-entry
// What's next
Exploring automated PRD validation against the design file via MCP
Considering whether the FigJam flow could be AI-generated from a brief rather than hand-authored
Document conventions as onboarding material so that any new designer should be able to adopt this on day one
Confidential — all proprietary tooling, product names & visuals omitted