“Handoff” sounds like a single moment: the designer finishes, passes a file over, and the developer builds it. In practice, the teams that ship good interfaces treat design handoff as a conversation that starts early and continues until the feature is live. Still, there is a point where a design must be clear enough to build without guesswork, and that is where most friction happens.
This post is a checklist for designers, written from the point of view of someone who has sat on both sides – designing screens and writing the front-end code for them. It uses Figma terms, but the ideas apply to any tool. If you are a designer who wants to understand the developer side better, the front-end developer roadmap is a useful overview.
Why design handoff goes wrong
Most design handoff problems are not about pixels. They come from missing information. Typical examples:
- The design shows only the “happy path” – no loading, error or empty states.
- Spacing and colours are slightly different on every screen, so developers cannot tell which values are intentional.
- Nobody explained what happens on a small phone or a very wide monitor.
- Interactions such as “this panel slides in” exist only in the designer’s head.
- The file contains five versions of the same screen and no indication of which is final.
Each gap forces a developer to guess, ask, or wait. Guessing produces inconsistent results; asking and waiting slows everyone down.
Before handoff: involve developers early
The cheapest time to fix a technical problem is before the design is polished. Share rough wireframes with a developer and ask:
- Is any part of this hard or slow to build with our current stack?
- Does the data for this screen actually exist, and in this shape?
- Can we reuse existing components instead of building new ones?
- Are there performance or accessibility concerns (large images, heavy animations, complex tables)?
This short conversation often saves days later. It also builds trust: developers feel ownership, and designers learn the constraints that shape good decisions.
Checklist 1: Organise the file
- Use clear page names, for example “Ready for dev”, “In progress”, “Archive”. Move old explorations out of the way.
- Name frames by screen and state: “Checkout – Payment – Error”, not “Frame 237”.
- Mark finished frames or sections as Ready for dev in Figma, so developers can filter to them in Dev Mode.
- Add a cover or overview page with the feature name, a short description, links to the ticket and prototype, and a contact person.
- Keep the flow left to right in the order users experience it.
Checklist 2: Use components, styles and variables
If a button is a detached group of shapes on one screen and a component on another, developers cannot tell whether the difference is intentional. Consistent building blocks make handoff much easier.
- Build repeated elements as components with variants for their states (default, hover, focus, disabled, error). See Figma components and variants.
- Use auto layout so spacing and resizing behaviour are visible in the file, not only in your head.
- Store colours, spacing values and type sizes as variables or styles with meaningful names such as
color/text/primaryorspace/16. - Match those names to the code where possible. If developers use CSS custom properties, a shared naming scheme removes a whole layer of translation; see CSS custom properties as design tokens and the CSS variables lesson.
- Avoid one-off values. If a spacing of 13px appears once, it is probably a mistake – fix it or explain it.
This is the foundation of a design system; design systems for beginners explains the bigger picture.
Checklist 3: Show every state
| Element | States to design |
|---|---|
| Buttons and links | Default, hover, focus (visible outline), pressed, disabled, loading |
| Form fields | Empty, focused, filled, error with message, disabled, read-only |
| Lists and tables | Loading, empty, one item, many items, very long text, pagination |
| Pages that fetch data | Loading (skeleton), success, error with retry, no permission |
| Images and avatars | Missing image fallback, different aspect ratios |
| Content | Short and very long names, long words, translated text that is longer |
Use realistic content. A layout that looks perfect with “Ravi” can break with “Venkataraghavan Subramanian”. For guidance on form states and error messages, see form design UX.
Checklist 4: Explain responsive behaviour
Developers need to know how a design behaves between the sizes you drew, not only at them.
- Provide key layouts for at least a small phone, a tablet or small laptop, and a wide desktop.
- State the breakpoints you designed for, and what changes at each one (columns, navigation pattern, hidden elements). Responsive design breakpoints covers common choices.
- Say what is fixed and what is fluid: “Sidebar is 280px; content area fills the rest; max content width 1200px”.
- Explain overflow rules: does long text wrap, truncate with an ellipsis, or scroll?
- If your team uses a framework such as Bootstrap, design to its grid and breakpoints so developers do not fight it; see the Bootstrap grid system.
Checklist 5: Describe interactions and motion
- Link screens in a prototype to show the flow; add the link to the ticket.
- Write short notes for anything a static frame cannot show: “Toast appears for 4 seconds, can be dismissed”, “Menu closes when you click outside”.
- For animation, give duration and easing and say what triggers it. Keep motion purposeful, and respect users who prefer reduced motion (CSS animation performance tips explains why).
- Specify keyboard behaviour for custom components: tab order, what Enter and Escape do, where focus goes when a dialog opens and closes.
Checklist 6: Accessibility notes
Accessibility is easier when decisions are made in design, not patched in code. Include:
- Colour contrast checked for text and important icons.
- Text alternatives for meaningful images and icons, and a note when an image is decorative.
- Heading levels for each screen (which text is the H1, H2…), which also helps semantic HTML.
- Labels for icon-only buttons (“Close”, “Search”).
- Touch target sizes that are comfortable on phones.
The web accessibility basics post has a fuller list.
Using Figma Dev Mode for design handoff
Figma’s Dev Mode is a view built for developers. According to Figma’s help centre, it is available on paid plans and lets developers:
- Inspect layers to see sizes, spacing, styles and the variables applied to them.
- See auto-generated code snippets (for example CSS) for a selected layer, which are a helpful starting point rather than production code.
- Filter to sections marked Ready for dev and compare changes against earlier versions, so they can see exactly what changed since they last looked.
- Download assets such as icons and images that are marked for export.
- See annotations and measurements that designers have added.
- On some plans, see real component code from the team’s codebase through Code Connect, instead of generic generated code.
Annotations deserve special mention. Designers with edit access can attach notes to layers, and those notes can include live properties (such as spacing or a text style) that stay up to date if the design changes. Use them for anything a developer might otherwise ask you about: behaviour, limits, content rules.
Tip: Feature availability depends on your Figma plan and seat type, and Figma updates Dev Mode regularly. Check the current Dev Mode guide on help.figma.com before you set up a team workflow.
Checklist 7: Assets and content
- Icons as SVG, using a consistent size and naming convention.
- Photos exported at sensible sizes and in modern formats; see image optimisation for the web.
- Final copy in the design, or a clear link to where approved copy lives. Avoid “Lorem ipsum” at handoff.
- Fonts named with weights used, and a note on licensing if they are not free web fonts.
After handoff: review the build
Handoff is not finished until you have checked the result. Agree on a design review step before release:
- Review the feature in a test environment on a real phone and a desktop browser.
- Compare against the design, focusing on things that affect users (states, spacing system, hierarchy) rather than one-pixel differences.
- Log issues clearly with a screenshot, the expected result and a link to the frame.
- Accept good developer decisions. Sometimes the built version is better than the mock-up; update the design file to match so it stays the source of truth.
Learning some front-end code makes these conversations far easier. Even a little HTML and CSS, or the basics of components in React, helps you design things that map cleanly to code.
Quick design handoff checklist
- Developer consulted at wireframe stage.
- File organised; final frames marked Ready for dev; overview page added.
- Components, variants, styles and variables used consistently; no stray values.
- All states and edge cases designed with realistic content.
- Responsive rules and breakpoints explained.
- Interactions, motion and keyboard behaviour described.
- Accessibility notes included.
- Assets prepared and final copy in place.
- Design review planned before release.
Frequently asked questions
What is design handoff?
Design handoff is the process of giving developers everything they need to build a design accurately: final screens, states, specifications, assets, interaction notes and context. In good teams it is an ongoing collaboration, not a one-time file transfer.
Do developers need a paid Figma seat for Dev Mode?
Dev Mode is a paid-plan feature, and access depends on the seat type assigned to each person. Plans and seats change over time, so check Figma’s current help centre pages for the details that apply to your team.
Is the code generated by Dev Mode ready to use?
Treat it as a reference. Generated snippets show values such as sizes, colours and spacing, but production code needs to follow your project’s components, structure and responsive rules. Code Connect can show real component code where a team has set it up.
How detailed should handoff annotations be?
Detailed enough that a developer does not need to guess about behaviour, states or rules, but not a repeat of what the inspect panel already shows. Focus notes on things a static frame cannot express.
