The moment finalised designs pass to engineering is one of the biggest sources of rework in all of product. The reason is structural: engineers can't read a designer's mind, and a design that omits states and edge cases gets guessed at.
▸ Try the interactive toolThe design-to-engineering handoff — the moment finalised designs pass from the designer to the engineers who build them — is one of the most common sources of quality issues and rework in all of product development. The reason is structural: engineers can't read a designer's mind, and a design that omits states and edge cases will be guessed at — usually wrong.
A great handoff is complete: it specifies not just the happy-path 'normal' screen but every state — loading, empty, error, success, disabled, hover, the very long text, the very short text, the slow connection. The gap between a designer's mental model (which includes all these) and what's actually drawn (often just the ideal state) is where rework lives. The PM's role is to ensure the handoff is genuinely complete before engineering starts, and to facilitate the conversation that catches the gaps — because the cheapest place to handle an edge case is in the design, not in a bug ticket.
Not just the ideal screen, but every state: loading, empty, error, success, disabled, hover/active, plus edge cases — long/short text, slow connections, boundary inputs. The states the designer pictured but didn't draw are where rework comes from.
A handoff that shows only the happy-path design forces engineers to invent the missing states — and their guesses surface as inconsistency and rework.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Happy-path-only designs | Engineers guess the loading, empty, and error states — usually wrong. | A complete handoff specifies every state, removing the guesswork. |
| Mind-reading expected | The designer's mental model isn't on the canvas; engineers can't see it. | Making every state explicit closes the model-vs-drawing gap. |
| Edge cases as bugs | Unhandled cases surface in QA or production as rework. | Catching them in the design is far cheaper than fixing them later. |
| No handoff conversation | Designs thrown over the wall with no dialogue. | A facilitated handoff conversation surfaces the gaps early. |
Before handoff, ensure the design covers loading, empty, error, success, disabled, and edge states — not just the ideal screen. The missing states are the rework waiting to happen.
Push on the boundaries: very long text, very short text, no data, too much data, slow connections, failures. These are exactly what a happy-path design omits and engineers will otherwise guess.
Don't let designs be thrown over the wall. Get designer and engineers talking through the design together, so questions surface and intent transfers — the dialogue catches what static files can't.
Treat 'all states specified' as part of the design's Definition of Ready. An incomplete handoff that enters the build is borrowing rework you'll pay for later.
Questions will still arise mid-build. Keep the channel open so they're answered by the designer, not guessed by the engineer — preserving design intent through to ship.
A designer handed over a clean, polished design — the ideal screen, fully populated, everything working. Engineering built exactly what they saw. Then reality hit: what showed while data loaded? what if the list was empty? what if the request failed? what if a name was 50 characters long? None were in the design, so engineers improvised — inconsistently, and some poorly — and the gaps came back as a wave of bugs and rework.
The designer had pictured all those states; they just hadn't drawn them, assuming they were obvious. They weren't — engineers can't read minds. A complete handoff specifying every state, plus a conversation to transfer intent, would have caught all of it in the design phase, where each was a quick decision rather than a bug ticket and a rebuild.
The deliverable is a handoff covering every state and edge case, transferred through conversation — not a happy-path mockup thrown over the wall.
| Incomplete handoff | Complete handoff |
|---|---|
| The ideal screen only | Loading, empty, error, success, disabled |
| Edge cases unspecified | Long/short text, no data, failures handled |
| Thrown over the wall | Transferred via conversation |
| Gaps become bugs | Gaps caught in design, cheaply |
The design handoff fails in a single predictable place: the gap between what the designer pictured and what they actually drew. Closing that gap — specifying every state before the build — is one of the cheapest quality wins available.
The structural insight is that engineers genuinely cannot see the designer's mental model — only the artifact. A designer who's pictured the loading state, the empty state, and the error state but drawn only the happy path has, from the engineer's perspective, simply not specified them, and the engineer will fill the void with guesses. Those guesses are where inconsistency and rework come from, and they're entirely preventable. The PM's role is to insist on completeness before the build and to facilitate the handoff conversation that transfers intent, because an edge case handled in the design costs a sentence, while the same edge case discovered in QA costs a bug ticket, a context-switch, and a rebuild. It's the same before-vs-after economics as acceptance criteria — cheap early, expensive late.
The missing states become engineering guesses and rework. Specify every state.
They can't see the designer's mental model. Make it all explicit.
No conversation means lost intent. Facilitate a handoff dialogue.
An incomplete handoff is borrowed rework. Confirm completeness first.
A strong design partnership (Tool 22) makes for a smoother, more complete handoff.
Specifying all states is the design-side version of AC surfacing edge cases (Tool 15).
A complete handoff should be part of what makes design work 'ready' to build (Tool 07).
Incomplete handoffs are a common, trackable delivery risk (Tool 24).
Take any simple screen (a list, a form, a profile). Beyond the ideal populated version, list every state a complete handoff would need: loading, empty, error, disabled, edge-case text.
Count how many you listed that a typical 'finished' mockup would omit.
The states you listed that wouldn't appear in a polished happy-path mockup are exactly the gaps engineers would otherwise guess — and exactly where the handoff's rework comes from.