A design handoff checklist for developers
Why a handoff checklist helps
A design file usually shows the happy path: one screen, one state, one language, one screen width. Developers have to build everything else. Each gap becomes a question, a guess or a bug.
A checklist makes the handoff complete and predictable. It also saves time for the designer, who answers fewer repeated questions.
The checklist below groups the items so that it can be copied into a ticket or a file description and ticked off for each screen.
States, layout and assets
- All states. Default, hover, focus, active, disabled, error, empty and loading, for every interactive component and every data view.
- Responsive behaviour. Show how the layout changes across widths, which elements stack, hide or resize, and the breakpoints used.
- Spacing and tokens. Name colours, type styles and spacing with the same token names used in code, instead of raw values.
- Assets and export settings. Provide icons as SVG, images at the needed sizes and densities, and state formats and file names.
Show states side by side in one frame rather than in separate files, so developers can compare them quickly. Label each state with its name, for example “Input / Error”, and use the same names in the code.
Also state which parts are fixed and which are flexible. A button may have a minimum width but grow with its label, and a card may keep its padding while its content changes height.
Motion, accessibility and content
- Motion. Specify duration, easing, what triggers the animation, and what happens when the user prefers reduced motion.
- Accessibility notes. Describe focus order, the accessible name of each control, heading levels, and any required labels or announcements.
- Content rules. Say what happens with long text: wrap, truncate with an ellipsis, or grow. Include minimum and maximum lengths.
- RTL. Provide mirrored layouts for Arabic, and note which icons flip and which do not.
Write behaviour as short rules, not as paragraphs. For example: “On submit, disable the button and show a spinner. On error, move focus to the first invalid field.” Short rules are easy to turn into tasks and tests.
Edge cases and review
- List edge cases: no data, one item, hundreds of items, very long names, slow or failed requests, and missing images.
- Link the design, the token list and the written notes in one place that developers know.
- Agree on who answers questions and how, so questions do not get lost in chat.
- After the build, review the real result on real devices against the design. Check states, spacing, focus, text length and RTL, and log differences as clear, small tasks.
The handoff is finished when the built result matches the design, not when the file is shared.
Early conversations help more than late documents. Walk through the design with a developer before the build starts: they often spot technical limits, reusable components and missing states while changes are still cheap.
This guide was drafted with AI assistance from public standards and references. For the exact wording of a standard, use the sources listed above.