Dev Mode and handoff — designs engineers can build

Choose your track

Read this module through your lens

Handoff is a deliverable

There is a moment every design reaches where it stops being yours and becomes someone else’s to build. How well that goes is not a footnote — it determines whether the product that ships matches the product you designed. And here is the counterintuitive part: a slightly rough file an engineer can read cleanly is worth more than a pixel-perfect file they cannot, because the rough one builds correctly and the perfect one builds wrong.

So handoff deserves to be treated as its own deliverable, not an afterthought you rush at the end. Figma’s Dev Mode is the tool engineers use to read a design — measurements, values, code snippets, exportable assets. But Dev Mode is only a reader. It can show structure; it cannot invent it. Almost all of handoff quality was decided upstream, in how you built the file.

The quality was decided upstream

Everything you have learned in this course is, in retrospect, also handoff preparation. Named layers mean Dev Mode shows an engineer “Primary button / Label” instead of “Frame 12 / Rectangle 4” — intent versus pixels. Components mean a repeated element is recognizably one thing with defined variants, so it gets built once as a reusable piece. Auto layout means the spacing is real padding and gaps, which Dev Mode reports as exact values, instead of hand-nudged positions an engineer must measure by hand. Variables and tokens mean colors and spacing arrive as named tokens — “color/primary”, “space/16” — that map straight to the codebase, instead of raw hex the engineer has to reverse-engineer into the system.

In other words, a file built well by the standards of the earlier modules is already most of the way to a great handoff. A file built as loose, unnamed, hard-coded rectangles cannot be rescued by Dev Mode, because there is no structure for Dev Mode to surface. You cannot inspect intent that was never expressed.

What Dev Mode adds, and what you still owe

With a clean file, Dev Mode does the rest of the read-side work. An engineer selects an element and sees its exact dimensions, spacing, and the distances between things; they copy color and type values, see your variables as token names, grab CSS or platform snippets, and export icons and images at the right scales. Frame statuses (marking a frame Ready for dev) tell them what is safe to build versus still in flux — skipping this is how engineers waste days building a screen you are still changing.

But two things Dev Mode cannot read, and you must supply. Behavior: what happens on hover, on error, when the list is empty, when the text is too long. These states and edge cases live in your head unless you annotate them, and undocumented behavior gets rebuilt wrong. And the flow: hand off the prototype alongside the specs, because the static frames do not show how screens connect or how transitions feel.

So a complete handoff is: a well-structured file, statuses set, behavior annotated, and the prototype shared next to the specs. That is a design an engineer can build into the product you actually designed.

Hands-on exercise

Take a component or screen and prepare it for real handoff. Upstream: confirm layers are named, it uses components and auto layout, and its colors/spacing come from tokens. Mark the frame Ready for dev, and add at least one annotation for a non-obvious state (hover, error, or empty). Then open Dev Mode and walk it as an engineer would — inspect spacing, copy a token, export an asset. Finally, note one thing Dev Mode surfaced because of your upstream work that it could not have shown on a loose, unnamed version.

Second case · a card component handoff

The same lesson, a different object

Common failures · spot them fast

The failure gallery

Each of these is caught by a quality gate — keep the cheatsheet open while you work.

Worked example

See the journey

Cheatsheet

Reflection