Tags: web-dev ux concept

Design Handoff

Date: 2026-08-16

---

The moment a design becomes an implementation task. What a developer needs is mostly the things a static mockup can’t contain — and a design system’s real success is measured by how little handoff is left to do.

---

Design handoff is the transfer of a design to the person building it: the artefacts, the specification, and the conversation.

What a mockup can’t say

A static frame shows one state, at one width, with one set of content. Everything absent from that list has to arrive some other way:

IN THE MOCKUP        NOT IN THE MOCKUP
one layout           every other breakpoint
one state            hover, focus, disabled,
                       loading, error, empty
realistic content    long names, missing
                       images, 200 rows
one language         translated strings 40%
                       longer
final data           what shows while loading

See: Component States

The developer will decide all of it, because they have to ship something. The question is only whether they decide it with you or alone at 5pm.

What actually helps

Ranked by value, which is roughly the inverse of how much time gets spent on each:

1. Which existing components this uses. “Card, Button, Field” answers most questions instantly. This is the single highest-value line in any handoff — Design Systems
2. What’s new — genuinely new, versus a variant of something existing. It changes the estimate by an order of magnitude
3. Behaviour and interaction. What happens on click, on error, on slow network. A short video or a prototype beats a paragraph
4. Content rules. Maximum lengths, truncation behaviour, what’s required
5. Responsive intent. Not every breakpoint drawn — the rule. “Cards go one-up below 600px, the sidebar moves under the content”
6. Redlines and pixel values. Last, and mostly unnecessary if the first item was answered

Redlines are where most handoff effort goes and where least value is. If the design uses system components, the spacing is already decided — measuring it and writing it down is transcribing the token file.

The system changes the job

WITHOUT A SYSTEM
  hand off pixel values, colours,
  fonts, spacing, every state
  → developer rebuilds it

WITH A SYSTEM
  hand off which components,
  in what arrangement, with what
  content rules
  → developer assembles it

Handoff shrinking is the clearest sign a design system is working. If designers are still redlining padding on a component that exists in the library, either they don’t know it exists or it doesn’t do what they need — both are system problems, not process problems — Design System Adoption.

Where it goes wrong

• Handoff as a moment. A design thrown over a wall gets questions back for a week. Involving the developer early — even briefly, at the point the approach is chosen — costs less than the questions
• Designing what can’t be built, unknowingly. Usually not because it’s impossible but because it’s disproportionately expensive, and nobody said so while it was still cheap to change
• Pixel-perfect as the goal. A browser is not a canvas. Text reflows, fonts render differently, users zoom. The design intent — the relationships, the hierarchy — is what should survive; exact pixel positions can’t and shouldn’t
• No decision record. Six weeks later nobody remembers why the flow works that way, so it gets changed back
• One-way review. Designers checking the built result catches the misreadings that no specification prevents, and it needs to happen before release, not after

The useful question

Instead of “here’s the design”, the handoff that works is a conversation around:

“What’s new here, and what’s assembled from things we already have?”

That single question separates the expensive part from the cheap part, surfaces gaps in the system, and gives an estimate — all before anyone measures a margin — Component Inventory, Figma to Code.