How to Hand Off Designs to Developers

Design handoff breaks down in predictable ways: missing states, ambiguous spacing, components that look simple but have unstated complexity. A solid handoff process prevents the back-and-forth that slows every team down.

What developers actually need

Developers don't need a beautiful Figma file. They need:

• Exact dimensions and spacing values
• Color values (hex, HSL, or mapped to tokens)
• Typography specs (font, weight, size, line height, letter spacing)
• All component states (default, hover, focus, active, disabled, error, loading)
• Interaction behavior (what happens on click, on hover, on keyboard)
• Edge cases (empty states, long text, missing images)
• Responsive behavior (how the layout changes at each breakpoint)

Most handoff failures are missing one of these — usually states and edge cases.

Figma Dev Mode

Figma Dev Mode (Cmd+Shift+D to toggle, or the </> button in the top bar) gives developers a dedicated inspection interface.

In Dev Mode, clicking any element shows its:

• Dimensions and position
• Colors (and if you've used variables, the variable names)
• Typography styles
• Auto Layout values (gap, padding)
• Computed CSS, iOS SwiftUI, or Android Jetpack Compose code snippets

Set up Dev Mode for your file properly:

Use variables and styles. Dev Mode shows variable names, not just hex values. If a developer sees color/interactive/primary, they know to use the design token — not hardcode the hex. This is especially valuable in codebases that use Tailwind or CSS custom properties.

Name your layers. A layer named icon/chevron-right is more useful than Vector 23. Developers use layer names as hints for component naming and asset export.

Use components. Components in Figma map to components in code. When a developer sees a Button/Primary/Default component in Dev Mode, they know which code component to reach for.

Naming layers and components

Consistent layer naming is underrated in handoff. Rules:

• Component names should match (or closely match) the code component names. If the code has <PrimaryButton>, your Figma component should be Buttons/Primary, not Blue button.
• Icon layers should be named after the icon: icon-search, icon-close. This makes export and referencing straightforward.
• Container frames should describe their content: header-nav, card-product, modal-confirmation.
• Avoid Figma defaults: Rectangle 47, Frame 12, Group 8. These mean nothing in handoff.

Specifying states and interactions

Design files show static screens. Developers need to know what changes between states.

The most reliable approach: design every state explicitly as a separate frame or component variant, then annotate which state corresponds to which trigger.

For complex interactions, add an annotation frame next to the design:

Button states:
- Default: blue fill, white text
- Hover: blue-700 fill (darken 10%)
- Focus: 2px ring, offset 2px, color brand-focus
- Disabled: gray-200 fill, gray-400 text, cursor not-allowed
- Loading: spinner icon replaces text, disabled behavior

This text takes five minutes to write and saves hours of questions.

For interactions with animation, specify:

• What triggers the animation (hover, click, focus)
• What changes (position, opacity, scale)
• Duration (e.g., 200ms)
• Easing (ease-in-out, ease-out, spring)

Showing design vs specifying behavior

Showing a design means "here's what it looks like." Specifying behavior means "here's how it works."

Both are required. Developers can implement the visual from Dev Mode. They cannot infer behavior that isn't specified anywhere.

Behavior to specify explicitly:

• What closes a modal (clicking outside? pressing Escape? only the close button?)
• What happens if a form is submitted with invalid data (which fields get error states, what's the error message, does submission attempt proceed?)
• What happens on empty state (first-time user, no results, no data)
• What triggers a loading state and when does it resolve

A separate spec document (even a Notion page or Figma annotation) for complex flows prevents these questions from arriving mid-sprint.

Try Figma Free

Dev Mode vs Zeplin

Figma Dev Mode is built in and works well for teams already in Figma. Zeplin is a dedicated handoff tool with additional features.

For most teams starting out, Dev Mode is sufficient. Zeplin makes sense if your team does detailed annotation work or has developers who prefer not to work in Figma directly.

Where Storybook fits in

Storybook is the developer's component library browser. If your team has Storybook running, developers can reference it alongside your Figma handoff.

Link between them. Add a figma.url parameter to your Storybook stories (the @storybook/addon-designs plugin) and add Storybook links in your Figma component descriptions. When Figma and Storybook are aligned, developers spend less time asking questions and more time building.

The real handoff win is a Figma component that maps 1:1 to a Storybook component. When that relationship exists, the developer already knows exactly what to reach for.