What is the design-to-dev handoff?

The design-to-dev handoff is the process of transferring design specifications from designers to developers for implementation. It includes sharing Figma frames, component specs, interaction documentation, and acceptance criteria so developers can build interfaces that match the approved design.

Why do designs never match the build after handoff?

Designs drift from builds because designers think in visual intent while developers think in DOM structure. Common causes include vague Figma links (file-level instead of frame-level), unnamed layers, missing interaction state documentation, undefined acceptance criteria, and no formal design QA step in the sprint.

How can I improve the design-to-dev handoff process?

Link to specific Figma frames (not files), name layers like component trees, annotate invisible states (hover, focus, error, loading), define design fidelity acceptance criteria before work begins, compare designs against live builds instead of eyeballing, file issues with actual CSS values, and add a design QA pass to your sprint workflow.

Blog Post

7 Ways to Improve Your Design-to-Dev Handoff (That Actually Work)

The design-to-dev handoff is a communication protocol between two people who think about interfaces in completely different ways. Designers think in visual intent. Developers think in DOM structure. Every handoff is a translation, and most teams lose meaning in translation. Here are seven things that actually move the needle.

1. Link to Frames, Not Files

Stop sending Figma file links. Link to the specific frame using Cmd+L (Ctrl+L on Windows). The developer should land exactly where they need to be. This takes three seconds and saves 15 minutes of back-and-forth per ticket.

2. Name Your Layers Like a Developer Will Read Them

Name layers the way a component tree reads: card/header/title, nav/mobile/menu-open. Developers inspect your layers to map Figma to code. Auto-generated names like Frame 247 > Group 12 prevent building a mental model of the component structure.

3. Annotate the Invisible States

Document hover states, focus states, loading states, error states, empty states, disabled states, and responsive behavior. If it is not in the mockup, it will not be in the build. Create a separate States and Interactions frame for everything a static mockup cannot show.

4. Define Done Before Handoff, Not During QA

Write acceptance criteria for design fidelity before the work starts. Is 2px off acceptable? Which breakpoints are required? Are animations in scope? Define what matching the design means before implementation, not during QA review.

5. Compare Designs Against Builds Instead of Eyeballing

Eyeballing between Figma and staging tabs misses subtle drift: 4px spacing discrepancies, wrong border radius, font weight 400 instead of 500. OverlayQA lets you compare the Figma design directly against the live build in one click.

6. File Issues with Values, Not Vibes

Include computed CSS values, expected values from the Figma spec, and annotated screenshots in every design issue. An issue with values gets fixed in one pass. An issue with This looks off costs 30 minutes of back-and-forth.

7. Build a Design QA Pass Into the Sprint

Add a Design QA step between Dev Complete and Ready to Ship. The designer reviews the build against the spec before it moves forward. This is not extra work. It is the work teams already do, just three weeks later when it costs 5x more.