Figma Handoff That Developers Actually Use

A handoff fails quietly. The designer shares a link, the developer opens a file with 4,000 layers named "Frame 2041", and ten questions arrive in chat before lunch. Each question is small. Together they cost days and produce a build that is "close" to the design.

A good handoff is not a separate document. It is a Figma file organized so that the developer can answer their own questions. This post covers the five areas that matter most: file structure, naming, tokens, states, and specs, followed by a checklist.

Start with the file structure

Developers open a file looking for one thing: what do I build, and in what order? Make that answer visible before they scroll.

• A cover page. Project name, status, a link to the brief, and the date of last update.
• A "Ready for dev" page. Only frames that are final live here. Work in progress stays on a separate page called "Drafts" or "Exploration". Figma also offers a "Ready for dev" status you can mark on sections; use it so nobody builds a screen that is still changing.
• Flow order. Arrange screens left to right in the order the user sees them, with arrows or numbered labels. A developer should not have to guess whether the payment screen comes before the review screen.
• One source for components. Keep components on their own page or in a shared library, and have screens use instances of them.

Name things so code can match

Names are the cheapest handoff tool. If the layer name matches the component name in the codebase, the conversation shortens.

Frames and screens: use plain, ordered names: 01 Sign up, 02 Verify email, 03 Dashboard / empty. The slash is useful: Figma groups names with slashes into a tree.

Components: use a consistent pattern, Category / Name / Variant. For example Button / Primary / Large, Input / Text / Error. Ask your developers what their component names are, and use the same words.

Layers inside components: rename the ones that matter. Label, Icon left, Helper text tell a developer what is a slot and what is fixed. Delete the layers called Rectangle 12 and Group 4 that do nothing.

A practical rule: if a layer would become a prop, a class or a slot in code, give it a name a developer would type.

Use tokens, not raw values

When a developer sees #2F6FED in a fill, they have to decide whether it is the brand blue, a one-off, or a mistake. A token removes the question.

Figma variables let you store colors, numbers, strings and booleans, and apply them to fills, spacing, corner radius and more. Use them in two layers:

1. Primitive values: the raw palette and scale, such as blue-500 or space-16.
2. Semantic tokens: names that describe the job, such as color-action-primary, color-text-muted, space-card-padding. These point to primitives.

Developers want the semantic layer, because it maps cleanly onto CSS custom properties or a theme file:

:root {
  --color-action-primary: var(--blue-500);
  --color-text-muted: var(--gray-600);
  --space-card-padding: 16px;
}

Agree on the naming with the developers before you create tokens, so that Figma and code use one vocabulary. If a theme matters (light and dark, or several brands), use variable modes so that one component serves both.

Do the same for type: text styles such as heading-lg and body-md, each holding size, line height and weight.

The test: select any element and check the right panel. If fill, text and spacing all show token names, you are done. If they show raw hex codes, the element is not ready.

Design the states, not just the default

The most common source of "can you check the design for this?" messages is a missing state. Developers will ask about what they cannot see, or invent their own behavior.

For each interactive component, show:

• Default, hover, focus, pressed, disabled
• Loading (a spinner on a button, a skeleton on a list)
• Error and success (with the actual message copy)
• Empty (a new account with no data)

For each screen, add the variants that change layout:

• Long text (a name with 50 characters, a title that wraps to three lines)
• Many items and no items
• Failed to load, and offline if it applies

Build these with Figma component variants and properties, so one component holds all states. Label the variants with the same words the code will use (state=hover, size=lg), since variant names often become prop names directly.

Focus states are the one most often forgotten, and they matter for keyboard users. Design a visible focus ring, and show it.

Specs developers use, and specs they ignore

Developers can already read pixel values from Figma's Dev Mode (inspect panel). Spend your effort on what the inspector cannot say.

Useful annotations:

• Behavior: "Table header is sticky. Columns below 768px collapse into cards."
• Responsive rules: which breakpoints you designed, and what the layout does between them. Use auto layout with constraints so resizing a frame shows the intent. Better still, show the layout at the real breakpoints.
• Interaction and motion: what triggers it, duration and easing, and what happens on reduced-motion settings.
• Content rules: character limits, truncation, how dates and currencies are formatted.
• Data: what the real fields are called, which are optional, what the API might return when empty.
• Accessibility: heading order, labels for icon-only buttons, the reading order if it differs from the visual one.

Less useful: redlines on every margin. If you use auto layout and spacing tokens, the inspector already holds those values. Annotate only the exceptions: "This gap is 24px on purpose, not 16px."

Export icons as SVG and tell developers which images are placeholders.

Run a short walkthrough

A file with no explanation still leaves gaps. Spend 30 minutes with the developer, ideally before the build begins:

1. Walk the flow in order.
2. Point out the tricky states and the annotations.
3. Ask them what is unclear or what looks expensive to build.
4. Agree on what can be simplified.

The last point matters. A developer who sees the file early will often propose a cheaper implementation that keeps the intent. That conversation is cheaper before the build than during review.

A handoff checklist

Before you mark a section "Ready for dev", check:

• [ ] Cover page has the brief link and last-updated date
• [ ] Screens ordered by flow, final frames separated from drafts
• [ ] Layer and component names match code vocabulary
• [ ] No unnamed groups or leftover hidden layers
• [ ] Colors, text and spacing use tokens or styles
• [ ] Components use auto layout and variants
• [ ] All interactive states designed, including focus and disabled
• [ ] Empty, loading, error and long-content cases shown
• [ ] Breakpoints designed, with behavior between them described
• [ ] Motion, content rules and accessibility notes added
• [ ] Icons and images ready for export
• [ ] Walkthrough done and open questions logged

FAQ

Do I need a full design system before handing off?

No. Even a small set of color and text tokens and a handful of components removes most ambiguity. Start there and grow it.

What if the developers do not use Dev Mode?

Share the same information in whatever they do use: a written spec, a shared token file, or a short recorded walkthrough. The principle stays the same: answer their questions before they ask.

Talk to us

If you want design and development to work from one file with fewer questions in between, the Rising Station team can help set up the workflow or build the product with you. Email hello@risingstation.com or visit risingstation.com/contact-us.