Design Handoff: How to Hand Designs to Developers

Design handoff is the moment a finished design goes to the people who will build it. A clean handoff gives the developer everything they need to build without guessing: the final screens, every state, the real content, the assets, and the rules that a picture cannot show. If the developer has to guess, you pay for it later in rework.

This guide is for business owners, designers and developers working on websites and small products. It covers what to hand over, what to write down, and how to run the handover itself. Checking the finished build against the design is a separate job, covered in our design QA checklist.

Key takeaways

• A handoff has three layers: what to build, how it behaves, and why. Most files only cover the first.
• Hand over every state of every screen, not just the happy path: hover, error, empty, loading, long text.
• Write down what the file cannot say: logic, edge cases, priorities.
• Talk to a developer before the design is final, not after.
• Real content and a short 30-minute walkthrough prevent most rework.

What is design handoff?

Design handoff is the transfer of a finished design from the designer to the developer, together with the information needed to build it accurately. It is a process, not a file export. The three layers below are a useful way to check that nothing is missing.

Developers can read the visual layer from the file. The logic and intent layers only exist if someone writes them down. That is where most handoffs fail.

What should a design handoff contain?

A complete handoff contains seven things. Use this as a list to check against before you send anything.

Two of these deserve a closer look.

States. A button is not one picture. It has a default, hover, focus, pressed and disabled look. A form field has an error state and a success state. A list has an empty state. If a state is not designed, the developer decides it, and the result is rarely what you would have chosen.

Design tokens. Tokens are the named values behind a design: the exact grey, the heading size, the spacing step. When the file uses shared styles, a developer can copy the names into code and everything stays consistent. If you do not have these yet, what a design system is explains the minimum worth setting up.

What should you write down that the file cannot say?

Write down the logic, the edge cases and the priorities. A design file shows one moment in time. It does not show what happens when a name is 60 characters long, when a user has no results, or when the network fails.

Add short notes for each of these:

• Logic. What decides what the user sees. For example: "Show the discount badge only on products with a sale price."
• Edge cases. Very long text, very short text, missing images, zero results, a thousand results.
• Validation. Which form fields are required, what counts as a valid value, what the error message says.
• Priorities. What must be exact (brand colours, the main call to action) and what can flex (exact image crop, small spacing).
• The why. One sentence on the goal of the page. A developer who knows the goal makes better small decisions.

For a marketing website, add the parts that are easy to forget because they are not visible in the design:

• Page title and meta description for each page
• Heading structure (one H1, then H2s and H3s in order)
• Alt text for images
• Form destinations: where submissions go and who is notified
• Redirects from old URLs, if you are replacing a site
• CMS fields: which text and images the client must be able to edit themselves

These are the items that cause late surprises, because nobody sees them in a design file.

How does handoff work when designer and developer are different people or companies?

When they are different companies, the handoff needs more writing and a live walkthrough. When they are the same team, it needs less ceremony but the same content.

If you are a business owner passing a design to a new developer, send the file, the written notes, the content and the brand assets together, and book one call. Ask the developer to list their questions in writing before the call. Their questions are a free quality check on your design.

If the designer and developer are the same person or studio, it is tempting to skip the handoff. We design and build in the same studio, and we still write it down. The reason is practical: a decision made in week one is forgotten by week six, and it shows up as a bug. A page of notes costs an hour. Forgetting costs more.

Which tools help with design handoff?

Use the tool your team already has. The tool matters less than the habits above. Figma's Dev Mode is the most common choice now. According to Figma's documentation, designers can mark frames and components as ready for development, developers get notified, and the inspect panel shows properties, styles, variables and downloadable assets. Designers can also add measurements, callouts and text notes so developers do not miss important specs.

A few practical points:

• Mark only finished frames as ready. Everything else is a draft.
• Name layers and components in plain words a developer can search for.
• Use components and shared styles instead of loose shapes with copied values.
• Generated code snippets are a starting point. A developer still has to decide how the page is built.

Other tools, such as Zeplin, do a similar job. Plain annotated screenshots and a shared document also work for small projects.

How should you run a handoff meeting?

A good handoff meeting takes 30 minutes with the file open on screen. Here is an agenda that works.

1. Goal (3 minutes). What this page or product has to achieve and for whom.
2. Walkthrough (12 minutes). Go through each screen in order, including states and mobile.
3. Edge cases and logic (7 minutes). Cover the written notes. Ask the developer what they would find hard.
4. Priorities and trade-offs (4 minutes). Agree what must be exact and what can flex.
5. Questions and next steps (4 minutes). Who answers questions, where, and how fast.

Afterwards, write down what was agreed and send it to everyone. A decision that was only spoken is a decision that will be disputed.

When is the right time to hand off?

Bring a developer in before the design is final, then do the formal handoff once the design is approved. Early contact lets a developer point out what is slow, expensive or not possible in the browser. A heavy full-screen video or an unusual animation is easier to change on day three of design than on day three of build.

Formal handoff is ready when four things are true: the client has approved the design, the content is real, every screen has its states, and the file is tidy. If one is missing, you are handing over a draft, and the developer will build on assumptions.

What are the most common design handoff mistakes?

These five cause most of the rework we see.

A sixth mistake is newer. Some teams generate code straight from a design with an AI tool and treat the result as finished. This can save time on a first draft. It does not remove the need for a clean file, because the quality of the output depends on how well the design is organised, and it still has to be checked for accessibility and performance. Two measurable targets are worth writing into the handoff. WCAG 2.2 asks for touch and click targets of at least 24 by 24 CSS pixels at level AA. Google's Core Web Vitals set the good thresholds at 2.5 seconds or less for loading the main content, 200 milliseconds or less for responding to input, and a layout shift of 0.1 or less.

What happens after the handoff?

The design goes into the build, the developer asks questions, and then the finished build is compared with the design before anyone signs it off. That second step is design QA: checking spacing, type, states, responsive layouts and behaviour in a real browser. Our design QA checklist lists what to check.

Keep the designer available during the build. Questions will come, and a quick answer is cheaper than a wrong guess. If your brand rules are not yet written down, a brand brief makes the later handoff easier, because colours, voice and logo rules are already settled.

A short handoff checklist

Copy this and tick it off before you send the file.

• A developer has seen the rough design
• Client approval is in writing
• Every page has a desktop, tablet and mobile layout
• Every component has all its states
• Layers are named; components and styles are used
• Colours, type sizes and spacing are named styles or variables
• Content is final: headings, text, labels, alt text
• Assets are exported and sized
• Interactions and timings are described
• Logic, edge cases and validation are written down
• Page titles, meta descriptions and form destinations are listed
• The editable CMS fields are listed
• A 30-minute walkthrough is booked
• Who answers questions during the build is agreed

Where to go from here

A clean handoff is mostly about writing things down and talking early. If you want designs that are built by the same people who drew them, that is how we work in our Design & Development service: one two-person studio in Las Palmas de Gran Canaria, working remotely with clients across Europe, the Gulf and the US.