Design Handoff to Developers: What to Pass Over So Nothing Gets Lost

Design handoff is the moment a design leaves the person who imagined it and enters the hands of the person who will build it. In many projects it is a single link to a file and a message saying "all done". Weeks later, the live site looks similar but not right: spacing is off, an important state is missing and the mobile version has been improvised. Nobody is to blame. The design simply did not carry all the information that building requires. A better handoff fixes that.

Pictures are not a specification

A screen mock-up shows one moment. Developers need the rest: what happens when the cursor hovers over a button, when it is pressed, when it is disabled, when the keyboard focuses it. They need to know how a card looks with a very long title, with no image, with an error. Designing these states, even roughly, is part of the job. Without them, the developer invents them, usually under time pressure.

Hand over the system, not the screens

Describe the building blocks and the rules: the palette with names and values, the type scale, the spacing steps, the shadows and the corner radii. Where the project uses design tokens, variables that hold these values, the designer and developer should use the same names. When a colour changes, it changes once, in one place, and both the design file and the code agree.

Explain behaviour and intent

Annotate what the design is trying to achieve. Why is this button at the bottom? What should happen when a form fails? How does the menu animate, and for how long? Is the animation important or decorative, and what happens for visitors who prefer reduced motion? A short note explaining the reason lets a developer make a sensible decision when the unexpected arises, rather than a literal one.

Cover the screens in between

Provide the layouts for the widths that matter, typically small phone, large phone, tablet and desktop, and explain how the layout flows between them, not just at the extremes. Note how long text wraps, how images crop and what is hidden or reordered on small screens. Show the empty, loading and error versions of each view, and the first-time experience.

Think about accessibility from the beginning

Annotate the reading order, the headings, the labels, the focus order and any text alternatives. Check colour contrast in the design file, not after the build. Specify touch target sizes and what happens with enlarged text. It is far cheaper to settle these in the design than to retrofit them in code.

Use real content

Lorem ipsum hides problems. A design that works with a tidy two-line heading may fall apart with a real one of six words. Test the design with real headlines, real names and real images, including the awkward ones. Agree who is responsible for writing the final content and when it will arrive.

Review before it ships

Talk early, not just at the end

The best handoffs are not a moment but a conversation that runs through the project. Invite a developer to look at early sketches, so that they can point out what will be difficult, what is cheap and what the platform already provides. A ten-minute chat at the start can reshape a design into something that is both beautiful and straightforward to build. Likewise, let designers see work in progress, so that small corrections happen before they pile up.

Keep a shared record of decisions

Write down why choices were made, such as why a menu collapses at a particular width or why a button is a specific colour, in a place both sides can find. When the project is revisited next year, or a new person joins, the reasoning is still there. A short log of changes to the design system, with dates, saves repeated arguments and makes the whole team faster.

Plan a review where the designer looks at the built work in the browser on real devices, and logs differences as a list rather than as scattered comments. Developers can then fix them in order of importance. Treat the exchange as collaboration, not inspection. If you would like us to help set up a smoother process between your designers and developers, we have a short checklist we are happy to share.