Handoff is a conversation

Developer handoff is the process of transferring a finished design to engineers so they can build it. Throwing designs over the wall is how designs die.

Many new designers picture handoff as a single moment: you finish the screens, share a link, and move on. But a design file answers maybe half the questions an engineer will have while building. The other half live in your head, and if you disappear after sharing the link, engineers will answer those questions themselves, on a deadline, without your context.

Handoff is not a delivery, it's an ongoing conversation that starts before the design is finished and ends only when the build ships. Your job during that conversation is to make the engineer's decisions easy: what happens here, why does it work this way, and what should it do when things go wrong.

    keywords
  • #DeveloperHandoff
  • #Collaboration
  • #Communication

What engineers actually need

A polished mockup of the happy path is the least useful part of a handoff, because it's the part engineers could have guessed. What they can't guess is everything around it.

Every state

A screen is never just one screen. A button has a default, hover, focus, pressed, and disabled state. A list has a loading state, a populated state, an empty state, and an error state. The empty and error states are the ones designers forget most often, and they are exactly the states engineers will improvise if you don't design them.

Walk through your flow and ask at every step: what does this look like while data loads? What does it look like when there is nothing to show? What does it look like when the request fails? A booking app with no designed empty state ends up shipping a blank white screen where "You have no upcoming trips" should be.

Edge cases

Your mockups probably use tidy sample data: a short name, three items, a perfect photo. Real data is messy. Design for the longest plausible name, the user with zero items and the user with nine hundred, the missing avatar, and the person using the product offline or on a slow connection. If you only design with ideal content, you haven't designed the product, you've designed the demo.

Behavior specs

Static screens show what the interface looks like, not how it behaves. Spell out the behavior in plain language: this panel slides in from the right over 300 milliseconds, this form saves automatically when a field loses focus, this upload shows a retry option if it fails. Pay special attention to failure behavior. What happens when a payment doesn't go through matters far more than how the success screen animates.

The why behind decisions

Engineers make dozens of small judgment calls during a build, and they make better ones when they understand your intent. If a checkout button is deliberately disabled until every field is valid because testing showed users submitting incomplete forms, say so. When engineers know why a decision was made, they can protect that intent even in situations you never anticipated.

    keywords
  • #States
  • #EdgeCases
  • #BehaviorSpecs
  • #DesignIntent

Annotating your designs

Annotations are short notes attached to your designs that explain what a static picture can't. The goal is not to write a novel next to every screen. Engineers won't read walls of text, and most of the design doesn't need explaining.

Annotate where ambiguity lives, and nowhere else.

A good annotation answers a question an engineer would otherwise have to ask or guess: character limits on an input, what the search does with no results, which fields are required, where the user lands after a successful submission. If a note just restates what's visible, delete it. If your team already has a design system, lean on it: naming the exact token or component in your notes means one shared word replaces a paragraph of description.

    keywords
  • #Annotations
  • #Documentation
  • #DesignTokens

Involve engineers before handoff

The most expensive feasibility conversation is the one that happens after the design is finished. If you learn at handoff that your real-time preview would take a month to build, you're redesigning under pressure and the engineer is the bearer of bad news.

Instead, show engineers rough work early. A quick "is this direction sane to build?" while you're still exploring costs fifteen minutes and can save weeks. Engineers also know things you don't: what data is actually available, what the system can do cheaply, and sometimes a technical capability that unlocks a better design than the one you had. Engineers who help shape a design will fight to build it well; engineers who receive a finished design will just build it.

    keywords
  • #Feasibility
  • #EarlyCollaboration
  • #Constraints

Reviewing the build

Design QA means reviewing the implemented product against your design before it ships. It's not an optional courtesy, it's part of the job. Small differences accumulate: spacing drifts, a focus state goes missing, an error message falls back to raw server text. Together those small differences make the product feel unfinished.

Review on a real device, not just your monitor, and walk the actual flows, including the failure paths. When you find differences, file them kindly and precisely. "The button looks off" is useless; "the primary button uses 12px vertical padding, the spec is 16px" is fixable in a minute. And name what's working, too. Engineers who feel respected in QA will invite your feedback; engineers who feel nitpicked will stop showing you the build until it's too late to change.

    keywords
  • #DesignQA
  • #Review
  • #Precision

When you hear "that's not possible"

Sooner or later an engineer will tell you something can't be built. Your first move should be curiosity, not defense. "That's not possible" usually means one of several things: it's genuinely impossible, it's possible but very expensive, it conflicts with something else in the system, or the engineer misunderstood what you're asking for. You can't respond well until you know which one it is.

Ask what specifically makes it hard, and explain the user problem your design is solving rather than defending the pixels. Once you both understand the constraint and the goal, you can weigh trade-offs together: a simpler version now, a phased approach, or a different pattern that solves the same problem. Often the constraint kills your solution but not your idea, and the version you find together is better than either of you would have reached alone.

    keywords
  • #TradeOffs
  • #Curiosity
  • #ProblemSolving

Takeaways

A design is only as good as its implementation, and the implementation is only as good as the handoff.

Treat handoff as a conversation, not a delivery. Document every state, especially empty and error. Design for messy real data, spec the behavior and the why, annotate only where ambiguity lives, bring engineers in early, review the build with precision and kindness, and meet "that's not possible" with curiosity.