Figma Dev Mode: why developers finally stopped complaining about handoff

Previously, the transfer of the layout to the development looked something like this. The designer throws a link to Figma in the chat. The developer opens, searches for the desired screen among twenty frames, hovers on the indentation, sees “16” and writes in the chat “is this definitely padding or margin?”. The designer replies, "padding, I guess." After two days, a feature is rolled out, in which the button is not there, the color is slightly different, and the shadow is completely gone.

Dev Mode didn't remove that pain with a magic button. But for the first time, he did the normal thing: split the "I draw" mode and the "I code" mode. And when the teams realized this and rebuilt the process, the flood of complaints from developers about handoff just dried up. Not because developers have become more patient, but because they have finally been given a tool that speaks their language.

## Why Hendoff has been broken for years

The problem has never been at Figma per se. The problem was that the same file was used simultaneously by two completely different people with different tasks.

The designer thinks in frames, auto-layouts, variants of components. It is important for him to quickly move blocks, breed alternatives, keep drafts next to the final.

The developer thinks in tokens, variables, states, breakpoints. It is important to him: what color from the design system, what name this token has, what component it is in the code, what is considered the final version.

Before Dev Mode, they both looked out the same window. The developer made his way through the “design-draft-v3-FINAL-that-that-exact” frame, got confused in unbound styles, poked in a local hex instead of a token, and ended up rewriting the values with his hands. Every second bug in the layout began with the words “I thought this was it.”.

## What Really Changed With Dev Mode

In short, the developer has its own mode of working with the file, in which:

• Only those frames that are marked as ready for development (Ready for dev) are visible.
• Whenever possible, each value is shown as a variable or token, not as a crude number.
• There are separate sections about status, task reference, branch, and related component in the codebase.
• You can compare the two versions of the frame and see the diff - what exactly has changed since the last rollout.

It sounds simple, but it is these four things that close roughly the entire old list of claims. The developer no longer knows what is considered relevant. He doesn’t pick 16px out of thin air – he sees spacing/md. He doesn’t ask “this is a new icon or just a draft” – the frame has status.

## Scenario: how the transfer of features is now arranged

To be specific, this is what it looks like in a team where Dev Mode really caught on.

### Step 1. Designer closes the feature

The designer finishes the screen, runs himself through a short internal checklist:

• All colors and indentations are variables, not local values
• Components are from the library, not hand-drawn copies
• Hover, Disabled, Loading, Empty, Error - Presented, Not Implied
• The frame has the status of Ready for dev
• A link to the frame is attached to the task in the tracker

Without this checklist, Dev Mode won’t save you – it will just show the same mess, but in a slightly more neat wrapper.

### Step 2. Developer opens up Dev Mode

He only sees Ready frames. Clicks in the element - on the right receives values in the form of tokens, sizes, assets, a link to a component in Storybook (if the connection with the codebase is configured). It only downloads the necessary assets, not the entire folder.

### Step 3. A question arises - a comment directly on the element

And that’s where the old habit of “ask in chat” breaks down. The comment is put directly on the element, the story remains in the thread, the designer answers there. In a month, when a third person comes to fix the bug, they'll see context, not archaeology from Slack.

## Anti-patterns that reduce the benefits of Dev Mode to zero

Dev Mode does not discipline itself. If the team continues as before, the developer will just get a slightly more beautiful interface to the same chaos. The most frequent failures:

• No one puts the status of Ready for dev. The developer again does not know what to consider relevant.
• **The designer paints by eye, not tokens. In Dev Mode, you see numbers instead of variable names, and the whole point is lost.
• The black page and the product are in the same file without markup. Dev Mode will show you everything, including what you drew at lunch.
• Components in Figma don't match the components in the code by name. The developer manually translates "Button/Primary/Large" into <PrimaryButton size="lg"> each time.

If you recognize yourself in at least two points, the problem is not in the tool. The problem is that handoff as a process is not described.

## Summary of the section

Dev Mode ceased to be an "inspector's tab" and became a separate work mode for another role. This shifted the focus of the conversation: instead of "how do we export the layout," teams are finally discussing "what is considered ready to develop." The second question has always been the real one.

## How do you know if you’re having a bad time with Hendop

Before turning on Dev Mode and rejoicing that “everything will be fine,” it’s helpful to look honestly at the current file through the eyes of a developer. Most often, the diagnosis takes fifteen minutes and hurts self-esteem.

Open your main product file and go through five questions:

• If I turn off all the layers except those marked Ready for dev, will there be one screen left?
• How many local values of color and indentation on a typical screen that are not tied to a variable?
• Do the components in Figma match what they are called in the code?
• Does the outsider understand which of the three similar frames is relevant?
• Does every key screen have a void, bug, and boot state — or just the “perfect” option?

If the answer to most questions is “well, no,” you don’t have a Dev Mode problem. You have a file hygiene problem and no mode will fix it.

## Designer workflow: what changes in the layout

Dev Mode requires the designer to think not only about the picture, but also about how the frame will read as a specification. It's a different attention mode.

### File structure

A minimum that pays off almost immediately:

• A separate Production page is only what is already in the product or will be in the next release.
• A separate In progress page is something that is actively working on, the status of Draft or Ready for review.
• Separate Explorations - concepts, options, mudboards, everything that the developer should not see.
• Archive are older versions so you won’t be tempted to keep them close to combat.

Dev Mode sees the entire file, but statuses and pages allow you to cut off the noise. The main rule is not a single “final” frame outside of Production.

### Tokens instead of magic numbers

If the radius of curvature you have 6, 7 and 8 on three adjacent cards is not “author’s handwriting”, it is a future ticket “why do we have three different radii”. In Dev Mode, such discrepancies are instantly visible: the developer clicks on the item and sees the raw number instead of radius/sm. Any raw number is a candidate for a token or correction.

The rule of thumb is that if a value occurs more than twice in the layout, it must be variable. If you meet once, ask yourself why.

### Conditions as part of the layout, not as "later finish"

The most expensive class of bugs is not “the wrong color button”, but “what should be if the list is empty”. Dev Mode highlights the absence of states well: the developer sees one frame and logically makes only it.

For each data screen, keep clear options:

• Loading (skeleton or spinner – determine what it is)
• Empty state (no new user data)
• Empty state after the filter (data is available, but nothing was found)
• Network error
• Validation error at field level and form level
• The state of “no rights” or “function is not available on the tariff”

If at least two of these items are missing, do not mark the Ready for dev frame. Seriously.

## Questions to ask on the review of the layout

Before you transfer the screen to the development, run yourself or a colleague on a short list. This is not bureaucracy, this is insurance against correspondence in the spirit of “how should it be?”.

• Which token is responsible for each color and indentation on this screen?
• What happens if the text in the button becomes twice as long?
• How does the screen behave at the minimum supported width?
• Which component in the code matches this component in Figma?
• What is considered a “successful” completion of an action – and where is it visible to the user?
• What frame is the source of truth if there are three?

## Typical errors that can be seen through Dev Mode

When the team first turns the mode on seriously, the same set of sins pops up.

• Duplicates of components. Two Primary buttons in different libraries, differing by pixel. The developer will not guess which one you meant.
• Stripped instances. The component is kind of from the library, but someone untied and painted it. In Dev Mode, this is seen as “almost a button, but the values are local.”.
• **Hidden layers with outdated content. **You can’t see them with your eyes, but they fall into the specification and are confusing.
• **Auto layout for beauty. ** If the indentations are manually displayed over the auto layout, the developer will receive conflicting numbers and guess the intent.

## Summary of the section

Dev Mode is not a “do well” button, but a magnifier. It honestly shows how ready your file is to be coded. The good news is that the designer’s checklist is short: pure structure, tokens instead of numbers, explicit states matching the name code. The bad thing is that there are no workarounds, and the regime reveals it in five minutes.

## Advanced scenarios: when Dev Mode stops being just an inspector

After the file is put in order, Dev Mode turns from a magnifier into a desktop bundle of design-code. And here begins the interesting: the mode ceases to serve only the developer and becomes a tool of the entire team.

### Scenario 1: Designer edits directly through production code

Classic scheme - the designer opens Figma, the developer looks at the layout, reality in the browser. Three sources of truth, and they diverge in a week.

In the advanced scenario, the designer opens the page in the browser, compares with the frame and records discrepancies through comments directly in Dev Mode. Not “it seems that the indentations have gone”, and “here should be spacing/md, in the sale is 14”. The developer does not get a mood, but a specific diff.

### Scenario 2: A component in Figma is associated with a component in the code

Dev Mode allows you to link to the frame a link to the code – to Storybook, to the file in the repository, to the documentation page. It sounds small, but the effect is tangible: the developer does not look for what Button was meant, it falls on a specific, with actual props.

What to tie:

• Each published component has a link to its Storybook-story.
• To each page - a link to the route or feature flag in the admin.
• A complex frame is a link to the PR or ticket within which it is made.

It takes the designer minutes, and the developer saves hours of search.

### Scenario 3: AI and MCP assistants as layout readers

When an assistant connects to Figma via an MCP or plugin, the situation is reversed: now the layout is read not only by a person, but also by a model that generates markup on its basis. And here all the weaknesses of the file are strengthened.

If you have a frame with three radii, a person will write it off as “designer instinct.” The model will faithfully generate three different values and fix clutter in the code. If the layer is called Frame 482, the model will write the Frame482 component. If the empty screen state is drawn “on the adjacent artboard without a signature”, the model simply will not see it.

Practical rules for working with AI-generation on the layout:

• Before generating, make sure that all values are tokens, not raw numbers.
• Layer names should be read as component names: CardProduct, ButtonPrimary, not Group 12 copy.
• Hidden layers, untied instances and “draft” take away – the model does not understand that “the frame on the left is old”.
• Never accept generated code without diff against a design system: AI willingly invents tokens you don’t have.

AI does not replace a layout review. He's severely punishing him for being negligent.

## How to Check the Quality of Hendoff

Not “the layout is beautiful”, but “you can write code on it without asking questions”. These are different criteria.

### Mini Frame Audit before Ready for Dev

• All colors and indentations are variables, not raw values.
• All components used are from the library, the instances are not untied.
• States (download, empty, error, no rights) are present nearby.
• Layer names are meaningful, without Frame, Group, copy 3.
• Links to code or storybook are linked where appropriate.
• The behavior of text and containers as length changes is described or illustrated by example.
• The minimum and maximum width are clearly checked.

If there are less than five points on the list, the frame is not ready yet, no matter how good it looks.

### A metric that you can see with your eyes

The most honest indicator is the number of questions from the developer on the first day after handoff. If they're zero, the file's fine. If there are ten, the problem is not the developer.

## How to explain to a team that it’s not “a designer making life difficult”

A clean file looks like extra work until it starts saving someone else’s time. Arguments that work on the review and in conversation with the manager:

• Each raw pixel in the layout is a potential ticket to the backlog of visual bugs.
• Each untied instance is a future “why do we have two buttons” conversation.
• Every missing state is an incident in the trade that is bound to happen.
• Each meaningful layer name is a minus minute developer and minus an AI assistant error.

It's not perfectionism. This is the transfer of work from the expensive stage (development, testing, fix) to the cheap (mock-up).

### Summary of the section

Advanced work with Dev Mode is not about new buttons in the interface, but about discipline. Code links, meaningful names, tokens everywhere, states nearby, no drafts on production pages. The stricter the designer is to his own file, the less the team spends on guesses - and the calmer the person and the model look at this file.

## Anti-patterns that break handoff even on a good layout

Discipline inside the file is half the story. The second half is to not do things that make it go away. Most often, handoffs are destroyed not by the absence of tokens and bad names, but by habits that are considered normal in the team.

### Final finale v3 (edited by Lena)

When pages and frames reproduce faster than they are deleted, the developer opens the file and sees six variations of a single screen. Which one's at work, guess what. In Dev Mode, this is especially painful: Ready for dev status is on three versions at once, because no one had time to remove the old ones.

The rule is simple: one screen is one current frame. Everything else is either in the archive page or deleted. If you really want to save the story - for this there is a version history, not doubles on canvas.

### Design on top of production

The designer opens the file in which the developer is already working, and edits the frame right there, without a copy and without comment. After an hour, the build is visually different from the layout, and no one understands what has changed - the layout or the code.

Normally, edits go through a separate frame, branch or at least the annotation "here is what changed." Silent edits to a live layout are broken trust, which is then restored longer than the edit itself.

### States are hidden in a component that no one can see

“We have an error state,” and it lies inside the Input component variant, a property that is turned off by default. You can't see him on the feature page. The developer honestly realizes only what is drawn, and the state of error goes into tech debt.

The states should be visible on the canvas next to the main script. The options in the component are about reuse, not about specification.

### "It's obvious from the layout."

The most dangerous phrase in the discussion of handoff. It's obvious to the author who keeps the context in his head. It’s not obvious to anyone else — much less obvious to a model that reads a file literally.

If the behavior can be shown in a second frame or described in one line in the abstract, it is better to show and describe. Any "and so clear" is a future question in the chat at 23:40.

### Abstracts instead of a system

The reverse extreme: the developer is given a frame, hung with twenty comments about indentations, colors and behavior. This means that the system does not work: the rules that should live in the library and tokens have moved into text signatures. On the next screen you will have to write them again.

Annotation is for the specifics of this screen. For everything else, there are guidelines, tokens and components.

## Questions for review layout before transfer

These questions are worth asking yourself or a colleague at a design review - before the frame gets to the developer. They are short, but they usually come out with everything that is not finished.

### About the layout

• Is it possible to create a screen without opening Slack?
• If you remove the author of the file from access, will the layout remain clear?
• What three states of this screen did I not draw and why?
• What happens if the text in this block is three times longer? And one symbol?
• What are the values here – tokens, and which I stuffed with my hands “by eye?”?

### The code connection

• Does every component here exist in the codebase under the same name?
• If a developer clicks on Dev Mode, does it end up in Storybook instead of a void?
• Where in this layout did I reinvent what was already in the system?

### About the team

• Did anyone else see this frame through the eyes of a developer?
• If I’m on vacation tomorrow, the developer will ask who?
• What is decided in this layout, and what – “we will discuss on the go”? The second one usually turns into bugs.

## The final checklist before Ready for Dev

Do not duplicate the mini-audit above – this is a step wider, about the process, and not about the frame itself.

• Older versions of the screen are removed from the page or clearly marked as archive.
• Ready for dev status is exactly one option.
• All edits after the first handoff are documented by a comment, annotation or a message in a ticket.
• Controversial decisions are recorded in writing, not “agreed by voice”.
• The developer who will do this knows that the frame is ready, and does not know about it from case-by-case correspondence.
• The designer has a slot in the calendar for questions on this task in the coming days.

The last point is underestimated. Hendoff is not “given and forgotten”, it is “given and stayed connected”. The file may be perfect, but if the author is unavailable for a day, the developer will still start thinking.

## Short practical outcome

Dev Mode stopped being a separate pain, not because Figma added a magic button. It ceased to be a pain where the team realized a simple thing: the quality of handoff is not a property of the tool, but a property of habit.

The habit of holding tokens instead of numbers. The habit of naming layers as a component is called. The habit of drawing states near, and not somewhere “in the variant”. The habit of removing drafts from the production page. The habit of answering questions, rather than dismissing “everything is clear there.”.

The tool helps: connects the layout with the code, shows tokens, gives variables in the desired format, opens the way for AI assistants. But it amplifies exactly what is already in the file. A clean file becomes transparent in Dev Mode. Sloppy - becomes transparently sloppy, and it is visible to everyone: the developer, and models, and the team leader in retro.

A good handoff is not a design feat before release. This is the sum of small decisions made during the entire work on the layout. If each of them is slightly in favor of the reader of the file, at the end you get a screen on which to write code without question. If each slightly in its favor - it turns out another ticket "to clarify the design".

The choice is not made at the transfer stage. It is done every time you decide whether to stuff a number with your hands or take a variable.