The handoff problem is structural, not personal

When design-to-dev handoff fails, the blame usually lands on individuals: the designer did not spec it properly, the engineer did not ask enough questions. After working across 30+ product teams, we have observed that the problem is almost always structural. The process itself creates the gaps.

The traditional handoff looks like this:

  1. Designer finishes screens in Figma
  2. Designer marks the file "ready for dev"
  3. Engineer opens Figma, builds what they see
  4. Designer reviews implementation, finds 30 things wrong
  5. Engineer makes corrections, designer reviews again
  6. Ship, eventually

This cycle takes 2-3x longer than it needs to.

The core problem: Figma shows states, not behaviour

A Figma file is a collection of static frames. It shows what a screen looks like in one state. It does not show you:

  • What happens during the loading state
  • What the error state looks like
  • How the component behaves when text is 2x longer than the design example
  • What the empty state is
  • How transitions between states work
  • Edge cases the designer has not encountered yet

Engineers build code that handles all states. Designers often spec the happy path. That gap is the handoff problem.

What we changed

1. Move the handoff earlier — to the design review, not the file handoff

Engineers review designs before they are finalised, not after. We schedule a 45-minute design review for every significant feature with at least one engineer present.

In that review, engineers ask:

  • What is the loading state?
  • What happens if the list is empty?
  • What is the error state if the API fails?
  • What if the user's name is 40 characters?
  • How does this work on 375px wide screen?

Designers answer or add the missing states before handoff. Rework drops immediately.

2. A structured handoff doc

For every feature, the designer fills out a one-page handoff doc before tagging it ready:

## Feature: [Name]
Figma link: [link to the specific frame]
API endpoint: [link or description]

States covered:
- [ ] Default / loaded
- [ ] Loading skeleton
- [ ] Empty state
- [ ] Error state
- [ ] Hover/focus states
- [ ] Mobile (< 768px)

Animations & transitions: [description or prototype link]
Design tokens used: [list non-standard tokens]
Open questions: [anything not yet decided — do not mark ready if non-empty]

It takes 20 minutes to fill out. It saves 4-6 hours of back-and-forth.

3. Engineers own the implementation spec

After the design review, the engineer who will build the feature writes a short note:

  • Which existing components will be used
  • Which new components need to be built
  • Any API shape assumptions
  • Estimated complexity

The designer reviews and signs off. It catches misalignments before a single line of code is written.

4. Design tokens in code

Your Figma design tokens should map 1:1 to CSS variables in your codebase:

/* Figma: Colour/Brand/Primary */
--color-brand-primary: #E0A458;

/* Figma: Spacing/4 */
--spacing-4: 16px;

When an engineer picks the wrong blue because there are 12 slightly different blues in Figma with no token structure, that is a token governance problem. When every colour has a token name and every token is in the codebase, there is nothing to pick wrong.

The metrics that improved

Across teams where we have implemented this system:

  • Design QA cycles per feature: from 3.2 average to 1.4
  • Engineer time on corrections after design review: down 65%
  • Designer satisfaction (team survey): +40 NPS points over 6 months

The last metric surprised us. Designers like the new process more than the old one. Fewer late-night Slack messages asking "did you see my Figma comment?" and fewer surprises at implementation review.

Start here

If you are going to change one thing: put an engineer in the design review before the file is marked ready. That single change eliminates more rework than everything else combined.