Design handoff usually gets the feature built and loses the last mile. Spacing, type, states and motion drift. The designer spots the difference after the build, and each fix becomes a ticket that waits in the backlog.
Better handoff documents narrow that gap without closing it. What closes it for visual work is a different owner: the designer makes the change in the pull request, and an engineer reviews it before merge.
Key takeaways
- Design handoff is "the process of handing over a finished design for implementation" (IxDF). A good one carries states, breakpoints, tokens and the reason behind the design, not only the screens.
- Handoff problems are structural. Figma's own handbook says design intent "breaks down" at the edge cases real content brings (Figma). Every step after the file adds another place to guess.
- For visual work, the alternative is the designer owning the change in the pull request, with engineering review as the gate. Atlassian describes this workflow for its designers (Atlassian).
- New business logic, shared platform code and security changes still need a handoff (Atlassian). A good one brings engineers in early (NN/g).
What is design handoff?
Definition
Design handoff is the point where a designer passes a finished design to the engineers who will build it. It includes what they need to build it as intended: screens, specs, states, tokens, assets and the reasoning behind the decisions.
The Interaction Design Foundation calls it "the process of handing over a finished design for implementation", and adds that it can include problem statements and business logic (IxDF). Figma's handbook for developer handoff calls it "the process of going from design to build" (Figma). Designer-developer handoff is the same thing, named by its two sides.
In most product teams, a handoff package has six parts:
- The design file, with frames marked ready and components from the design system.
- Specs for spacing, type and color, written as design tokens rather than raw values. Nielsen Norman Group describes specs as "a few lines of text written next to a prototype and describing details that may be ambiguous in the design" (NN/g).
- States and edge cases: hover, focus, loading, empty, error and long strings.
- Breakpoints and motion, wherever they differ from the defaults.
- The ticket, with scope, acceptance criteria and a link to the file.
- A walkthrough, live or recorded, where the engineer can ask questions.
What a good design handoff process looks like
A good design handoff process is a series of small handoffs that start before the design is finished. It ends when the build matches the design. Sharing the file is one handoff in the middle.
- Bring an engineer in during exploration. Kelley Gordon writes for NN/g that "involving the development team late in the design process often leads to team friction and rework" (NN/g). A short feasibility check during exploration is cheaper than a redesign after the estimate.
- Write down what the file cannot show. States, breakpoints, motion, content limits, and the reason for every decision that looks arbitrary. Figma's trends report says it helps when designers explain "how they arrived at the solution and why" (Figma).
- Name tokens and components, not values. "The card uses the space-lg token" survives a design system change. "16px padding" does not.
- Mark it ready and walk through it. In Figma, the Ready for dev status tells engineers which frames to build (Figma Help). Dev Mode has more to it, covered in the guide to handing off from Figma to developers. The walkthrough is where assumptions surface while they are still cheap.
- Stay reachable during the build. A question answered within the hour does not turn into a guess.
- Review the build before it merges. Run design QA on the pull request while a fix can still go into the same branch.
Brad Frost and Dan Mall coach teams in a more collaborative process they call the Hot Potato Process, as an alternative to "chucking Zeplin links at developers". Frost's summary: "A more collaborative process saves an absurd amount of time, money, and anguish" (Brad Frost).
Figma's handbook lands in the same place. The most successful teams "don't just focus on one handoff moment", it says, and build "a shared understanding" gradually (Figma).
Design handoff problems: where the handoff breaks
Handoff problems come from the structure of the designer-developer handoff, not from careless people. Each step after the design file carries less of the design than the step before it. And the designer, who holds the intent, is not the person who changes the product.
The loop, one step at a time:
The design file. The file shows the happy path. Long names, empty lists and error messages are rarely drawn. Figma's handbook puts it plainly: design intent "breaks down" with "the inevitable edge cases that come along with user-provided content" (Figma). Those cases get decided later, by someone else.
The ticket. The ticket carries the scope and a link. The reasoning stays in the designer's head or in a comment thread nobody reads twice. That is where "differences in assumptions", the challenge developers name most often, begins (Figma).
The build. The engineer fills each gap with a reasonable guess under sprint pressure. A raw value goes where a token belonged. A hover state gets invented, and a breakpoint gets picked in code. Something close ships. One design lead we spoke with saw drift in two layers. The first runs from the Figma file to the code, the second between engineers who do not follow the shared components.
Design QA. The designer sees the build after it exists, often after it merges. Every difference now needs a second implementation by someone else. The design QA guide lists the six sources of drift.
The backlog. The fixes become tickets in someone else's queue. Each one waits for an engineer with time, and a four-pixel gap is easy to push to the next sprint. Then the same loop runs again.
No one in that loop is doing anything wrong. The process just does not let the person who owns how the product looks change what ships.
Left alone, those tickets become design debt, which builds up one unfixed finding at a time. Once it reaches users, it turns into UX debt they feel.
Why more specs do not fix handoff friction
Teams usually answer handoff friction with more handoff: redlines, annotations, a handoff checklist, Dev Mode seats for every engineer, another sync. Each helps a little. None changes who can fix the build, and each one adds another place for the design to drift from the product.
What handoff costs, and why nobody has measured it traces a figure credited to Nielsen Norman Group that NN/g never published.
Some details only exist in running code, where no spec can reach them. Atlassian's design team ran into this on its Rovo Desktop app. A cursor glow animation was built from its spec, and "the basics were there, but the details weren't" (Atlassian). The blur and spread felt off, and the spec's colors did not shine in the shipped product.
Instead of another round of Figma files, the fixes were made in code and shipped as a pull request for engineering to review and merge.
The design handoff alternative: the designer owns the change
The alternative to design handoff for visual work is for the designer to make the change in the real product and open a pull request. An engineer reviews it before merge. The designer owns the visual layer: spacing, type, color, states and motion. The engineer owns the logic, the architecture and the merge.
Atlassian tells its designers to "ship a PR that encodes the exact feel you want, not just specs or prototypes". Its rule for review is short: "Always create Pull Requests, never direct-merge" (Atlassian). GitLab shows the review half of the idea. Its code review guidelines require a Product Designer's approval on user-facing changes, which include "visual changes (regardless of how minor)" (GitLab).
The same finding, handled both ways:
| Through the handoff | In the pull request | |
|---|---|---|
| Who spots the drift | The designer, after the build | The designer, on the preview |
| What they produce | A ticket describing the fix | The fix, as a diff |
| Who implements it | An engineer, in a later sprint | The designer, now |
| Who reviews it | The designer, on a second build | An engineer, in code review |
| Where it stalls | The backlog, in someone else's queue | Review, which has an owner |
Three things keep it safe.
- Small changes. One component or one screen per pull request. The walkthrough of a designer's first pull request walks through one in eight steps.
- The design system in code. Fixes reuse the tokens and components the codebase already has. One team we work with wanted to change the spacing between a modal's title and its description once, in the component, and have every modal follow. That is one component in the product's own design system. Components shared across products fall under the exceptions below.
- Review stays with engineering. Nobody merges their own pull request. The guide chapter on running design QA in code covers fixing the findings in the same pull request.
Designers do not need to write the code by hand. A coding agent or a canvas on the codebase writes it, and the diff is what gets reviewed. For a one-line token or copy change, the github.dev browser editor is enough. The guide to design to code routes compares the options that write the code for you. Modeinspect is one such canvas, for Next.js React codebases that use Tailwind. It opens a pull request as a running build and applies fixes with design controls. The result ships as a new pull request for review.
When a handoff is still the right call
Designer-owned pull requests fit visual changes on a product whose design system lives in code. Some work needs a handoff anyway. Atlassian lists the exceptions for its designers: new business logic or a brand-new flow, components in a shared platform library, fragile performance, and security or compliance code (Atlassian).
For that work, keep the handoff and keep it good. Bring an engineer in early, write the states down, walk through the file, and run design QA on the pull request. The same applies to a team whose design system exists only in Figma. There, the first job is getting tokens and components into the codebase.
Designers we talk to mostly want closer collaboration with developers, not to take over shipping. The pull request is a good place for that collaboration, because each side owns the part it knows.
What changes for designers and developers
For designers, the last mile stops being a request. The spacing issue they would have explained again and again gets fixed once, and they check it on a preview before it merges.
For developers, there are fewer margin tickets to pick up and fewer gaps to guess at. They review a small diff with a clear intent, which is the job they already do for each other.
For the product, the slow drift from the design, one ticket at a time, stops. The person who owns how the product looks can change it, and the person who owns the code still decides what merges.
Frequently asked questions
What is design handoff?
Design handoff is the point where a designer passes a finished design to the engineers who will build it, with the specs, states, tokens and reasoning they need. It is also called designer developer handoff. In most teams it runs through a design file, a ticket and a walkthrough.
What should a design handoff include?
A design handoff should include the screens built from design system components, and specs written as design tokens. It needs every state (hover, focus, loading, empty, error), breakpoints, motion and content limits. Add the reason behind any decision that looks arbitrary, and a walkthrough where the engineer can ask questions before building.
Why does UX break after the design handoff?
UX breaks after the design handoff because the person who owns the design cannot change what ships. The engineer fills gaps in the file under time pressure, and something close ships. The designer's fixes then become tickets someone else has to schedule.
Do more detailed specs fix handoff problems?
More detailed specs reduce guessing but do not fix handoff problems. Specs cannot carry every detail that only shows up in running code, and every correction still waits for someone else to implement it. Letting the designer make visual fixes in the pull request, with developer review before merge, removes that round trip.
Is there an alternative to design handoff?
For visual changes, yes. The designer changes the real product and opens a pull request, and an engineer reviews it before merge. Atlassian describes this workflow for its designers. New business logic, shared platform code and security-sensitive changes should still go through a handoff.
Do designers need to code to fix UI after handoff?
No. A coding agent or a canvas on the codebase writes the code, and the designer checks the result on a preview. Designers need to understand branches, pull requests and review, not write CSS by hand. Developers still own the logic and review every change.