# Design Handoff: Figma to Development

> The process of communicating design decisions to developers—clear handoffs prevent misinterpretation and rework.

*Tags: ux, processes, junior*

---



> [!info] Quick Definition
> The process of communicating design decisions to developers—clear handoffs prevent misinterpretation and rework.


## What is Design Handoff?

Design handoff is the moment designs move from Figma to code. Without clear handoff, developers interpret designs in their own way. Blue becomes a different shade. Padding is guessed. Animations are simplified.

A good handoff answers: What is this component? How does it behave? What are the states? What's the spacing? A bad handoff is mockups alone with no documentation.

**One sentence punch:** A good handoff answers every question a developer has before they ask it.**

## Why Handoff Matters

- **Prevents Rework** — When developers misinterpret, they build the wrong thing. Rework is expensive. Clear handoff prevents it.
- **Ensures Consistency** — When specifications are clear, every instance of a component looks the same.
- **Reduces Questions** — Developers don't come back asking "what color is this?" Specs have answered it.
- **Speeds Development** — No back-and-forth. No clarifications needed. Development flows fast.

## Handoff Process

1. **Prepare Figma File** — Organize components. Use consistent naming. Clean up unused elements.
2. **Create Specifications** — Document spacing, colors, typography, states, interactions.
3. **Add Annotations** — In Figma, add notes explaining non-obvious decisions.
4. **Create Handoff Document** — A single reference for all specs (Notion page, PDF, or living document).
5. **Review with Developers** — Walk through specs. Answer questions. Get buy-in.
6. **Share Access** — Developers can access Figma. Use Inspect mode for measurements.
7. **Maintain Alignment** — If specs change, update them. Keep document current.

## Figma Features for Handoff

- **Inspect Mode** — Developers click on elements and see measurements, properties, and code.
- **Components Library** — Organized component library developers reference for consistency.
- **Annotations** — Add notes on artboards explaining decisions.
- **Design Tokens** — Export colors and typography as tokens developers can import.
- **Comments** — Async feedback on designs. Developers can ask clarifying questions.

## What to Document

1. **Component Purpose** — When and why is this component used?
2. **Visual Specs** — Dimensions, padding, margins, colors, typography.
3. **States** — Default, hover, active, disabled, loading. Every state must be documented.
4. **Interactions** — Click behavior, animations, transitions. Timing and easing details.
5. **Responsive Behavior** — How does this component adapt on mobile/tablet/desktop?
6. **Edge Cases** — Very long text, special characters, empty states.
7. **Accessibility** — Focus states, contrast requirements, ARIA labels if applicable.

## Documentation Template

```
Component: [Name]

Purpose: [What is this? When is it used?]

Visual Specs:
- Width: [px]
- Height: [px]
- Padding: [px]
- Border Radius: [px]
- Background: [color hex]
- Text: [font, size, weight, color]

States:
1. Default: [visual description]
2. Hover: [visual description]
3. Active: [visual description]
4. Disabled: [visual description]

Responsive:
- Mobile: [changes]
- Tablet: [changes]
- Desktop: [no changes, same as default]

Accessibility:
- Min touch target: 44px
- Contrast ratio: [WCAG level]
```

## Mentor Tips

- **First tip: Handoff is a conversation, not a document.** A perfect spec that developers don't understand is useless. Walk through key components. Be available for questions.
- **Test developers' interpretation.** After handoff, review first implementation. Are they building what you designed? If not, specs were unclear.
- **Give developers autonomy.** Specs are a guide, not a prison. If developers have a better implementation that matches specs, let them do it.
- **Version your specs.** When specs change post-launch, version it. Developers need to know what spec their code matches.

## Resources and Tools

- **Books:** "Frontend Architecture for Design Systems" by Micah Godbolt
- **Tools:** [[Figma]] with Inspect mode, Zeroheight or Specify for auto-generated specs, [[Notion]] for documentation
- **Articles:** Design handoff best practices on Nielsen Norman, handoff on [[UX Collective]]

---

Source: https://www.fernandoux.com/en/wiki/processes/design-handoff/