Design Handoff Checklist
A design handoff checklist for designers and developers: Figma file prep, states, responsive specs, assets, copy and a walkthrough before development begins.
- Typical schedule per feature or page handoff
- The checklist 6 sections, 23 items
- Variables
{{feature}}
Use this checklist each time a design moves from the designer to the developers who will build it, whether that is a full website or a single new feature. Most questions developers ask after a handoff are predictable: what happens on mobile, what the error state looks like, which font weight that is, where the final copy is. This list answers them before development starts.
Who owns it
The designer owns the run and prepares the file. The lead developer reviews it and confirms the handoff is complete. On client projects, the project lead checks that the client has approved the designs being handed off.
Common pitfalls
- Only the happy path is designed. Empty, loading, error and long-content states are where developers have to guess. Design them, or at least note the rule.
- A messy file. Old explorations next to final screens cause the wrong version to be built. Mark final frames clearly, for example with Figma's "Ready for dev" status, and archive the rest.
- Inconsistent values. One-off colours and spacing that are not in the design system lead to drift. Use styles and components, and flag intentional exceptions.
- Handoff as a file link. A short walkthrough call catches more misunderstandings than any spec.
Tools mentioned here are examples. The same steps apply in Figma, Sketch, Penpot or Adobe XD.
The checklist: Design handoff: {{feature}}
Approval and scope
-
Final designs for
{{feature}}approved by the client or product owner -
Scope of the handoff listed: which pages, components and flows are included
-
Open design questions resolved or listed with an owner
File preparation
-
Final frames clearly marked as ready for development, and explorations archived
-
Layers and frames named so developers can find them
-
Colours, typography and effects use shared styles or design tokens
-
Reused elements built as components with their variants
-
Auto layout or spacing values consistent with the agreed spacing scale
States and responsive behaviour
-
Interactive states designed: hover, focus, active, disabled
-
Empty, loading and error states designed for each screen that needs them
-
Layouts provided for the agreed breakpoints (e.g. mobile, tablet, desktop)
-
Behaviour with long text, missing images and many items described
-
Animations and transitions described with duration and easing optional
Assets and content
-
Icons and illustrations exported or marked as exportable in SVG
-
Images provided at the needed sizes and formats, with licences confirmed
-
Final copy in place, or a link to the copy document
-
Fonts and their licences for web use confirmed
Accessibility
-
Text and UI contrast checked against WCAG AA
-
Focus styles designed for keyboard users
-
Alt text and accessible labels for icons noted in the file
Walkthrough
-
Walkthrough held with the developers, and questions captured
-
Development tickets created and linked to the matching frames
-
Design review of the built version scheduled before release
Checklist as Markdown
Frequently asked questions
What should a design handoff include?
A handoff includes approved final screens, all interactive and edge-case states, responsive layouts, shared styles and components, exported assets, final copy, and notes on behaviour and accessibility. It ends with a walkthrough so developers can ask questions while the designer still has the context.
How do I prepare a Figma file for developer handoff?
Separate final screens from explorations, name layers and frames clearly, use styles and components instead of one-off values, and mark frames as ready for development. Add notes where behaviour cannot be seen in a static frame. Developers can then inspect values directly in Dev Mode or the inspect panel.
Should designers be involved after the handoff?
Yes. Questions always come up during the build, and a design review of the built version catches differences before users see them. Plan a short review before release rather than treating handoff as the end of the designer's work.
Updated