From Prototyping to Production: A UX Workflow That Scales
How I bridge the gap between Figma prototypes and shipped products. The tools, handoff process, and iteration cycles that keep design and dev aligned.
The gap between a Figma prototype and a shipped product is where most design intent dies. A prototype looks perfect because it has no edge cases, no loading states, no errors, no empty data. Production has all of those. The workflow that bridges the gap is what separates a designer who ships from one who hands off a file.
Prototype the unhappy paths
Most prototypes show the happy path: a user with a full cart, a fast connection, and existing data. I prototype the unhappy paths first. Empty state. Error state. Loading state. Offline. These are the states that define whether a product feels considered or thrown together. If you only design the happy path, engineering will fill the unhappy ones, and they will fill them badly.
- Empty: no data yet, what does the user do first?
- Loading: skeleton, spinner, or progressive reveal?
- Error: what went wrong, in plain language, with a next step.
- Partial: 3 of 10 items loaded, show them now.
- Offline: what still works without a connection?
Handoff is a conversation, not a file
A Figma link in a Slack message is not handoff. Handoff is a 30-minute walk-through where I explain the why behind decisions, the engineer asks about edge cases, and we agree on what is a hard constraint versus a suggestion. The file is the artifact. The conversation is the handoff.
If the first time an engineer sees your design is the Figma link, you have already lost the edge cases.
Iterate in production, not in Figma
Once a feature is shipped, the real feedback starts. Users click the wrong thing, miss the button, fill the form wrong. That feedback is invisible in Figma. I keep a short cycle: ship, watch real usage for a week, adjust, ship again. The prototype was a hypothesis. Production is the experiment.