Design Handover to Developers: Documents That Prevent Costly Rework
Why Design Handover Fails Without a Spec
A polished mockup is not a build instruction. When designers hand over a Figma file and assume the developer will "fill in the gaps", those gaps become expensive assumptions. Buttons get the wrong padding. Animations run at the wrong speed. Responsive breakpoints are guessed. Each mismatch triggers a round of rework that costs time, budget, and goodwill.
The fix is a written specification that travels with the visual file. It does not need to be a 60-page document. It needs to answer the questions a developer would otherwise ask during the build, before they start typing code.
Define Layout, Grid, and Spacing Rules
Start with the structural logic behind the design. State the grid columns, gutter widths, and maximum content width. Explain how the layout collapses at each breakpoint, not just the desktop view. A developer should know whether a three-column card row becomes two columns at 1024px or stacks immediately.
Spacing is where small errors multiply. Provide a spacing scale and say which values apply to section padding, card internals, and form fields. If you used an 8px base system, say so. If certain gaps are intentional exceptions, list them.
| Element | Desktop | Tablet | Mobile |
|---|---|---|---|
| Section padding | 96px | 64px | 40px |
| Card gap | 32px | 24px | 16px |
| Body text size | 18px | 17px | 16px |
Document States, Interactions, and Motion
Static screens rarely show what happens on hover, focus, loading, or error. A spec must cover every interactive state. Include default, hover, active, focus-visible, disabled, and error styles for buttons, links, inputs, and cards. Accessibility depends on these states being deliberate rather than invented in code.
Motion deserves the same treatment. Note durations, easing curves, and what triggers each transition. If a modal fades in over 200ms with ease-out, write it down. If a hover effect should not appear on touch devices, say that too.
"A design spec is not bureaucracy. It is the shortest path between intent and implementation."
Specify Typography, Colour, and Assets
List font families, fallback stacks, weights, line heights, and letter spacing for each text style. Developers should not guess whether a heading is 600 or 700 weight. Give hex or token values for every colour, including borders, shadows, and overlay tints.
Asset handover matters as much as the values. Provide SVGs for icons, exported images at correct densities, and naming that matches the spec. Explain which graphics are decorative and which carry meaning for screen readers.
- Confirm every component state is documented.
- Check breakpoint behaviour against the live prototype.
- Verify colour contrast for text and UI elements.
- Match asset filenames to the component names in the spec.
- Review the spec with the developer before the sprint starts.
Make the Handover a Conversation, Not a Dump
The best spec is one the developer helped shape. Walk through it together, invite questions, and log decisions in the same document. When something changes later, update the spec rather than sending a stray message.
That habit prevents the most costly rework of all: rebuilding finished pages because nobody wrote down what the designer actually intended.
