Design-Developer Handoff

The plain-language idea

Design-developer handoff is the process (and the artifacts) that carry a design from "approved mockup" to "built correctly," and most handoff failures aren't about the mockup being wrong — they're about the mockup being incomplete in ways that only surface once a developer starts wiring up real behavior. A static Figma frame shows one state of one component at one moment; a real UI has to handle every state, and someone has to have decided what each of them looks like before a developer improvises an answer under deadline pressure.

The three things a complete handoff needs beyond the polished mockup:

• Interaction states for every component — hover, focus, active, disabled, loading, and error, not just the default/happy-path appearance. A button that only has a "normal" state design forces the developer to guess what disabled or loading looks like, and that guess usually doesn't match what the designer would have chosen.
• Spacing and sizing specs a developer shouldn't have to eyeball. "About that much padding" measured off a screenshot produces a slightly-wrong implementation every time — actual values (ideally tied to the design system covered in this platform's Frontend Practices track) remove the guesswork entirely.
• A documented component inventory. Which of the mockup's pieces are new components, which reuse existing ones, and which are one-off compositions of existing components — without this, a developer can't tell "build a new component" from "just use the Card we already have," and the same visual pattern quietly gets rebuilt three different ways across a codebase.

See it in a real thing: a "Save" button with one design and six real states

A designer hands off a single polished "Save" button. In production, that button needs: default, hover, focus (a visible keyboard focus ring — not optional, and not automatically the same as the hover style), active/pressed, disabled (while a required field is empty), loading (a spinner replacing the label while the save request is in flight), and error (if the save fails, does the button revert, or does it show something inline?). A developer who receives only the default-state mockup has to invent the other six under time pressure, and "invent under time pressure" is exactly how a product ends up with a disabled button style that's indistinguishable from its default one.

What people usually miss

Watch out

• Focus state is not the same as hover state, and treating them as interchangeable breaks keyboard accessibility. A component with only a hover style, applied to :focus as a shortcut, often produces a focus indicator that's invisible or wrong for keyboard-only and screen-reader users who never trigger :hover at all.
• "The developer will figure it out" is not a plan — it's an unstated design decision, made by whoever implements it fastest, not by the person who should be making it. Every un-designed state gets decided by someone, just not necessarily the right someone.
• A component inventory prevents accidental duplication, not just naming confusion. Without one, "new card-like thing" and "existing Card component styled slightly differently" are indistinguishable to a developer working from a screenshot, and duplication compounds every time it happens.
• Handoff is a process, not a one-time file drop. Real specs go stale as a flow evolves during implementation — a handoff that isn't revisited when edge cases surface during development just produces a second, silent divergence between what was designed and what shipped.

Why this matters in interviews

"How do you keep a component from diverging between what was designed and what got built?" is testing whether a candidate treats handoff as a real deliverable with content requirements (interaction states, specs, inventory) or as an informal file-sharing step — naming the specific gaps (missing disabled/loading/error states, no documented spacing values, no component inventory) is what shows real cross-functional collaboration experience.