The production question
You've built the recovery-setup screen with a “Submit recovery” button bound to the action/primary semantic token, four interaction variants (default, hover, pressed, disabled), and a validation error state that appears when no target is selected. A developer opens the file, clicks into Dev Mode's inspect panel, and it dutifully spits out the exact CSS, spacing, and token name for whatever variant happens to be selected on the canvas. So what's left for you to actually write down? The judgment call is this: Dev Mode tells a developer what a static frame looks like right now — it cannot tell them why the button is disabled, when it re-enables, what happens to the review screen's chosen target if the user hits back, or how the toolbar should restructure at 768px versus collapse at 390px. Good handoff isn't re-describing pixels Dev Mode already surfaces; it's writing down the behavior and system logic that only exists in your head.
How to decide
- Check whether the value is already bound to a variable in the file. If it is, Dev Mode's inspect panel will surface the token name and its resolved value automatically — don't waste an annotation restating “gap: 16px, color: #2D6CDF” when the layer already carries that information.
- Check whether the behavior is stateful. If hover, pressed, disabled, or error exist only as separate detached frames rather than variants on one component, a developer inspecting the canvas only ever sees whichever single state is selected — either build the missing variants or write out the state transitions explicitly.
- Check whether the layout changes structure, not just scale, across breakpoints. A side nav collapsing into a top bar, or a table becoming stacked cards, is a transformation rule that lives nowhere in the file unless you annotate it at each breakpoint frame.
- Check whether an empty, loading, or error data state exists as a real frame. If “zero workloads” or “validation failed” was never built, Dev Mode has nothing to export — write what should render, because inspection can't invent a state you didn't design.
- Check whether the note explains a rule or just restates a value. “Disabled until a target is selected, re-enables immediately on selection” is a rule worth writing near the control. “Border-radius: 8px” is not — that's already in the inspect panel.
- Ask whether someone without Figma access, or without a paid Dev Mode seat, could still build the screen correctly from your layer names, bound variables, and written notes alone. If the answer depends on them clicking through your prototype to guess at behavior, the handoff isn't finished.
Correct vs. incorrect
On the recovery-setup screen, the “Submit recovery” button is built as a component with default/hover/pressed/disabled variants, its fill bound to action/primary. Next to the disabled variant, the designer adds one short annotation: “Disabled until a recovery target is selected in the list above; re-enables immediately on selection — no separate loading state for this transition.” This is correct because it adds exactly the thing Dev Mode's inspect panel cannot: the trigger condition and timing of a state change. The token, padding, and radius are already machine-readable from the bound variable, so repeating them would be noise.
On the confirmation overlay, the designer exports a screenshot and writes “close icon, top right, #6B7280 gray, 24px” — sampling the hex directly from the layer instead of naming the bound border/default or text/secondary token it should reference. The annotation duplicates information Dev Mode already exposes correctly through the token, and it's actively wrong the moment someone changes that semantic token during a later rebrand or dark-mode pass — the hardcoded hex in the annotation goes stale while the actual component updates, and a developer who trusts the note over the file ends up with mismatched, un-themeable color.
Practice it, then try to break it
Pick one screen from your recovery-workflow prototype — the review screen or the confirmation overlay works well. Without opening Dev Mode, write a single paragraph a developer with no Figma access could implement from: name the semantic tokens the screen consumes, list every interactive state present and what triggers each transition, describe the structural change (not just scaling) at 768px and at 390px, and state exactly what renders if the underlying data is empty or a validation error occurs.
Stress test: Hand your annotations to someone else — or imagine a developer working from an exported PDF with no Dev Mode seat — and ask them to describe what happens when a user leaves the recovery target empty and clicks Submit, using only your layer names and written notes, not by clicking through your interactive prototype. If they have to guess whether an error appears, where it appears, or whether Submit is disabled versus clickable-but-rejected, the handoff documentation has a gap that the prototype was silently covering for you.
Common mistakes
- Treating Dev Mode's auto-generated CSS and token readout as the complete handoff, leaving every interaction rule, state trigger, and responsive transformation undocumented because it “looked done” in the inspect panel.
- Annotating values that are already bound to variables — restating a color or spacing number that Dev Mode already surfaces correctly, which is redundant now and wrong later if the token changes but the note doesn't.
- Leaving hover, pressed, and disabled states as one-off unlabeled frames instead of component variants, so a developer inspecting the canvas only ever sees whichever static state happens to be selected.
- Abandoning handoff discipline entirely when Dev Mode isn't available on the team's plan, instead of falling back to the same clear names, bound variables, and written notes that make Dev Mode useful in the first place.
Accessibility and handoff
An overlay annotation that never states which key closes it or where keyboard focus lands afterward forces the developer to guess, and the guess is almost always “skip focus management,” which quietly fails keyboard accessibility on every confirmation dialog in the product.
FAQ
- Do I need a paid Figma seat with Dev Mode to hand off well?
- No. Dev Mode access can depend on plan tier, but the discipline that actually carries intent — clear frame names, bound semantic variables, and written behavior notes — works with or without it. Dev Mode is a convenience layer on top of that discipline, not a replacement for it.
- Should I annotate every value on the screen?
- No — only what inspection can't tell a developer: interaction rules, state triggers, responsive transformations, and data-state behavior. Restating an already-bound token's resolved value is redundant and can drift out of sync with the file over time.
- What's the actual difference between prototyping and handoff?
- Prototyping proves an interaction sequence works end to end, like clicking from dashboard through recovery setup to success. Handoff documents the system behind it — tokens, component states, responsive rules — so someone who never clicks through your prototype can still build it correctly.
- My component doesn't have hover, pressed, or disabled variants yet — can I still hand it off?
- Only weakly, through written notes describing each state by hand. It's better to build the states as interactive component variants first, so Dev Mode's inspect panel shows the correct state on its own, and reserve your annotations for the behavior logic that no inspect panel can show.
Take this skill into a connected project.
The full Mission 6 lesson includes guided steps, a timer, quiz, pass criteria, and saved progress.