Design handoff checklist
Template · 7 min read · By Utkarsh Dhairya Panwar · Updated
A design handoff is ready when an engineer can build the feature without asking what happens in any state. The ten-line checklist below covers file hygiene, states, edge cases, permissions, responsive behaviour, copy, tokens, analytics events and acceptance criteria, with a states matrix and event table to copy.
The checklist
Copy it into the ticket, the Figma file's cover page or a Notion doc. Tick each line or write 'n/a' with a reason. Any line left blank turns into a question in Slack later.
- File is ready: One page or section marked 'Ready for dev'. Explorations moved elsewhere. Frames named by screen and state ('Connect integration / no access'). Prototype link for the main flow.
- Component states: Default, hover, focus, pressed, disabled, loading, for every interactive component that isn't straight from the library.
- Screen states: First-use empty, no results, loading, partial data, error and success. Each one gets a designed frame rather than a comment describing it.
- Edge cases: Longest realistic name or title, zero, one and many items, truncation rule, very large numbers, dates across time zones, currencies and locales you support.
- Permissions: What each role sees: owner, admin, member, viewer, signed out. What a user without access sees instead of the feature.
- Responsive behaviour: Each breakpoint you support, and what collapses, stacks or hides between them. Tables especially.
- Copy is final: Every label, error message and empty state written. Who owns copy changes after handoff.
- Tokens and components: Colours, type and spacing bound to tokens instead of raw values. New components flagged as new. Any one-off deviation explained in a note.
- Analytics events: Every event the feature should fire, with name, trigger and properties. Use the table below.
- Acceptance and QA: What 'done' means for each screen, who does the design QA pass on staging, and what blocks release versus what can follow.
A states matrix for one screen
Fill this in for any screen that shows data. It catches most of the 'what happens if' questions in one place.
| State | When it happens | What the user sees | Designed? |
|---|---|---|---|
| First use | Account is new, nothing connected yet | One sentence on what will appear here, and the action to get it | Frame name |
| Loading | Data is being fetched | Skeleton matching the layout, not a centred spinner | Frame name |
| Partial | Some sources loaded, one failed | Loaded data plus an inline notice on the missing part | Frame name |
| Empty result | Filters return nothing | What was searched, and how to clear filters | Frame name |
| Error | Request failed | What happened, whether anything was lost, and a retry | Frame name |
| No permission | User's role can't see this | Who can grant access, and a way to ask them | Frame name |
| Overflow | Long names, many items | Truncation with full text on hover, pagination or virtual scroll | Frame name |
Most handoffs skip the no-permission row, and in B2B that's often where activation dies. At CodeAnt AI, onboarding broke at exactly this state: people without org admin rights trying to connect a repository. The story of fixing it is in how CodeAnt doubled trial-to-paid.
The analytics event spec
Events left out of the handoff get added after launch, and you lose the first weeks of data. Agree the names with whoever owns analytics and keep to one naming pattern: object, then action.
| Event name | Fires when | Properties | Question it answers |
|---|---|---|---|
| integration_connect_started | User clicks Connect on the provider step | provider, plan, role | How many try? |
| integration_connect_blocked | Install fails for lack of admin rights | provider, role | How many hit the wall? |
| admin_request_sent | User emails admin or copies invite link | method (email or link) | Which recovery path do people use? |
| integration_connect_completed | First integration connected | provider, time_since_signup | How many get through, and how fast? |
These rows use a generic integration-connect flow to show the format. Your event names will differ. What matters is that each one answers a question someone will ask in the launch review.
Why the system half of handoff matters
With a component library and named tokens in place, the checklist only has to cover what's new on a screen. Without one, every handoff describes every button. For me that's the main argument for a library, and my guide to design systems for startups covers how small it can start.
How to run the handoff itself
- Walk through it live for 20 to 30 minutes with the engineers building it, because async handoffs miss the questions people don't think to write down.
- Start with the user's goal and the metric, then the happy path, then states and edge cases.
- Ask engineers what's hard. You can simplify an expensive state now, which is better than finding out later that someone cut it.
- Book the design QA pass on staging before release, and compare it against the frames using real data lengths.
- Keep the Figma section frozen once building starts. Changes go in a dated new section, linked from the ticket.
The design handoff guide goes deeper on the working habits behind this list: starting at the flow, notes on frames, and the build review.
Questions people ask
Is Figma Dev Mode enough for handoff?
It handles measurements, tokens and assets well. What it can't tell engineers is what happens in states you never designed, which events to fire, or what 'done' means, so those still belong in the handoff.
Who should write the acceptance criteria?
The designer and product owner together, with an engineer reviewing them. Each screen should have a short list of what must be true before it ships.
When should design handoff happen?
In stages. Share the flow early so engineers can flag what's hard, then hand over the final frames with this checklist complete before the sprint starts.
Sources
- Guide to Dev Mode in Figma, Figma Help Center
- Skeleton Screens 101, Nielsen Norman Group
- Designing Empty States in Complex Applications: 3 Guidelines, Nielsen Norman Group
Working on this?
Tell me what you're building and where it's stuck: book a 30-minute call, email work@utkarshdesign.com or send a brief.