By Nick Babich
Key Takeaways
- What design handoff is: the point where approved designs, specs, assets and the reasoning behind them pass to the people who build the product. Your side's job starts when that package arrives for review.
- What the package must show: presence checks for final screens in every state, components and tokens, behavior notes, final copy, assets, a prototype of the main flows, and owned open questions. Definitions of those artifacts live elsewhere.
- Who signs it off: the engineering lead and the product owner on your side, not only the design team that produced it.
- How to accept it: treat the checklist as acceptance evidence on one real feature before development starts. Accept, accept with conditions, or return it.
- What closes the loop: before launch, confirm a design QA report exists and that critical defects were addressed. Put review windows in your statement of work, not in this checklist.
Design handoff is the moment approved designs become instructions a developer can build from without guessing. A good handoff carries the files, the measurements and the intent: what each screen looks like in every state, how it behaves, which components and tokens it uses, and why key decisions were made. A weak one is a link to a design file and a hope that the build team reads it the same way the designers did.
Stage 9 of the stages of a typical UX project covers how the design team prepares the handoff package and later runs design QA on the build. This guide starts where that stage ends for you: the client's review. You decide whether the package is ready to build, and later whether critical design defects on staging were closed. If you are comparing outside partners, the independent rankings of product UX design teams on this site are a fair place to start, and if your product relies on a shared component library, look at the design system agencies we have reviewed, because handoff quality depends heavily on how components and tokens are set up. Below you will find presence checks for the package, who signs off, a client-side review flow, an acceptance checklist you can copy as evidence, an illustrative worked example, and a short pointer to where acceptance belongs in your agreement.
What a Design Handoff Is (and What It Is Not)
A design handoff transfers three things at once. The first is the what: layouts, spacing, typography, color, components and assets. The second is the how: interactions, transitions, validation rules, responsive behavior and states such as empty, loading and error. The third is the why: the user problem, the business rule or the research finding that made the team choose this design over the alternatives. Developers who get only the first part build what they see. Developers who get all three can make sensible calls when the design does not cover a case.
It is not the end of the design team's involvement, and it is not a one-meeting dump of screens. The costliest handoffs I have seen were one-off events: polished screens presented, designers gone, and the build team filling gaps for weeks. Your review of the package is the gate before sprint one. A later design QA report is the gate before launch. Neither replaces the other.
It is also not a second glossary of UX artifacts. Journey maps, research reports and information architecture shape the design, but most of them are not things a developer builds from. For what each artifact is and how to judge its quality, use our explainer on wireframes, prototypes and other UX deliverables. This article only checks whether the build-facing slice is present and usable.
Package Presence Checks
Use the table as a presence pass, not a rewrite of artifact definitions. For any feature that goes into development, confirm each row is present or that someone can say why it is out of scope.
| Check | Passes when present | Common miss |
|---|---|---|
| Final screens, all states | Default, empty, loading, error, success and permission-denied states exist for each screen at each supported breakpoint | Only the happy path is drawn |
| Component specs | Library components, variants and props are named; any new component has a short spec | Detached one-offs that look like library parts |
| Design tokens | Color, spacing, type, radius and elevation use named values mapped to code names | Raw hex or pixel values on new screens |
| Interaction notes | Tap, hover, focus and keyboard behavior, transitions with timing, and validation rules are written or prototyped | Behavior lives only in a designer's head |
| Prototype of main flows | A clickable path exists for the two or three flows that matter most | Static frames only for multi-step flows |
| Final copy | Labels, help text, error messages, empty-state text and any emails or notifications are final | Placeholder strings still in the file |
| Assets | Icons and illustrations export in the agreed formats with names that match code | Flattened icons that cannot be recolored |
| Accessibility notes | Focus order, visible focus style, contrast checks and labels for icons and fields are specified | No focus style at all |
| Data and logic notes | Required data, defaults, sorting and limits such as longest name or largest list are listed | Every mockup uses a short name and five rows |
| Decision log and open questions | Key decisions have a reason; unresolved questions have an owner and a date | Questions scattered across comments and chat |
One practical note on the files. If your team works in Figma, ask the design team to group finished work into sections and mark them ready for development, and to keep work in progress outside those sections. Figma's documentation on Dev Mode statuses and notifications explains how a design marked ready for dev switches to a "Changed" state when someone edits it, which gives developers a visible signal instead of a surprise.
Who Signs Off on the Client Side
Handoff fails when everyone assumes someone else is checking. Name one person for each role before the walkthrough.
- Design lead (outside team): prepares the package, runs the walkthrough, answers questions within an agreed time, and produces the design QA report after the build.
- Engineering lead (your team): checks that components and tokens map to code, and signs the acceptance checklist as evidence the package is buildable.
- Product owner (your team): confirms the designs match scope and business rules, approves final copy, and decides trade-offs when design and build constraints conflict.
- QA: uses the states and acceptance evidence to write test cases, so "matches the design" has a concrete meaning.
How the Client Review Works
Once the package is marked ready, keep the review short and decisive. I use three steps before development, plus one acceptance check before launch.
1. Walkthrough of final designs. A 60 to 90 minute session where the design lead walks the main flows, explains decisions and edge cases, and records questions.
2. Acceptance review. Within two to three business days, your engineering lead and product owner run the checklist below on the package. The checklist is evidence for your decision, not legal wording. The result is one of three decisions: accept, accept with conditions and a date, or return.
3. Decide and start (or hold) the sprint. Only flows that passed, or that have a dated fix, enter development.
4. Before launch: design QA report check. Confirm a design QA report exists for the staging build and that critical defects were addressed or explicitly deferred with an owner. This article does not cover how to run staging QA. It only asks whether that report and the critical-defect outcome are part of your acceptance evidence.
The Handoff Acceptance Checklist
This is the original tool in this article: twelve checks your side can run without being a designer, framed as evidence that the package is ready to build. Each one has a pass condition you can verify by opening the files, so the review does not turn into a debate about taste. Run it on one real feature first, then on the rest. Do not paste these lines into a contract. Use them to record what you saw and what you decided.
| # | Check | Passes when | Common gap |
|---|---|---|---|
| 1 | Final version is clear | Finished screens are in marked sections; drafts are elsewhere | Three versions of the same screen side by side |
| 2 | Scope matches | Every screen listed in the scope exists, and nothing new appears without a note | Extra "nice to have" screens nobody budgeted for |
| 3 | States covered | Empty, loading, error and success exist for each data-driven screen | Error states only for the login form |
| 4 | Breakpoints covered | Each supported screen size is shown, or the resize rule is written down | Desktop only, "mobile is similar" |
| 5 | Components reused | Screens use library components; new ones are listed with specs | Detached copies that look like library parts |
| 6 | Tokens mapped | Colors, spacing and type use named tokens that your engineers recognize | Raw hex values on new screens |
| 7 | Behavior described | Interactions, transitions and validation rules are annotated or prototyped | Validation rules live only in a designer's head |
| 8 | Copy is final | No placeholder text; every error message is written and approved | "Error message here" |
| 9 | Accessibility basics | Focus order and a visible focus style are specified; contrast was checked | No focus style at all |
| 10 | Assets exportable | Icons and images export in the agreed formats with sensible names | Flattened icons that cannot be recolored |
| 11 | Edge cases named | Long names, large lists, missing data and slow connections are addressed | Every mockup uses a short name and five rows |
| 12 | Open questions owned | Each unresolved question has an owner and a date before the sprint that needs it | Questions scattered across comments and chat |
For check 9, you do not need an accessibility specialist to spot the obvious gaps. The W3C explanation of WCAG 2.2 Focus Visible is a short, plain description of why keyboard users need to see where they are, and it is enough to ask the right question: where is the focus style defined?
How to decide from the evidence. My rule of thumb: if checks 1, 2, 3 or 8 fail across the whole feature, return the package, because those gaps change what gets built. If a gap is limited to one flow, or only checks 4 to 12 fall short and each gap has an owner and a date, accept with conditions and hold the affected flow. If all twelve pass, accept and start the sprint.
Worked Example: Illustrative Billing Settings Handoff
This worked example is illustrative and fictional. It is not a client case, and it is not the same scenario used in our statement-of-work or kickoff articles. Imagine a SaaS company that hired an outside design team to redesign its billing settings: plan overview, change plan, update payment card, and invoice history. Four flows, fourteen screens. The engineering lead and the product owner block 90 minutes, two business days after the walkthrough, and run the checklist as acceptance evidence.
| Check | Result | Note and action |
|---|---|---|
| 1, 2, 5, 7, 8, 10, 12 | Pass | Final sections marked, scope matches, copy approved, three open questions already owned |
| 3. States | Partial | No state for a declined card or for an empty invoice list. Design lead adds both, 2 business days |
| 4. Breakpoints | Partial | Invoice table has no mobile layout. Agree on a stacked-row rule, 1 business day |
| 6. Tokens | Partial | Two new warning colors are raw values. Map to existing tokens or add them to the library with the engineering lead |
| 9. Accessibility | Pass | Focus style taken from the library; contrast noted on the plan cards |
| 11. Edge cases | Pass | Long company names and 200-row invoice history shown |
Result: nine checks pass and three are partial. Check 3 is in the "return" group, but the gap sits in two flows only, so the team accepts with conditions: development starts on plan overview and change plan, which are complete, while the design lead finishes the declined-card and empty-invoice states. Payment card and invoice history move one sprint later. The cost of the review was 90 minutes for two people. The alternative would have been a developer discovering the missing declined-card state mid-sprint and inventing one.
Later, before launch, the same pair checks that a design QA report exists for the staging build and that every critical defect is closed or deferred with an owner. That is the only design QA step this guide asks you to enforce.
Where Acceptance Belongs in Your Agreement
The checklist above is evidence for your review, not contract language. If you need review windows, fix windows or what "handoff-ready" means written into the engagement, put those lines in the acceptance terms in your statement of work. Keep this article's checklist as the working record of what you checked and what you decided.
Common Handoff Problems and How to Prevent Them
- First look at handoff: developers seeing designs for the first time at the walkthrough. Ask for an earlier feasibility look during wireframes, then treat the walkthrough as confirmation, not discovery.
- Moving target: files that keep changing after sign-off. Use ready-for-dev markings and a change note for every edit.
- Missing QA evidence: staging ships without a design QA report or with critical defects still open. Make the report and the critical-defect outcome part of your launch acceptance evidence.
Frequently Asked Questions
What is a design handoff?
It is the transfer of finished designs, specifications, assets and design reasoning from designers to the developers who build the product. On the client side, handoff becomes real when you review the package before the sprint and later confirm that critical design defects on the build were addressed.
What files should a design handoff include?
Confirm presence of final screens in every state and breakpoint, component and token specs, interaction notes, a prototype of the main flows, final copy, exportable assets, accessibility notes, data notes, and a log of decisions and open questions. Use the deliverables guide linked above when you need definitions rather than a presence check.
Who should approve a handoff on the client side?
The engineering lead, who checks whether the package can be built as specified, and the product owner, who checks whether it still matches scope and business rules. Designers should not approve their own handoff.
How long should a handoff review take?
For a feature of ten to twenty screens, plan about 90 minutes for two people, plus a few days for the design team to close gaps. Review larger releases feature by feature.
Conclusion
A design handoff is ready when your team can build from it without guessing, and the only way to know is to check. Start from the client's review after the design team prepares the package, run presence checks, name owners on both sides, and use the twelve-point checklist as acceptance evidence on a real feature before development begins. Before launch, confirm a design QA report exists and that critical defects were addressed. Keep contract wording in your statement of work so this checklist stays a working record, not a legal document.
