Design handoff

Why design handoff matters

Whatever the design doesn't specify, an engineer has to guess. What does the invoice list show when there are no invoices? What happens when a company name is 60 characters long? What does the error say when a card is declined?

Each guess is reasonable on its own. Added up, they're why shipped products drift from the mockups. They're also why QA turns into a long list of "that's not what we meant".

What a good design handoff includes

Final screens at each breakpoint, plus every state: empty, loading, error, success, long content and restricted permissions. Components and tokens should point to the design system rather than one-off values, and the copy should be final, not lorem ipsum.

Behaviour needs writing down too: what triggers an animation, what happens on a slow connection, where focus goes when a modal opens. Accessibility notes such as form labels, alt text and reading order belong here, since engineers can't infer them from a static frame. Add a short note on why the design works this way, so trade-offs during build don't undo it.

A design handoff checklist

Use this before a feature moves into build. Each line is something an engineer would otherwise have to guess.

• Screens at each breakpoint. Desktop, tablet and phone, not only the widest one.
• Every state. Empty, loading, error, success, long content and restricted permissions.
• Final copy. Real labels, messages and error text, not placeholder words.
• Tokens and components. Pointing at the design system, with any one-off value called out.
• Assets. Icons and images exported, named and in the right formats.
• Behaviour notes. What triggers each animation, what happens on a slow connection, where focus goes when a dialog opens.
• Accessibility notes. Form labels, alt text, focus order and reading order.
• The reasoning. A short note on why the design works this way, so a trade-off during build does not undo it.
• Ready status. Frames or sections marked as ready for development, so nobody builds from a draft.

Then do two things a file cannot do. Walk the engineers through it, live, and let them ask why. And when the feature is built, review it against the design together before it ships.

How design handoff works in Figma

Figma's Dev Mode gives engineers a separate view for inspecting designs. They can see properties and generated code, download assets and compare a frame with earlier versions to spot what changed.

Designers can mark frames or sections as ready for development and add annotations. With Code Connect, a design system team can show real component code in place of auto-generated snippets. None of that replaces a conversation about intent, but it cuts down on measuring pixels.

Figma's guide describes the status in practical terms. A designer selects a frame, component or section and clicks "Mark as ready for dev". Those items then appear under "Ready for development" in the Dev Mode layers panel, and developers who have viewed the file are notified each time something is marked ready. When a design changes later, "Compare changes" shows what moved.

Signs a design handoff went wrong

You can usually tell within the first week of build.

• Engineers ask the same kind of question repeatedly. "What happens when this is empty?" asked five times means the states were never drawn.
• The build matches the mockup and still feels wrong. The static frame was copied, but the behaviour between frames was never described.
• QA produces a long list of "not what we meant". Each item is a guess that went the other way.
• Copy changes late. Placeholder text reached the build, and real words do not fit the layout.

None of these is fixed by a longer document. They are fixed earlier, by showing engineers the design while it can still change, and by agreeing the states and the copy before the feature is marked ready.

Design handoff vs a design system

A handoff covers one feature or release. A design system is the shared library of components, tokens and rules that every handoff draws on.

The two shrink each other's workload. With a decent system in place, a handoff can say "standard table, standard empty state" and spend its detail on what's new. Without one, every handoff has to specify buttons from scratch, and drift creeps in.

For what the shared library holds, see design system. Our post on when your SaaS needs a design system covers how big the first version should be.

How Gr8r handles design handoff

Our designers and engineers work on the same projects, so handoff happens in stages rather than as one big drop. Engineers look at designs while they're still changing, which surfaces technical constraints early.

Before a feature moves into build, we check that its states, copy and behaviour notes are in place. The same people stay available to answer questions during development.

That is why product design and product engineering run as one team here. Projects start at $8,000, with the final price agreed in writing. To see where handoff sits in the first days of a project, read your first two weeks with a new product partner.