The Intent Ledger
← All articles

Design Handoff Checklist: 12 Checks Before You Ship

Design Handoff Checklist: 12 Checks Before You Ship

A good design handoff checklist covers four things: the visuals, the behavior, the files and access, and the reasons behind the choices. Most checklists stop at the first two. This one goes through all four, for product designers handing off to developers and for freelancers handing a finished project to a client.

Use it as a gate. If an item is not done, the handoff is not done.

Theintentledger
Keep the Why Behind Every Handoff
The Intent Ledger turns project conversations and critique feedback into source-backed records of decisions, design intent, risks, and actions.
Explore project memory

TL;DR

  • Design every interactive state, not just the happy path: default, hover, active, focus, disabled, loading and error.
  • Write accessibility down. Focus order, heading levels and accessible names are design decisions, not things developers should guess.
  • Walk the prototype with the developer before any code is written.
  • For freelance handovers, release files and account ownership in a fixed order: acceptance, final invoice, verified payment, transfer.
  • Record why each decision was made, with a link to the conversation it came from. Specs show what; a decision record shows why.

Table of Contents

Why handoffs fail

Handoff is rarely lost in one big mistake. It leaks through small gaps: a missing error state, a color pasted as a hex value, a keyboard path nobody defined.

Research from a design-engineering studio describes the root cause as different mental models. A designer sees a component as a visual rectangle. A developer sees a coded entity with props, variants and API dependencies. Their advice is to treat the design file and the codebase as two views of the same system instead of throwing work over a wall.

That framing shapes everything below. The checklist is not paperwork for the designer’s protection. It is the shared definition of “ready” between two people who see the same button differently.

Two cautions before you start:

  • Co-write the list. Checklists work best when developers help write them, and when they live inside the design tool as a note or comments rather than in a separate document.
  • Track what gets skipped. If an item is ignored again and again, the same source suggests it either does not apply to your workflow or the process is broken. Cut it or fix it.

The checklist at a glance

# Check Done when
1 Scope and flow The screen, component or flow is named and the user journey is stated
2 Components and variants Every variant is built, named and matches the system
3 Interactive states Seven core states are shown per interactive element
4 Tokens Color, type and spacing use named tokens, not raw values
5 Responsive behavior Breakpoints and reflow rules are annotated
6 Edge cases Empty, error, long-text and loading states exist
7 Motion Duration and easing are written down
8 Accessibility Focus order, headings, names and contrast are annotated
9 Assets Icons, images and exports are named and delivered
10 Walkthrough You and the developer have tested the prototype together
11 Decision record Open questions and the reasons for key choices are logged
12 Access and ownership Accounts, files and credentials are transferred securely

Checks 1 to 10 apply to any design-to-development handoff. Checks 11 and 12 matter most when the work changes hands between people or companies.

Part 1: What the developer needs to see

1. Scope and flow

Name exactly what is being handed off: the screen, the component or the whole flow. Add two sentences on the user journey it belongs to. A developer who understands the goal makes better calls when the spec is silent.

2. Components and variants

Confirm every component is the current version from your library, with variants named the way the code will name them. If a component is new and not yet in the system, say so. Do not let a one-off detached copy pass as a standard part.

3. Interactive states

This is the most common gap. A comprehensive handoff should document default, hover, active or pressed, focus, disabled, loading and error. Guides commonly cite five to seven core states for interactive elements, and missing ones are a frequent cause of rework, because developers have no source of truth for the full behavior.

A practical layout: put each state in its own frame, side by side, with the state name in the layer label. Another freelance workflow guide lists error messages, loading and skeleton states, hover, focus and active states, and responsive breakpoint notes as the annotations that save the late-night edge-case question.

4. Tokens

Colors and spacing pasted as hex codes and pixel values force the developer to reverse-engineer your system. Name them. If the project has no token set yet, at least name the roles (primary action, surface, border, body text) and the spacing scale.

5. Responsive behavior

Show the layout at each breakpoint the product supports, and write the rule when the change is not obvious: what stacks, what truncates, what hides, what stays fixed.

6. Edge cases

Design the screen with no data, with one item, with a very long name, with a failed request and with a slow connection. Include the actual error copy and the condition that triggers it. These are the cases developers hit first and ask about last.

7. Motion

Inspect tools generate CSS, but they often miss easing curves, animation timings and integration logic that need manual annotation. Write duration, easing and what triggers the animation. Say what happens when a user prefers reduced motion.

8. Accessibility

Accessibility has to be explicit rather than inferred from visuals. That means annotating heading hierarchy, logical tab and focus order, landmark roles and accessible names for icon-only buttons. WCAG AA contrast is the minimum bar, and the same guidance asks you to specify focus indicator visibility and what a screen reader should announce. Its framing is useful: when these annotations are missing, that is a design gap, not a development bug.

9. Assets

Export icons, illustrations and images in the formats the project uses, with consistent file names. Note which are placeholders. Keep source files in a shared location the team controls, not on your laptop.

10. The walkthrough

Before implementation starts, sit with the developer and click through the prototype together. Accessibility practitioners call this a handoff ritual: the developer tests keyboard navigation, screen reader flow and edge cases, and ambiguity surfaces before code exists, which is far cheaper than fixing it afterward.

Treat the walkthrough as the point where the spec becomes a shared one. Write down every question that comes up and its answer.

Part 2: The part most checklists skip, the why

A flawless spec still leaves a hole. Six weeks later a developer asks why the confirmation step exists, or a client asks why you rejected their preferred layout. The spec shows what the design is. It does not show what you weighed.

This is what design handoff documentation usually lacks: the reasoning. It is also what a junior designer, a replacement freelancer or a project manager needs most when picking up work midstream.

For each significant decision, capture:

  • The decision in one sentence.
  • The intent: what problem it solves and for whom.
  • The alternatives considered and why they lost.
  • The source: the meeting, critique or client comment where it was agreed.
  • Risks and open questions that remain.
  • The owner and any commitment attached to it.

If you want a ready structure, our design documentation template is built around capturing decisions rather than just tasks. For the review stage that precedes handoff, the three-phase design review checklist shows how to preserve decisions as you go, and these design review notes templates cover the note-taking side.

Perspective: what we see in handoffs

We build project memory software for design teams, so we read a lot of project conversations. The pattern we keep coming back to is that handoff problems are usually memory problems. The spec exists. The reasoning behind it lives in a call, a critique, a chat thread or a client email, and nobody tied them together.

That is why we focus on the why behind the work, not just the what. A decision with no traceable source is hard to defend and easy to reverse by accident. A new person joining the project cannot tell a deliberate constraint from an old leftover.

Our advice is simple. Do not wait until handoff day to reconstruct the reasoning. Log it where it happens, link it to the conversation, and mark what is still unresolved. Then the handoff is a review of a record that already exists, not an archaeology project.

The same applies to students and juniors. If you cannot say where a task came from, ask, and write the answer next to it.

, Rajas

Part 3: Freelance design handover

When you hand a project to a client instead of a developer, the risk shifts. Visual completeness still matters, but now payment, ownership and liability do too.

Define done in writing

Before you ship anything, write one short paragraph that defines done. One offboarding checklist suggests covering final files delivered, revisions used or closed, final invoice sent, access transferred and documentation handed over. Compare it against the original scope or contract so nothing is promised that was never agreed.

Release in a fixed order

For freelance and agency work, experts recommend a gated sequence. The ClearTimeline guide describes it this way:

  1. Request explicit client acceptance, with a review period (they cite 10 days as a common standard).
  2. Issue the final invoice.
  3. Verify that payment has arrived.
  4. Only then transfer ownership of accounts and final files.

The same guide defines silence after the review period as deemed accepted, which limits indefinite scope creep. Put that rule in your contract at the start, not in an email at the end.

Say what the client owns

A handover clause should identify the exact deliverables and state whether the deal is an assignment of rights or a limited license, and it should tie release to verified payment. One drafting guide for UX and UI freelancers lays out this structure. Rights and liability vary by contract and jurisdiction, so have a lawyer review your clause before you rely on it.

Avoid orphaned accounts

Transfer ownership of hosting, SaaS tools and domain registrars to the client’s own accounts. Emailing a password is a security failure; use a password manager or another secure transfer method. Staying on as admin on your own account leaves you with unpaid support requests for years.

Share the right file

Give the client what they need, not your working file with every abandoned exploration. A dedicated, cleaned-up view with annotations is easier for them to use and protects your process.

Keep the record of client decisions

Freelancers lose the most context when client feedback sits in email. Keep a log of what the client asked for, what you decided and why. Our guides on client feedback tracking and client comment tracking show a lightweight way to do it, and client meeting documentation covers what to capture in the room.

A worked example

Imagine a settings screen with a toggle for email notifications.

Visual spec: the toggle in default, hover, focus, disabled, loading (while saving) and error (save failed) states, on mobile and desktop widths, using named tokens for the track color and spacing.

Accessibility notes: the toggle has an accessible name tied to its label, focus order follows the visual order, the focus ring is visible against both backgrounds, and a screen reader announces the saved state.

Motion: the thumb slides over a short duration with an easing curve you name, and the animation is skipped for reduced motion.

Decision record: “Save on toggle, no Save button. Intent: fewer steps for a low-risk setting. Alternative rejected: explicit Save button, because users forgot to press it in the review session. Source: Tuesday critique. Open question: should failure revert the toggle or show a retry?”

That last paragraph is what the developer and the future designer will thank you for. It is also the one almost nobody writes.

Run the handoff in five steps

  1. Prepare. Work through checks 1 to 9 and mark gaps honestly.
  2. Pre-read. Send the file and decision notes to the developer a day before the call.
  3. Walk through. Click the prototype together, keyboard first, then pointer.
  4. Log. Write down every answer and every unresolved question, with an owner.
  5. Review the list. After the build, note which checklist items were never used and which gaps you only found late. Update the checklist.

Where The Intent Ledger fits

If your decisions are scattered across calls, critique sessions and client comments, we turn those conversations into ILM Records: structured, source-backed records of decisions, design intent, risks, actions, commitments and unresolved questions, each traceable to the conversation it came from. That gives your handoff a finished decision record without a week of reconstruction.

You can start small. The Working Set is 12 $ one-off, and the Project Record is 29 $ one-off. If you create records continuously, the Working Memory plan is 29 $ per month. See everything on the pricing page, or read about the product on our homepage.

FAQ

What should a design handoff checklist include?

At minimum: the flow and scope, components and variants, all interactive states, tokens, responsive rules, edge cases, motion details, accessibility annotations and exported assets. Add a walkthrough with the developer and a record of decisions and open questions. The last two are the items most teams forget.

What is design handoff documentation?

It is everything that lets someone build or maintain the design without asking you: specs, annotations, assets and the rationale for key choices. The rationale part matters most when people change mid-project. Link each decision to the conversation where it was made.

Is Figma Dev Mode enough for a handoff?

No. It supplies measurements, code snippets and exports, but easing, timing, integration logic and accessibility behavior still need manual notes. Use it as one input, not as the documentation.

How should a freelancer hand over design work to a client?

Define done in writing, get explicit acceptance, send the final invoice, confirm payment, then transfer files and account ownership. Move third-party accounts into the client’s own name and share credentials through a password manager. Have a lawyer check the ownership and license wording in your contract.

How long should a client review period be?

Ten days is a commonly recommended window for acceptance, with silence treated as deemed acceptance. Whatever you choose, agree to it in the contract before the work begins.

Sources

Design Handoff Checklist: 12 Checks Before You Ship: The Intent Ledger Blog