How do I hand off designs so developers don't guess?

A good handoff answers every question a developer would otherwise have to guess. That means every state of every screen, specs written as tokens, every asset exported, and notes on the edge cases.

My bar is simple. I ship everything a developer needs alongside the design: all the media, all the information, and the edge cases that might occur on the frontend or the backend. Something is ready when developers, PMs, and other designers agree it feels complete, both in how it works and how it looks.

The second half of the answer: handoff is a conversation, not a file you throw over a wall.

Figma's own handbook for developer handoff says it plainly: "It's never too early to bring a developer in." Engineers can flag technical limits and spot opportunities while ideas are still cheap to change.

They also put the core tension well: "Design is 'what we want' and development is essentially 'what we have.'" Your job is to close that gap early, not discover it in review.

Ask pointed questions, because, as the handbook notes, developers "won't know what you don't know." Good ones to start with:

• What data actually exists for this screen, and what can be missing?
• What is expensive to build, and is there a cheaper version that keeps the intent?
• What do you want annotated, and what can you read straight from the file?

Most guessing happens here. A developer gets a perfect screen with ideal data, then has to invent the rest.

For every screen, design at least:

• Empty. What the user sees with no data yet. Nielsen Norman Group warns that "totally empty states cause confusion about how and whether the system is working." Use the space to show status, teach the feature, or give a clear first action.
• Loading. NN/g recommends skeleton screens for full-page loads under about 10 seconds, spinners for a single module, and progress bars for longer waits or uploads.
• Error. What failed, in plain words, and what the user can do next.
• Edge cases. Figma's handbook notes that "design intent breaks down" with user-provided content. Test long names, missing images, low-resolution photos, and half-filled profiles.
• Interactive states. Hover, pressed, focus, and disabled for every control.

Do not forget the backend side. What happens on a timeout, a failed payment, or a permission error? If you do not design it, someone will improvise it.

Use tokens, not raw values. If your colours and spacing are Figma variables, a developer sees the variable name, and in Dev Mode can follow its alias chain back to the raw value. A hex code invites copy-paste. A token name like content/primary maps straight to code. My guide on building a design system in Figma covers how to set this up.

Name your layers. Figma's handbook says "Developers rely on layer names when inspecting a design and building out the structure in code." A layer called "Frame 123" makes them guess.

Write down behaviour. Use annotations for what a screenshot cannot show: what triggers an animation, how a list sorts, what a truncated label does on hover.

Prepare every asset. Figma recommends applying export settings to the frames, components, and assets developers will need for the production build. Icons, illustrations, images, and video should be named, sized, and ready, not buried in a frame.

Dev Mode is Figma's workspace for developers to inspect designs. It is available on all paid plans and needs a Full or Dev seat. The features that matter most for handoff:

If a design marked ready is edited later, Figma flags it as Changed, so developers know to look again. Annotations and measurements need a Full seat with edit access to add. Anyone with a Full or Dev seat who can view the file can read them.

Figma's MCP server also lets developers "get design context and code" from Figma files inside their AI coding tools. I use Figma MCP with Claude Code myself, and it cut real friction from my design-to-dev handoffs. It does not replace the conversation, though. It just means fewer questions are about pixels.

The last row matters most. If the developer still has questions after the walkthrough, the handoff is not finished.

1. Take one screen you have designed and add its empty, loading, and error states this week.
2. Rename every layer in that file and replace any raw colour with a variable.
3. Ask one developer what they wish designers handed them, and add it to your checklist.
4. Write the handoff into your case study. Showing the states and edge cases proves you think past the happy path. My case study guide shows where it fits.

If you want to close the gap from the other side and build what you design, read what a design engineer is.