Design that survives the handoff
The work does not end at approval. It ends when someone who was not in the room ships it correctly.
- Published
- Reading time
- Topics
- Written by

Every studio has seen it: a launch that looks nothing like the file that was signed off. Not because anyone was careless, but because the design described a happy path and production is made almost entirely of everything else.
Approval is the middle of the project
A design file is a proposal. It becomes a product when an engineer implements it against real data, in a real browser, under a real deadline. The gap between those two states is where quality is lost, and it is almost never lost to a lack of skill.
It is lost to unanswered questions. What happens when this name is sixty characters long? What does this list look like empty? What is the focus order? Which of these two elements wins when both are visible on a narrow screen?
Design the states, not the screens
The single highest-return change a design team can make is to stop delivering screens and start delivering states. For every component:
- Empty — before there is any data, which is what every new user sees first.
- Loading — including the slow case, not just the spinner.
- Error — with real copy, written by someone who has read the failure modes.
- Overflow — the longest plausible string, not the one that fits.
- Focus — visible, ordered, and tested with a keyboard rather than assumed.
A component delivered with those five is implementable without a single clarifying message. One delivered without them is a negotiation.
Specify in the units the code uses
Handoff friction is often just a translation problem. If the system is built on a spacing scale, the spec should name steps on that scale rather than pixel values that happen to match this week. If colour has semantic roles, the spec names the role — surface, line, muted — not the hex.
This sounds pedantic until the first theme change, when every hardcoded value has to be found by hand and every semantic one updates itself.
A specification that has to be interpreted will be interpreted differently by each person who reads it.
Sit in the build
We stay in the repository through implementation. Not to write all of it, necessarily, but to be present when the first real content lands and the layout behaves in a way nobody predicted.
The alternative — reviewing a staging link two weeks later — turns every finding into rework with a cost attached, which is how design feedback ends up negotiated away.
What good handoff feels like
Nobody notices it. There is no launch-week scramble, no list of thirty visual bugs, no meeting about whether the padding was meant to be like that. The team ships the tenth screen faster than the first, because by then they are assembling rather than deciding.
That is the whole goal of a system: to move the decisions to the front, once, so that everything after it is execution.





