EduFlow
UI Design with Figma
0%

Section 4 · Prototype to Handoff

Dev Mode and Handoff

14 min4 min readPut in order

Lesson at a glance

Prepare Steady’s screens for developers, mark them ready for dev, annotate behaviour and accessibility, and use Dev Mode’s inspect, variables and change comparison to keep handoff a conversation.

  1. 1Organise for the reader
  2. 2Ready for dev
  3. 3What developers see in Dev Mode
  4. 4Annotate what pixels cannot say

No video here — just the real thing: a written lesson, runnable examples, a quiz and practice.

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.

Organise for the reader

Before anything else, make the file easy to navigate for someone who was not there:

  • Move explorations off the Screens page. Developers should only see what will be built.
  • Group screens into sections by flow: “Check-in”, “Add habit”, “Habit detail”. Arrange each flow left to right in the order people move through it.
  • Include the states, not just the happy path: empty Today (“No habits yet”), a habit with a 1,000-day streak, the text field’s error state, the loading state of Habit detail.
  • Give each section a one-line description at the top: what the flow is for and any open questions.

Ready for dev

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.

Statuses 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.

A design moves from In design to Ready for dev, which is set by the designer. Editing it afterwards sets Changed automatically; the designer marks it done with changes and it returns to Ready for dev. When it is built, it can be marked Completed on higher plans. In design Ready for dev Changed Completed set automatically on edit done with changes Org and Enterprise
Dev Mode statuses as a design moves from design to build

What developers see in Dev Mode

Developers 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:

  • Measurements and layout: sizes, padding and gaps, with auto layout described in terms close to CSS flexbox.
  • Variables by name: the check button’s fill appears as 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.
  • Components and properties: the instance’s component, its variant and property values, and the component description you wrote in Lesson 3.5.
  • Code snippets: generated CSS, iOS and Android code, a starting point rather than production code. On Organization and Enterprise plans, teams can connect real component code with Code Connect so the snippet shows their own component instead.
  • Assets: icons and images marked for export, downloadable in the right format.

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.

Annotate what pixels cannot say

Some 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:

  • Content rules: habit names wrap to two lines, then truncate with an ellipsis; streaks above 999 show “999+”.
  • Behaviour: tapping a check button marks the habit done for today; it can be undone until midnight.
  • Accessibility: accessible names for icon buttons, the focus order of the New habit sheet, the 44 × 44 hit area, the reduced-motion alternative.
  • Data edge cases: what an empty list and a failed load look like, pointing at the frames that show them.

You 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.

Key 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 reading

Check your understanding

3 questions

Question 1 of 3

After marking the check-in flow Ready for dev, you change the habit row’s padding. What does a developer see?

Question 2 of 3

Which note belongs in an annotation rather than in the visual design?

Question 3 of 3

In Dev Mode a developer sees the check button’s fill as color/action/primary rather than only

Practice

Put in order

Hand off the check-in flow

The check-in flow is designed and tested. Put Sofia’s handoff steps in order, from preparing the file to checking what was built.

Use the arrow buttons to reorder.

  1. 1Annotate content rules, behaviour, accessible names and focus order.
  2. 2Walk the developers through the prototype and annotations, and answer questions.
  3. 3Group the remaining check-in screens into a section, arranged left to right in flow order.
  4. 4Add the missing states to that section: empty list, long habit name, error and loading.
  5. 5Mark the section Ready for dev.
  6. 6Review the first build side by side with the design and file fixes.
  7. 7Move explorations and old versions off the Screens page.