Design handoff

Handoff is less a single moment than a working agreement. The files alone rarely answer every question: what happens when a name is too long, how a menu behaves on a tablet, what an error message says. A good handoff anticipates those questions; a poor one leaves developers to guess, and the built site drifts from the approved design.

Handoff is easiest when designers and developers share a design system or component library, because most decisions already exist as named parts in both the design files and the code.

How it works

Before handoff, designers tidy the files: final screens grouped by page and screen size, components named consistently, colours and spacing defined as design tokens and assets ready to export. Design tools such as Figma let developers inspect measurements, colours and type directly, so fewer separate specification documents are needed.

The handoff itself usually includes a walkthrough meeting, written notes on interactions and edge cases, every component state, responsive behaviour between the drawn widths and rules for content. The designer then reviews the built pages against the design and logs differences before launch.

Timing matters as much as the files. Developers who see designs only at the end often discover that a layout is hard to build, a font is not licensed for the web or a feature depends on data the system does not hold. Bringing a developer into reviews before sign-off catches those problems while they are cheap. After the build, a side-by-side review of the design and the live pages on real devices, with differences logged as a list, closes the loop.

Example

A designer sends a developer a link to forty screens for a clinic's new site. Questions follow for weeks: how the doctor cards behave with four doctors instead of three, what the booking form shows when the chosen day is full, and whether the hero photo crops differently on phones. On the next project a handoff checklist covering empty, error and overflow states is completed before the build starts, and far fewer questions come back.

The checklist for the next project is short and specific: every component in its default, hover, focus, error, disabled and loading states; each page at phone, tablet and desktop width; what happens with no data, too much data and a slow connection; and the exact wording of every error message. The developer reviews the file against the checklist before building and sends remaining questions in one batch instead of one at a time.

Why it matters for your business

A messy handoff costs time and money: developers wait for answers, guess wrongly and rebuild, and the launch slips. It also shows in quality, because small inconsistencies in spacing, states and behaviour add up to a site that feels less polished than the approved design. On small projects where one person designs and builds, handoff is mostly internal, but the same checklist still catches the states nobody drew. A good handoff costs a few hours of preparation and review; a poor one can easily run to days of rework.

Common mistakes

• Handing over only the ideal screens and leaving errors, empty states and long content undesigned.
• Leaving old versions and experiments in the file, so developers cannot tell which design is final.
• Naming components differently in the design file and in the code.
• Ending the designer's involvement at handoff instead of reviewing the build.

Questions people ask

What should a design handoff include?

Final screens at each breakpoint, all component states such as hover, focus, error and disabled, exported assets, colour and type definitions, spacing rules, notes on interactions and animation, and guidance for edge cases such as long text or missing images. A short walkthrough call and a named person to answer questions during the build complete it.

Do developers still need a specification document?

Less often than before. Collaborative design tools let developers inspect sizes, colours, fonts and spacing directly and export assets themselves. Written notes are still needed for behaviour a static design cannot show: what triggers what, validation rules, responsive changes and states that only appear under certain conditions.

How can I make design handoff smoother?

Involve a developer before the design is final so technical limits surface early, use a shared design system or components, name things consistently in design and code, and design every state rather than only the ideal one. Keep the designer available during the build and schedule a review of the built pages before launch.