In short
- A handoff passes screens, specs, assets, states, and decisions from design to development.
- Most problems come from what the designs leave out, such as error states and long content.
- Shared tokens, a design system, and early developer review shrink the gap.
- When the same people design and write the code, there is far less to hand over.
Also called: Design to development handoff, Dev handoff, Developer handoff, Design specs.
What a design handoff is
In most teams, design and development are separate jobs done by different people. Designers work out how the product should look and behave, usually in a tool such as Figma. Developers then turn those designs into code. The handoff is the point where the work changes hands.
It is rarely a single moment. On a healthy team it is a series of small handovers, one feature or flow at a time, with conversation in both directions. On a strained team it is a link to a large design file sent at the end of a phase, followed by weeks of questions.
What gets handed off
A complete handoff covers more than the screens. Developers need enough to build each part without guessing.
| Item | What it contains | What happens without it |
|---|---|---|
| Screens and flows | Every screen, in order, with how users move between them | Developers invent the gaps |
| Specs | Spacing, sizes, type, colors, and layout rules for each screen width | Small inconsistencies everywhere |
| Assets | Icons, images, and illustrations in usable formats | Placeholders that ship by accident |
| States | Empty, loading, error, success, and disabled versions | Blank screens and raw error messages |
| Design tokens | Named values for color, type, and spacing shared with code | Hard-coded values that drift apart |
| Behavior notes | Animations, validation rules, and edge cases | Guesses that need rework later |
Design tokens are worth a short explanation. They are named values, such as a primary color or a spacing step, kept in one place and used by both the design file and the code. When a token changes, both sides change together, which removes a whole class of small mismatches.
Where handoffs go wrong
Static designs show the product at its best moment. Real software spends much of its time in other moments, loading, empty, failing, or showing text that is longer than the designer expected. When those moments are not designed, developers fill them in under deadline, and the result rarely matches the rest of the product. In Choie's prototype week, day one names the workflow's screens and states, and the prototype is coded with real behavior rather than drawn as a Figma mockup, so the missing moments surface early.
- Missing states. The main path is designed, but errors, empty lists, and slow connections are not.
- Interpretation. A design shows what a screen looks like, and the developer has to infer how it behaves. Two reasonable people infer different things.
- Designs that cannot be built as drawn. A layout that works at one screen width breaks at another, or depends on data the system does not have.
- Moving targets. Designs keep changing after development starts, and nobody is sure which version is current.
- Rework. Each of the above ends in the same place. Something is built, reviewed, and rebuilt, and the schedule absorbs the cost.
How teams reduce the gap
Most fixes move conversation earlier and make the shared parts explicit.
- Involve a developer before designs are final. A short review catches things that are expensive to build or impossible with the data available.
- Design every state. Include empty, loading, error, and long-content versions of each screen in the file.
- Share a [design system](/glossary/design-system). When components and tokens exist in both design and code, a new screen is mostly assembly.
- Hand off in small pieces. One flow at a time, with a short walkthrough call, works better than one large file at the end of a phase.
- Review the build against the design. A design QA pass before release catches drift while it is still cheap to fix.
A handoff that works
- 01DesignScreens and every state
- 02Developer reviewCheck what can be built
- 03HandoffOne flow, with a walkthrough
- 04BuildQuestions answered the same day
- 05Design QACompare the build to the design
Design and code in the same hands
The other way to reduce handoff problems is to remove most of the handoff. In a small team, one person or a close pair can design a flow and build it, so decisions about behavior are made once, by the people who will write the code. A question that would have been a ticket becomes a moment of thought.
This has limits. It depends on people who are genuinely good at both, and it suits small teams and early products best. Larger organizations with many designers and developers still need a structured handoff, and they lean on design systems and clear specs to keep it working.
AI-assisted development has made the combined model more practical, because tools such as Cursor and Claude help a product person move from a design decision to working code faster. Someone still has to judge whether the result is right.
Choie avoids the problem by keeping design and code in the same hands: the person who draws a screen is the person who builds it. How a project runs shows what that looks like week to week.
Common questions
What should a design handoff include?
Screens and flows, specs for spacing and type, exported assets, every state of each screen, design tokens, and notes on behavior. The states and behavior notes are the parts most often missing.
What is design QA?
Design QA is a review of the built product against the designs before release. A designer checks spacing, type, states, and behavior, and logs the differences for developers to fix. In a Choie build, the live link sent every Friday does part of this job, because you use the product each week rather than waiting for a review at the end.
Do design tools handle the handoff for you?
They handle part of it. Tools such as Figma let developers inspect measurements, copy values, and export assets directly. They cannot fill in states or decisions that were never designed, and that is where most rework comes from.
Who is responsible for a good handoff?
Both sides share it. Designers owe complete states and clear notes, and developers owe early questions and a review before the designs are final.