By the end of this lesson you can
- Prepare designs so developers can build them accurately.
- Annotate behaviour, states, content rules and accessibility.
- Work with developers through handoff rather than throwing files over the wall.
The idea
Handoff is how designs become code. Modern tools let developers inspect measurements, colours, variables and export assets, but inspection only shows what is drawn. Developers also need to know what is not drawn.
What to include
- Final screens clearly marked as ready, separate from explorations.
- States: empty, loading, error, success, and component states.
- Behaviour: what happens on click, how things animate, what is responsive.
- Content rules: maximum lengths, truncation, sorting, formatting of dates and money.
- Accessibility: heading levels, focus order, labels for icons, alt text.
- Edge cases: very long names, zero items, slow networks, permissions.
Handoff is a conversation
Walk developers through the design before they start, invite questions early, and review builds as they progress. Many teams add a developer to design reviews and a designer to code reviews for UI changes.
Why it matters in real projects
Most gaps between design and the shipped product come from missing information, not poor development. Clear handoff reduces rework, avoids guessed behaviour and builds trust between design and engineering. It also makes you far more effective as a designer, because your intent actually reaches users.
A realistic example
A designer hands over a team members page with one screen. The developer builds it, and in testing a customer with 400 team members finds the page unusable, while a new account sees a blank table.
For the next feature, the designer adds annotated frames: the empty state with a call to action, pagination after 50 rows, long name truncation with a tooltip, loading skeletons, an error banner, focus order and labels for the icon buttons. A 30-minute walkthrough with the developer surfaces two more questions, answered before any code is written.
Step by step
Mark what is ready
Move approved frames to a "Ready for dev" page or section.
Add states and edge cases
Design empty, loading, error and extreme content cases.
Annotate
Add notes for behaviour, content rules and accessibility.
Check components and tokens
Ensure library components and variables are used so inspection shows names, not raw values.
Walk through
Present the design to developers and log questions.
Review the build
Compare the implementation with the design and agree fixes.
Common mistakes
Mistake Handing over only the happy path.
Instead Include states and edge cases.
Mistake Assuming inspection is enough.
Instead Annotate behaviour and rules that cannot be seen.
Mistake Disappearing after handoff.
Instead Stay available and review the build.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h
Handoff package
Prepare a handoff for one screen you have designed.
Steps
- Add empty, loading and error states.
- Add at least five annotations covering behaviour, content and accessibility.
- List three edge cases and how they are handled.
- Ask a developer or peer what is still unclear.
Deliverable
An annotated handoff page plus a list of questions received.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Handoff turns designs into code.
- Include states, behaviour, content rules, accessibility and edge cases.
- Use components and tokens so inspection is meaningful.
- Treat handoff as an ongoing conversation.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
- Wireflows (opens in a new tab)Nielsen Norman Group
- Making your service accessible (opens in a new tab)GOV.UK Service Manual
Your notes
Marking complete updates your course and roadmap progress.