Build week one
The designs are signed off and the developer opens the Figma file. The homepage is beautiful at desktop width. There is a mobile version of the homepage but not of the inner pages. The navigation has no mobile menu design. The contact form shows the empty state but not what errors look like. The blog listing assumes every post has an image. The team page has six people with short names, and the client has twenty, some with long job titles.
The developer messages the designer, who is now on another project. Some answers come quickly, some take days. The developer guesses the rest. At the staging review, the client does not like some of the guesses, and the designer does not either.
Why handovers have gaps
- Designs are made to be approved by the client, who looks at desktop pages with ideal content.
- Designers move to the next project once sign-off happens.
- There is no agreed list of what a design must include before it goes to development.
- Component states and edge cases are invisible in a static page view.
- Developers ask questions in chat, and the answers never make it back into the design file.
The handover is treated as a moment rather than a check, so the file goes over with whatever it happens to contain.
What gaps cost
Developers wait or guess, and both cost time. Guesses that do not match the designer's intent create another round of changes at staging. Mobile layouts decided by developers under pressure are often weaker than designed ones. The designer is pulled back into a project they thought was finished, interrupting their current work.
The handover check we build
- A handover list is agreed between your designers and developers: breakpoints for each template, navigation states, hover and focus states, form errors and success, empty states, long content cases, image ratios, and component variants.
- The Figma file is read through the Figma API. Frames, components and variants are listed and matched against the handover list for each template.
- Missing items are flagged, for example a template with no mobile frame or a form component with no error variant.
- The designer resolves flagged gaps before the build starts, while the project is still fresh in their mind.
- Developer questions during the build are raised against a specific frame and answered there, so the answer stays with the design.
- The handover is recorded as complete with the Figma version, so later design changes are clearly after handover.
| Often missing | What the developer ends up doing |
|---|---|
| Mobile layouts for inner pages | Improvising the layout |
| Mobile navigation | Using a default pattern |
| Form error states | Using browser defaults |
| Empty and long content cases | Guessing truncation and spacing |
| Hover and focus states | Inventing them, or leaving them out |
The check cannot judge whether a design is good. It checks that everything a developer needs is present, so the design quality the client approved reaches the build.
Build week one with a checked handover
The designer runs the check before handing over and sees five gaps: two templates without mobile frames, no error state on the form, no mobile menu and no long-name case for the team page. She fills them in over a day while she still remembers the project. The developer opens a complete file, and the questions she does have are answered on the frame itself.
Is your design handover leaking time?
- Developers find missing mobile layouts after the build starts.
- Form errors, empty states and hover states are rarely designed.
- Designers are pulled back into projects during the build.
- Answers to developer questions live in chat, not the design file.
- Staging reviews reveal developer guesses the client does not like.