process & strategy
Handoff
What is design handoff?
Handoff is the point where a design is passed to developers to build - along with the specifications, assets, states and intent they need to build it accurately. A good handoff transfers everything needed to implement the design faithfully and answers the questions developers will have; a poor one leaves gaps that get filled with guesses, so the built product drifts from the design.
Also known as: handoff, design handoff, design-to-dev handoff
Prefer to watch?
Watch the recap 1:11
The demo
A designer hands a screen to a developer. First as a bare mock-up with nothing else - then with full specs, states and reasoning. Flip between them and see what the developer ends up building.
What this demo shows (text version)
The same designed screen is handed to a developer two ways, shown alongside what they end up building. In the sloppy handoff they get a single static mock-up with no measurements, no states and no rationale, so they guess the spacing, invent a hover and error state, and the built result visibly drifts from the design. In the clean handoff they get exact specs, shared design tokens, every state (hover, empty, error and so on) and the reasoning behind decisions, so the build matches the intended design.
That's design handoff: whatever you don't specify gets guessed, and guesses drift from the design. A good handoff transfers specs, states, assets, tokens and intent; a poor one leaves gaps. The deeper fix is to treat handoff as ongoing collaboration on a shared design system, so design and code speak the same language - not a one-way toss over the wall.
What's not specified at handoff gets guessed - and guesses drift from the design. A clean handoff gives developers everything they need to build faithfully: exact spacing, sizes, colours and type (ideally as shared design tokens), all the states (hover, focus, empty, loading, error, not just the happy path), behaviour and edge cases, assets in the right formats, and the intent behind decisions so trade-offs are made sensibly. A sloppy handoff - a single static mock-up with no specs - forces developers to invent the missing details, and the result diverges from what was designed. The deeper fix is treating handoff less as a one-way "throw it over the wall" event and more as ongoing collaboration, with a shared design system so design and code speak the same language.
Hand over a lone static mock-up and the developer has to guess the spacing, the hover state, the error case - and the build drifts from the design. Hand over specs, every state, tokens and the reasoning, and it gets built as intended. That's handoff: whatever you don't specify, someone else decides. Make it a shared, collaborative process on a common system, not a one-way toss over the wall.
A complete handoff includes more than a picture of the happy path: precise measurements (spacing, sizing, alignment), colours, typography and ideally design tokens/variables shared with code; all interactive and edge states (default, hover, focus, active, disabled, empty, loading, error, success); behaviour, transitions and responsive rules; exported assets and icons in the right formats; and the rationale behind decisions so developers can make sound calls when reality diverges from the mock-up.
The failure mode is the "throw it over the wall" handoff: a single static comp with no specs, no states, no reasoning. Developers must then guess the unspecified details - and their guesses, made under different constraints and knowledge, drift from the design intent, producing an implementation that doesn't match. The gulf widens when designers don't understand technical constraints and developers don't understand the design rationale.
The stronger model is collaboration over transfer: involve developers early so the design is feasible and the rationale is shared, treat handoff as an ongoing conversation rather than a one-time event, and use a shared design system (with the same tokens and components in design and code, building on atomic design) so both sides speak one language. Tools that auto-generate specs help, but the real fix is shared understanding - which also reduces design debt and rework.