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 point where a designer passes a finished design to engineers. A good one carries states, breakpoints, tokens and the reason behind the design, and the copyable handoff ticket template has a field for each.
- Handoff problems are structural. The file shows the happy path, every step after it carries less of the design, and the designer who holds the intent cannot change what ships.
- For visual work, the alternative is the designer owning the change in the pull request, with engineering review as the gate.
- New business logic, shared platform code and security changes still need a handoff. A good one brings engineers in early.
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, the handoff package is a design file with frames marked ready and components from the design system, plus specs written as design tokens rather than raw values. A walkthrough lets the engineer ask questions, and a ticket ties it together. 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).
The ticket is the part engineers build from, so the template below puts states, breakpoints, tokens and open questions into it. Copy it into Jira, Linear or a GitHub issue. Leave no field blank: write "not needed" and the reason.
DESIGN HANDOFF TICKET
Feature:
Designer: Engineer:
Design file (frames marked Ready for dev):
Walkthrough (date or recording):
SCOPE
In scope:
Out of scope:
ACCEPTANCE CRITERIA
[ ] Matches the Ready for dev frames
at every breakpoint below
[ ] Every state below is built, or
marked "not needed" with a reason
[ ] Spacing, type and color use the
tokens below, no raw values
[ ] Design QA on the pull request
before merge (reviewer: ______)
STATES
State | Frame/note | Behavior, copy
------------|------------|---------------
Default | |
Hover | |
Focus | |
Loading | |
Empty | |
Error | |
Long string | |
BREAKPOINTS
Mobile:
Tablet:
Desktop:
MOTION
Where it differs from the defaults:
TOKENS USED
Spacing:
Type:
Color:
Radius:
Components reused:
New components (and why):
WHY IT LOOKS THIS WAY
Decisions that look arbitrary,
and the reason for each:
OPEN QUESTIONS
Question | Owner | Answer by
--------------------|---------|----------
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 and end 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). The guide to handing off from Figma to developers covers the rest of Dev Mode. 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. We hear the same thing on our calls with customers: the drift runs in two layers. The first runs from the Figma file to the code. The second runs 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
If you are the one designer on a team of ten engineers, you have probably answered handoff friction with more handoff already. Redlines, annotations, a handoff checklist, Dev Mode seats for every engineer, another sync. Each helps a little, and so does the ticket template above. None changes who can fix the build, and each adds another place for the design to drift from the product. Nobody has measured what handoff costs, either: the figure credited to Nielsen Norman Group is one 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 |
| New business logic or a shared platform component | Handoff fits: the engineer owns the build | Not the right route: the logic and shared components stay with engineering |
Prelude, a Modeinspect customer whose design team ships its own pull requests, works this way, and engineering review still gates every merge. Idea to merged pull request went from about 31 days on average to 13 days, and handoffs per feature went from five or more to one (Prelude customer story).
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. We hear the same thing on our calls with customers: teams want to fix the spacing under a modal's title once, in the component, and have every modal follow. Components shared across products fall under the exceptions below.
- Review stays with engineering. Nobody merges their own pull request. Engineers review a small diff with a clear intent, which is the job they already do for each other. The guide chapter on running design QA in code covers fixing the findings in the same pull request.
Who writes the code
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, the canvas Prelude's designers use, is built for Next.js React codebases that use Tailwind. It opens a pull request as a running build, applies fixes with design controls, and ships the result 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, fill in the ticket template, 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.
We hear the same thing on our calls with customers: designers 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.
To start, take the oldest spacing or state ticket in your backlog. Make the fix in a pull request, and ask the engineer who would have picked up the ticket to review it.
Frequently asked questions
What does design handoff mean?
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. The ticket needs scope, acceptance criteria, a link to the frames marked Ready for dev, every state (default, hover, focus, loading, empty, error and long strings), breakpoints, motion, the tokens used and open questions. Add the reason behind any decision that looks arbitrary, and a walkthrough where the engineer can ask questions before building.
What are the steps in a design handoff process?
A good design handoff process starts before the design is finished. Bring an engineer in during exploration, write down what the file cannot show, name tokens and components instead of raw values, mark frames ready and walk through them, stay reachable during the build, and review the build before it merges. Sharing the file is one step in the middle.
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.
What causes handoff friction between designers and developers?
Most handoff friction starts with differences in assumptions, which Figma's designer and developer trends report names as the challenge developers raise most often (Figma). The file shows the happy path, the ticket drops the reasoning, and the engineer fills the gaps under sprint pressure. Fixes then wait in someone else's queue.
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.