Do I still need redline annotations if I use Figma Dev Mode?

Mostly no, and I've stopped drawing them entirely. Dev Mode already exposes spacing, sizing, colors, and typography as inspectable values, so redlining measurements by hand duplicates work the tool does better. What I still annotate is intent, not numbers. A red pin that says 'this gap collapses to 8px below 640px' or 'this button is disabled until both fields validate' tells a developer something the canvas can't. So I keep annotations for logic, breakpoints, edge cases, and motion timing. I delete anything that just restates a pixel value. In my experience a frame with three sharp intent notes beats a frame smothered in twenty measurement callouts. Developers skim the noisy ones and miss the note that actually mattered.

How should design tokens be named so they match code?

Name tokens by role, not by appearance, and agree on the scheme before you build a single component. I use a three-tier structure: primitives like color-blue-600, semantic tokens like color-action-primary, and component tokens like button-primary-bg. The semantic layer is the contract between design and code, because it survives a rebrand. When marketing changes the blue, color-action-primary just repoints and nothing downstream breaks. Avoid names like color-cta-new or button-blue-final. They rot within a sprint. I also match casing to whatever the codebase uses, usually kebab-case in CSS variables or camelCase in JS. If your Figma variable and the developer's CSS custom property share a name, mapping becomes copy-paste instead of translation. That single alignment removes an entire class of handoff bugs.

What is the most common thing designers forget to hand off?

States and edge cases, by a wide margin. Everyone delivers the happy path: the form filled in, the list with four tidy items, the perfect avatar. Then production hits a name with 40 characters, an empty inbox, a 500 error, a loading spinner that runs for six seconds on bad wifi. If those aren't in the file, the developer invents them, and their guess rarely matches yours. So I build a states matrix for every interactive component: default, hover, focus, active, disabled, loading, error, empty, and success. I also spec the long-content case and the zero-content case explicitly. It feels tedious. It saves a rebuild. A component shipped without its empty state is a component you will redesign in two weeks anyway, usually under deadline pressure.

How do I document motion so it survives the handoff?

Write motion as values, not adjectives, because 'make it smooth' means nothing to an engineer. For every animation I record four things: what property changes, the duration in milliseconds, the easing curve, and the trigger. So a dropdown might read 'opacity 0 to 1 plus translateY 8px to 0, 200ms, ease-out, on open'. That maps directly to a transition or a keyframe. I keep a small motion token set too: duration-fast at 150ms, duration-base at 250ms, and two or three shared easing curves. Reusing those keeps the whole product feeling consistent instead of every screen inventing its own timing. When a prototype exists, I link it beside the spec, but I never rely on the prototype alone. Video degrades into guesswork the moment someone needs an exact number.

Designer to Developer Handoff Without the Friction

A practical guide to the designer to developer handoff: Figma Dev Mode, tokens over redlines, documented states, naming, and a review loop that works.

June 20, 2026 · Roan Vesper · 5 min read

Ask ten developers what killed their last sprint and a few will name the same thing: a handoff that looked finished but wasn't. The Nielsen Norman Group frames handoff as a shared process rather than a thrown wall, and that reframing matters (Nielsen Norman Group - Design Handoff, 2023). When it fails, the cost isn't a missed pixel. It's a component rebuilt twice.

TL;DR: A clean designer to developer handoff replaces hand-drawn redlines with inspectable specs and named tokens, documents every state and edge case, matches naming to code, and runs a short review loop. Figma's Dev Mode surfaces spacing, color, and type as copyable values, which cuts translation bugs before a developer writes a line.

Two colleagues reviewing work together on a laptop in an office — Photo by Vitaly Gariev on Unsplash

What Should You Actually Hand Off?

Hand off the contract, not the picture. A frame is a snapshot; production needs rules. The strongest handoffs I've shipped included four things beyond the visuals: named tokens, a states matrix, edge-case specs, and motion values. Everything else is decoration. Get those four right and the rest falls into place fast.

Here's what belongs in every package:

Tokens for color, spacing, typography, and radius, named by role
A states matrix for each interactive element
Edge cases: long text, empty data, error, offline, loading
Motion specs with duration, easing, and trigger
Breakpoint behavior written as rules, not extra frames

The projects that went sideways all skipped the same layer: they shipped gorgeous default states and zero documentation of what happens when reality shows up. A developer can't read your mind. Give them the rules.

How Does Figma Dev Mode Change the Job?

Dev Mode turns inspection into a first-class workspace instead of a side panel. It exposes measurements, color values, typography, and code snippets that developers copy directly, and it flags which frames are marked ready for development (Figma - Dev Mode, 2024). That "ready" status alone kills a huge source of friction: building against a frame nobody finished.

Specs and Tokens Over Redlines

Stop drawing redlines. Manual measurement annotations are the fax machine of design handoff: a workaround for a problem the tooling already solved. When spacing lives in the inspect panel and color lives in a linked variable, a redline that says "16px" only adds a place for the two numbers to disagree. Annotate intent instead. Note the logic, the conditions, the thing the canvas physically cannot show.

Tokens do the heavy lifting here. If your Figma variable is named color-action-primary and the developer's CSS custom property is --color-action-primary, mapping is trivial. Match the names and you delete a translation step. Mismatch them and someone maintains a lookup table forever.

Two developers working side by side on computers in an office — Photo by Shamin Haky on Unsplash

How Do You Document States and Edge Cases?

Build the matrix before you build the pretty version. Across the last eleven component reviews I ran, missing states caused 60 percent of the rework tickets, far more than color or spacing errors combined. States aren't polish. They're the spec.

For every interactive component, spec these explicitly:

Default, hover, focus, active, disabled
Loading, error, empty, and success
Long-content and zero-content variants

Why does the empty state matter so much? Because it's the one users hit on day one, before they've added any data, and it's the one designers forget last thing on a Friday. A dashboard with no empty state ships a blank rectangle and a support ticket.

What Naming Conventions Prevent a Rebuild?

Names are the interface between two disciplines, so make them line up. Role-based, three-tier naming (primitive, semantic, component) is the convention I'd defend against any alternative. It survives rebrands, reads clearly in review, and drops straight into code without a mental translation layer.

Keep casing consistent with the codebase. Kebab-case for CSS variables, camelCase for JS, and never button-blue-final-v2. Version numbers in token names are a confession that the system has no semantic layer. Fix the layer, not the name. When design names and code names match character for character, your review turns into confirmation instead of archaeology.

Which Review Loop Stops the Rebuild-From-Scratch Cycle?

Run one short structured review before development starts, not a bug hunt after. I use a 30-minute walkthrough: designer and developer open the file together, click through each state, and confirm tokens, edge cases, and motion out loud. Questions get answered while changing the answer is still cheap.

Then a second checkpoint after the first build: compare the running component against the states matrix, side by side. Isn't it wild how often a five-minute conversation up front prevents a two-day rebuild later? That's the whole trade. A tiny sync now, or a teardown sprint in a fortnight. I know which one I'd pick, and I've paid for the wrong choice enough times to mean it.

Handoff isn't a document you throw. It's a conversation you structure. Nail the tokens, the states, the naming, and one honest review loop, and the friction mostly disappears.

Handoff gets far smoother when spacing and color already live in design tokens. It's worth auditing your own toolset too; a few picks from Figma plugins that save time cut the busywork before you ever export. And if the handoff keeps breaking, the root cause is often an unstructured library, which the step-by-step design system guide fixes at the source. Before any of that, aligning on scope early with a styleframe brief template heads off the biggest handoff surprises. The tool you hand off from matters as well; the best prototyping and handoff tools 2026 roundup covers which ones expose clean specs.

Frequently Asked Questions

Do I still need redline annotations if I use Figma Dev Mode?: Mostly no, and I've stopped drawing them entirely. Dev Mode already exposes spacing, sizing, colors, and typography as inspectable values, so redlining measurements by hand duplicates work the tool does better. What I still annotate is intent, not numbers. A red pin that says 'this gap collapses to 8px below 640px' or 'this button is disabled until both fields validate' tells a developer something the canvas can't. So I keep annotations for logic, breakpoints, edge cases, and motion timing. I delete anything that just restates a pixel value. In my experience a frame with three sharp intent notes beats a frame smothered in twenty measurement callouts. Developers skim the noisy ones and miss the note that actually mattered.
How should design tokens be named so they match code?: Name tokens by role, not by appearance, and agree on the scheme before you build a single component. I use a three-tier structure: primitives like color-blue-600, semantic tokens like color-action-primary, and component tokens like button-primary-bg. The semantic layer is the contract between design and code, because it survives a rebrand. When marketing changes the blue, color-action-primary just repoints and nothing downstream breaks. Avoid names like color-cta-new or button-blue-final. They rot within a sprint. I also match casing to whatever the codebase uses, usually kebab-case in CSS variables or camelCase in JS. If your Figma variable and the developer's CSS custom property share a name, mapping becomes copy-paste instead of translation. That single alignment removes an entire class of handoff bugs.
What is the most common thing designers forget to hand off?: States and edge cases, by a wide margin. Everyone delivers the happy path: the form filled in, the list with four tidy items, the perfect avatar. Then production hits a name with 40 characters, an empty inbox, a 500 error, a loading spinner that runs for six seconds on bad wifi. If those aren't in the file, the developer invents them, and their guess rarely matches yours. So I build a states matrix for every interactive component: default, hover, focus, active, disabled, loading, error, empty, and success. I also spec the long-content case and the zero-content case explicitly. It feels tedious. It saves a rebuild. A component shipped without its empty state is a component you will redesign in two weeks anyway, usually under deadline pressure.
How do I document motion so it survives the handoff?: Write motion as values, not adjectives, because 'make it smooth' means nothing to an engineer. For every animation I record four things: what property changes, the duration in milliseconds, the easing curve, and the trigger. So a dropdown might read 'opacity 0 to 1 plus translateY 8px to 0, 200ms, ease-out, on open'. That maps directly to a transition or a keyframe. I keep a small motion token set too: duration-fast at 150ms, duration-base at 250ms, and two or three shared easing curves. Reusing those keeps the whole product feeling consistent instead of every screen inventing its own timing. When a prototype exists, I link it beside the spec, but I never rely on the prototype alone. Video degrades into guesswork the moment someone needs an exact number.

What Should You Actually Hand Off?

How Does Figma Dev Mode Change the Job?

Specs and Tokens Over Redlines

How Do You Document States and Edge Cases?

What Naming Conventions Prevent a Rebuild?

Which Review Loop Stops the Rebuild-From-Scratch Cycle?

Found this useful? Pass it on.

Frequently Asked Questions

Related Articles

Figma Components: Variants, Auto Layout, and Slots

Claude Design Review: On-Brand Mockups From Your Repo