A developer opens Steady’s file for the first time. Without help, they face sixty frames, three explorations of the Today screen and a page called Scratch, and they have to guess which version is real, what happens when a name is too long and whether that teal is a token or a one-off. Every guess becomes a bug, a Slack thread, or both.
Handoff is the work of removing those guesses. Most of it you have already done: named layers, auto layout, components with properties, variables. This lesson adds the last layer.
\nBefore anything else, make the file easy to navigate for someone who was not there:
\nScreens page. Developers should only see what will be built.When a flow is stable, select its section and mark it Ready for dev. At the time of writing, you can do this on sections, frames and components, and it is available on paid plans.
\nStatuses are a signal, not a lock. If you edit a design after marking it ready, Figma marks it Changed automatically, so developers know to look again, and they can compare the current version with the one that was marked ready. When you have finished changing it, you mark it done with changes and can add a short note. On Organization and Enterprise plans there is also a Completed status for designs that have been built.
\nDevelopers switch to Dev Mode with the toggle in the toolbar or Shift+D. It needs a paid plan and a Full or Dev seat at the time of writing. Selecting a layer shows its inspect panel:
color/action/primary with its value, padding as space/4. If you set code syntax on your variables (Lesson 3.3), developers see the exact token name their code uses.This is where all the earlier discipline pays off. A component with named layers and bound variables reads like a spec; a detached frame with raw hex codes reads like a puzzle.
\nSome things are invisible in a static frame. Annotations put them right on the design. Press Shift+T (or use the annotation tool), select a layer and write a note, or pin a property so it stays visible. At the time of writing, annotations have categories such as Development, Interaction, Accessibility and Content, and developers can filter by them. Measurements (Shift+M) pin spacing on the canvas.
For Steady, annotate:
\nYou have designed, systematised, prototyped, checked and handed off Steady. The final lesson is about the two skills that turn this work into a career: running a critique and telling the story in a case study.
\n","toc":[{"id":"sec-1","text":"Organise for the reader","level":2},{"id":"sec-2","text":"Ready for dev","level":2},{"id":"sec-3","text":"What developers see in Dev Mode","level":2},{"id":"sec-4","text":"Annotate what pixels cannot say","level":2}],"takeaways":["Handoff starts with an organised file; sections per flow, named layers and components bound to variables do most of the work.","Ready for dev tells developers which designs are stable, and Figma flags a design as changed when someone edits it afterwards.","Dev Mode shows measurements, variables by name and code snippets, so developers read tokens instead of guessing from pixels.","Annotations carry what pixels cannot, such as behaviour, edge cases, accessible names and focus order.","Handoff is a conversation, so walk developers through the flow and review the built screens against the design."],"further":[{"title":"Guide to Dev Mode","url":"https://help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode"},{"title":"Dev Mode statuses and notifications","url":"https://help.figma.com/hc/en-us/articles/26781702258583-Dev-Mode-statuses-and-notifications"},{"title":"Add measurements and annotate designs","url":"https://help.figma.com/hc/en-us/articles/20774752502935-Add-measurements-and-annotate-designs-in-Dev-Mode"}],"quiz":[{"q":"After marking the check-in flow Ready for dev, you change the habit row’s padding. What does a developer see?
","options":[{"text":"Nothing, because Ready for dev freezes the design.","why":"Ready for dev is a signal, not a lock. Designers can still edit, and Figma records that they did."},{"text":"The design shows as changed, and they can compare it with the version that was marked ready.","why":"Correct. The Changed status is applied automatically, and comparing versions shows exactly what moved."},{"text":"Figma automatically reverts the edit.","why":"Figma never reverts your edits. It surfaces them so developers are not surprised."},{"text":"The developer must unmark and remark the section to see edits.","why":"Developers see the latest design and the changed status without any extra steps."}],"answer":1},{"q":"Which note belongs in an annotation rather than in the visual design?
","options":[{"text":"The habit row’s corner radius is 12.","why":"Dev Mode already shows the radius, and its variable, from the design. Annotating it adds noise."},{"text":"The title font is the Large title style.","why":"The text style name is visible in Dev Mode. No annotation needed."},{"text":"The screen background is white.","why":"The fill and its variable are visible in Dev Mode. Annotations are for what cannot be seen."},{"text":"Habit names wrap to two lines, then truncate with an ellipsis; the add button’s accessible name is “Add habit”.","why":"Correct. Wrapping rules and accessible names are behaviour you cannot read from a static frame."}],"answer":3},{"q":"In Dev Mode a developer sees the check button’s fill as color/action/primary rather than only
The check-in flow is designed and tested. Put Sofia’s handoff steps in order, from preparing the file to checking what was built.
\n","hints":["Developers should never see a flow marked ready that still contains explorations or missing states.","Annotations describe the final frames, so they come after the states exist, and before the ready signal.","Clean, group, add states, annotate, mark ready, walk through, review the build."],"explanation":"First clean up so only real designs remain, then group the screens into a section in flow order. Add the missing states (empty, error, long content) because annotations and developers both need them. Annotate behaviour and accessibility on those final frames. Only then mark the section Ready for dev, so the signal means “stable”. Walk the developers through the flow, and finally review the build against the design. Marking ready earlier would trigger Changed badges for every later edit and teach developers to ignore them.
\n","checkLabels":{},"itemText":{"clean":"Move explorations and old versions off the Screens page.","sections":"Group the remaining check-in screens into a section, arranged left to right in flow order.","states":"Add the missing states to that section: empty list, long habit name, error and loading.","annotate":"Annotate content rules, behaviour, accessible names and focus order.","ready":"Mark the section Ready for dev.","walkthrough":"Walk the developers through the prototype and annotations, and answer questions.","review":"Review the first build side by side with the design and file fixes."}},"words":810,"readMinutes":4}