By Mehdi HassanWhat is design handoff?
Design handoff is the step where designers pass finished designs to developers, along with everything needed to build them: specs, assets, interactions, states and copy. In practice it's less a single moment than a conversation, starting before the design is final and ending when the build matches it.
The term comes from a world where designers and developers sit in separate teams, or separate companies. Design happens, a file is thrown over the wall, and development starts. Every gap in the file becomes a guess, and every guess becomes a difference between what was designed and what shipped. This hub covers how to make handoff work, why it so often doesn't, and the case for removing most of it.
Here's how the guides in this hub fit together, so you can jump to the part you need.
If you need to… | Read |
|---|---|
Prepare a file before developers see it | |
Decide whether to pay for Figma Dev Mode | |
Structure pages and names so developers find things | |
Make components behave like CSS | |
Link Figma components to real code | |
Explain states, edge cases and interactions | |
Spec breakpoints for a web app | |
Check the build against the design | |
Understand the root causes |
Why does design handoff go wrong so often?
Design handoff goes wrong because the file answers what a screen looks like but not how it behaves. Developers need to know what happens on hover, on error, with no data, with too much data, at every width, and when the copy is twice as long. If the design doesn't say, the developer decides, usually under time pressure.
The second cause is vocabulary. Designers call something a Card, Large, with Icon. The codebase calls it Panel with size lg and an icon prop. Without a shared vocabulary, every component is translated by hand, and translations drift. The third cause is timing: handoff happens once, at the end, when it's too late for developers to point out that a design is expensive to build or impossible with the current data.
- Missing states: loading, empty, error, disabled and hover are left out or drawn for one component only.
- Missing responsive rules: a desktop and a mobile frame, with nothing in between.
- Placeholder copy: lorem ipsum or draft copy that changes after the build.
- Detached values: raw hex codes and one-off spacing instead of tokens.
- No behavior notes: animations, transitions and logic shown in a prototype nobody opens.
- Late involvement: developers see the design for the first time at handoff.
We cover each root cause in depth in why design handoffs fail. The short version: most of those causes disappear when the people who design and the people who build stop working in separate silos.
Is the best design handoff no handoff at all?
For most startups, yes. The best design handoff is one where the same team, or even the same person, designs and builds, so decisions don't have to be written down to survive the trip. When the designer is in the pull request and the developer was in the design review, gaps get filled in minutes rather than discovered after release.
This is the model we work in. One team owns the words, the design and the code, so a copy change, a layout tweak and the matching CSS happen together. There's still a design file and still a build, but the handoff between them is a conversation inside one team rather than a delivery between two.
Handoff fails where two teams meet. The fewer places they meet, the less it fails.
Pros
- Decisions don't get lost between design and build
- Developers flag build cost while the design is still changing
- Copy, design and code change together, not in sequence
- Fewer documents to produce and maintain
- Design QA happens continuously instead of at the end
Cons
- Designers who code, or tight design-dev pairs, are harder to hire
- Large organizations still need some formal handoff between teams
- Less written documentation can hurt when the team changes
- Not every studio or freelancer works this way
One team doesn't mean no process. You still want tokens, a component library and a QA pass. It means the process exists to keep quality, not to transfer knowledge between people who never talk. Our comparison of an in-house product team vs a design and dev studio covers when each structure makes sense.
What does a handoff-ready design file include?
A handoff-ready design file includes tokens, components built with auto layout, every state, responsive rules, final copy and annotations for behavior. If any of those is missing, developers either stop to ask or guess. Here's what each part means in practice.
Part | What ready looks like | Deep dive |
|---|---|---|
Structure | Clear pages, named frames, a ready-for-dev section | |
Tokens | Every color, space and radius uses a variable with code syntax | |
Layout | Auto layout everywhere, constraints match CSS behavior | |
States | Default, hover, focus, disabled, loading, empty, error | |
Responsive | Breakpoints and what changes at each | |
Copy | Final text, real data lengths, error messages written | |
Assets | Icons as components, images exported or linked at the right sizes |
Final copy deserves special attention because it's the item most often skipped. Layouts built around placeholder text break when real text arrives. Headlines wrap, buttons overflow, and empty states say nothing useful. Writing the real words before handoff is one of the cheapest ways to avoid rework, and it's why we start every project with the words.
What is the design handoff process step by step?
A good design handoff process starts before the design is finished and ends after the build ships. For teams that must hand off between separate designers and developers, these six steps cover what matters.
Involve developers early
Share rough flows with a developer before high-fidelity design starts. They'll spot data that doesn't exist, interactions that are expensive and components that already exist in code.
Agree on the vocabulary
Align component names and props between the Figma library and the codebase. Use a shared table if they differ. Ideally they match exactly, so a developer reading the file knows exactly which coded component and props to use.
Prepare the file
Run the Figma handoff checklist: tokens, auto layout, states, responsive rules, final copy, assets, annotations.
Walk through it together
Hold a short walkthrough call instead of sending a link. Developers ask questions while the designer is there, and the answers get added to the file as annotations.
Stay available during the build
Questions come up during development. A designer who responds within hours keeps the build on track; one who responds in days forces guesses.
Run design QA before release
Compare the build to the design on real devices and widths, log differences and fix the important ones before shipping. See our design QA checklist.
Notice that only one of those steps is about the file itself. The rest are about people talking at the right moments. Teams that invest only in better files, without the conversations, still end up with drift.
Which tools help with design handoff?
The main design handoff tools are Figma Dev Mode for inspecting specs, Code Connect for linking design components to code, AI design-to-code tools for drafting implementation, and annotation features for documenting behavior. They make good handoff faster. None of them makes an incomplete design complete.
Tool | What it does | Worth it when | Limits |
|---|---|---|---|
Figma Dev Mode | Inspect specs, variables, code snippets, ready-for-dev status, compare changes | Developers regularly inspect files | Paid seats; see our Dev Mode review |
Figma Code Connect | Shows real component code in Dev Mode | You have a coded component library matching Figma | Setup effort and plan requirements |
AI design-to-code (Figma MCP and others) | Generates code from frames, using your tokens and components if named well | Files are clean and tokenized | Output quality depends on file quality |
Annotations | Notes and measurements pinned to designs | Behavior and edge cases need explaining | Only as good as what's written |
Prototypes | Show transitions and flows | Motion and flow matter | Developers often don't open them |
AI tools are changing handoff the fastest. Tools that read Figma files and generate components work far better when variables, components and names match the codebase, which is one more reason to keep files clean. Our comparison of Figma to code with AI covers what they do well and where they still need a developer, and our guide to Figma Code Connect shows how to give them real components to reference.
Hypothetical example: the same feature handed off two ways
For example, suppose a startup is shipping a new billing settings page. In the first version, a freelance designer delivers a Figma link with a desktop and mobile frame. The developer builds it in a week, inventing the loading state, the error for a declined card, the empty invoice list and everything between the two widths. Design QA finds a dozen differences after launch, and half never get fixed.
In the second version, the designer and developer are on the same team. The developer joins the first design review and points out that invoice data loads separately, so the page needs a partial loading state. The designer writes the real error messages before high fidelity. The build uses existing table and card components, and QA happens on a preview link before release. The same page ships with fewer surprises, and the only artifact beyond the design file is a short list of annotations.
How should you handle responsive design and edge cases in handoff?
Handle responsive design by specifying rules rather than drawing every width. Show the key breakpoints, then write what changes between them: which columns stack, what collapses into a menu, what gets truncated and what wraps. Developers build behavior, not screenshots, so describe behavior.
Edge cases work the same way. You don't need a frame for every possibility, but you do need decisions for the common ones: very long names, missing images, zero and huge numbers, slow networks, permissions the user doesn't have. A single edge-case frame per component, or a few written annotations, saves hours of back-and-forth. Our guides to responsive design handoff and annotating designs for developers give templates for both.
How do you check the build after design handoff?
Check the build with design QA: a structured review of the implemented feature against the design, on real devices, before it ships. Design QA is where handoff either succeeds or quietly fails, because it's the only step that compares what was designed with what was built.
- Review on a preview link, not in production after launch.
- Check every state, not just the default screen: loading, empty, error, hover, focus.
- Test at several widths, including the awkward ones between breakpoints.
- Compare tokens, not pixels: is it using the right variable, even if it looks close?
- Read the copy: check that final text made it into the build and nothing is truncated.
- Log issues by severity, so the team fixes what users will notice first.
Our design QA checklist has the full list. When the same team designs and builds, QA becomes part of the work rather than a separate gate, which is the other big advantage of skipping the handoff.
How does handoff work for websites versus product features?
Handoff for a marketing website is usually a one-time project handover, while handoff for product features happens continuously, sprint after sprint. The principles are the same, but the risks differ. A website handover risks you not owning your files, code and CMS. A product handoff risks slow drift between the design system and the app.
For websites, make sure you receive everything you paid for at the end: source design files, code, CMS access and documentation. Our website handover checklist lists what you should own. For the wider sequence a site goes through, see the website design process. For product work, the hub on MVP design and development covers how design and build fit together in a first version.
If you'd rather skip the handoff problem entirely, we design and build with one team. Our brand and design sprint is $3,000, fixed, for design in Figma, and a $1,000 trial week lets you see us design and develop together before you commit. Both are on our pricing.
