How to Use Figma for Design-to-Dev Handoff

Most design-to-dev handoff problems aren't really about the design being wrong, they're about the developer not having a reliable way to know what the design actually specifies. A screenshot with a comment thread full of "can you check the spacing on this" is a sign the handoff process, not the design itself, is broken. Figma's Dev Mode was built specifically to close that gap: it gives developers a dedicated view of a file where measurements, styles, and even code snippets are generated directly from the real design, rather than reconstructed by eye from a flat image.

For background on Figma's pricing tiers and how it compares to other design tools, see our full Figma profile. This guide walks through actually using the handoff workflow once you're in a file: inspecting specs, pulling out design tokens and variables, generating code snippets, annotating anything code can't capture, keeping the component library in sync, and tracking which screens are genuinely ready to build.

Step 1: Turn On Dev Mode and Orient Developers to It, Not to the Design View

Dev Mode is a distinct view within a Figma file, toggled from the toolbar, and it's worth treating as the primary place developers work rather than something they stumble into. In the standard design view, Figma is optimized for the person building the interface; in Dev Mode, the same file is optimized for the person reading it for implementation details. Selecting any layer in Dev Mode surfaces a dedicated inspect panel with sizing, spacing, and style information, without the clutter of editing tools a developer doesn't need. Getting developers into the habit of opening Dev Mode first, rather than the regular design canvas, is a small process change that removes a surprising amount of "where do I find this" friction on its own.

Step 2: Inspect Specs Directly Instead of Asking the Designer

With a layer selected in Dev Mode, the inspect panel shows exact pixel dimensions, padding and margin values, corner radii, stroke weights, and layout properties like auto-layout direction and spacing, all read directly from the actual design rather than estimated. This is the core value of the entire workflow: a developer who needs to know whether a gap between two elements is 16px or 24px can read it straight from the panel instead of opening a ruler tool on a flattened screenshot or pinging the designer to ask. The habit worth building on the design side is simple: use real auto-layout and consistent spacing values when building the file, since Dev Mode's inspect panel is only as useful as the structure underneath it. A file built with manually nudged pixels and inconsistent spacing produces a messier, less trustworthy spec than one built with disciplined auto-layout.

Step 3: Extract Design Tokens Through Variables, Don't Hardcode Values

Figma's Variables feature is what makes Dev Mode's specs map cleanly onto a real design token system rather than just reporting raw pixel numbers. When colors, spacing values, and typography are defined as Variables rather than hardcoded on individual layers, Dev Mode's inspect panel shows the token name alongside the raw value, for example a color swatch labeled "color/brand/primary" instead of just a hex code. That token name is what a developer actually wants, since it maps directly onto a corresponding variable in code (a CSS custom property, a Tailwind config value, a design-token JSON file) rather than requiring someone to manually match a raw hex value back to the right named token by inspection. If your team hasn't moved to Variables yet, this is the single highest-leverage step in this whole workflow: a file full of hardcoded values turns Dev Mode into a slightly better ruler, while a file built on Variables turns it into an actual bridge between design tokens and code.

Step 4: Generate Code Snippets for the Parts That Translate Directly

For a selected layer, Dev Mode can generate ready-to-use code snippets, covering CSS, iOS (Swift), and Android (Kotlin/Compose) depending on the target platform, pulling spacing, color, typography, and effect values straight from the design. This is genuinely useful for the kind of implementation detail that's tedious to transcribe by hand and easy to get subtly wrong, box-shadow values, exact border-radius and padding combinations, font-weight and line-height pairings, especially across a long component-heavy screen. It is not a substitute for real engineering judgment: generated CSS for a single element doesn't understand your actual component architecture, responsive breakpoints, or state logic, and treating it as a first draft to adapt, rather than code to paste in unmodified, is the right expectation to set with developers up front.

Step 5: Annotate Anything the Spec Can't Capture On Its Own

Specs and generated code snippets handle layout and styling well, but they say nothing about interaction behavior, edge cases, or intent, what happens on a long text overflow, what the empty state looks like, which field is actually required. Figma supports adding comments and annotations directly on specific elements in the file, and building a habit of annotating these non-obvious behaviors at the point they occur, rather than documenting them separately in a PRD a developer may not have open while building, keeps the one source of truth developers are already looking at actually complete. A good test for whether a screen is handoff-ready: if a developer would reasonably need to ask a clarifying question about behavior that isn't visible in the static layout, that answer belongs in an annotation on the file, not in a separate document or a Slack message that will be hard to find again later.

Step 6: Keep Dev Mode Synced With Your Actual Component Library

Dev Mode's usefulness depends heavily on whether the components in a given file are genuinely linked to your team's published component library rather than detached, one-off copies that have drifted from the real system. When a component instance is properly linked to a published library component, Dev Mode can surface the corresponding code component name and props (for example, mapping a Button instance to a React component and its relevant prop values), which is what actually closes the loop between a design system and the codebase that implements it. A file full of disconnected, manually duplicated components looks identical to a developer glancing at the canvas, but behaves completely differently in Dev Mode, since there's no real mapping back to a reusable code component. Auditing for detached instances before a round of handoff, and relinking or rebuilding them against the published library, is worth doing as a deliberate step rather than assuming every instance is still properly connected.

Step 7: Track Handoff Status Explicitly, Don't Rely on Memory

On any project with more than a handful of screens, some kind of explicit status tracking for what's actually ready to build, versus still in review, versus already implemented, prevents the common failure mode where a developer starts building from a screen that was still mid-revision, or a designer keeps revising a screen a developer already shipped against. Figma supports status tracking directly on frames in Dev Mode, and pairing that with a simple, consistently applied status convention (ready for dev, in progress, blocked, built) gives both sides a shared, visible answer to "is this actually done" instead of relying on someone remembering the state of a screen from a meeting three days ago. The specific labels matter less than the discipline of actually updating them at each handoff point, a status system nobody keeps current is no better than no status system at all.

Where This Workflow Breaks Down, and How to Avoid It

The most common way teams undermine this entire setup is skipping Step 3: building the actual design file with hardcoded hex values and arbitrary pixel spacing instead of Variables and consistent auto-layout. Every other step in this workflow, inspection, token mapping, code generation, depends on that underlying structure being disciplined, and no amount of careful annotation in Step 5 fully compensates for a file that wasn't built with tokens and real auto-layout in the first place. The second most common failure is treating Dev Mode as a one-time export rather than an ongoing reference, a team that generates specs once early in a project and then keeps iterating the design without updating the file developers are actually looking at recreates the exact "which version is current" confusion this workflow is meant to eliminate.

Used deliberately, starting with a well-structured file built on Variables, inspecting real specs instead of guessing from screenshots, generating snippets as a starting point rather than a finished answer, annotating what code can't capture, keeping components linked to the real library, and tracking status honestly, Dev Mode turns handoff from a recurring source of back-and-forth into something closer to a shared, trustworthy reference both sides can work from directly.

If you're deciding whether Figma's broader feature set and pricing actually make sense for your team in the first place, our Figma vs Sketch comparison covers how the two tools differ on collaboration and handoff more generally.