Dev Mode: Why the developer stopped asking “what did you mean?”

Previously, the correspondence of the designer and developer looked something like this: “And the indentation here is 16 or 20?”, “This is the same button as the main or new?”, “What color is the hover, did you not unload?”, “And what about the empty state?”. For each layout - dozens of messages in slack, half in the evening, half on Friday at 19:00. The designer is angry, the developer is angry, the product comes out late.

Figma’s Dev Mode is not a “new developer tab.” This is a shift in how the interface is described. The layout ceases to be a picture and becomes a specification: with tokens, states, links to components, binding to the task. And the developer really stops asking "what did you mean" because the answer is already in the file.

But it only works if the designer has redesigned the process. Simply enabling Dev Mode is not enough – it will highlight exactly the discipline that is in the file. If it is not, the developer will get the same frustration, only in a new wrapper.

## Why “transfer layout” is not about export

Design transfer is not the moment when a designer throws a link into a thread. This is a process that begins long before and ends after release. And it has three typical loss points.

Loss of context. The developer doesn't know what the screen is doing. Sees UI, but doesn't see why. As a result, it implements literally - without understanding what is important and what is decorative.

The button is similar to the one already in the code, but not the same. The developer assembles a new one — and a month later, there are three buttons in the product that are almost the same.

** Loss of fortune. ** The layout has a happy path. What to show when downloading, error, empty data, long lines is thought out on the go. Mostly bad.

Dev Mode helps with two of the three. The context remains with the designer, and no tool can explain why this flow is important.

## Minimum File Hygiene Before Opening Dev Mode

Previously, it was possible to pass the layout “as is” and decide the rest in the correspondence. Now everything in the file, the developer will read literally. Therefore, before giving a link - go through the checklist.

### Checklist of layout readiness for development

• All colors are variables, not hex-s in a layer
• Retractions and sizes - through auto layout, not an eyepiece
• Fonts – styles, not local text settings
• Components are used as instances, not as copypaste
• Hover, Active, Disabled, Loading, Error, Empty
• The screen is marked as Ready for Dev
• A link to the task in the tracker is attached to the section
• Deleted drafts, experiments and old versions next to the final screen

The last point is underrated. If there are three “think” options next to the final screen, the developer may take the wrong one. Murphy's Law of Design works seamlessly.

### The anti-patterns that break Dev Mode

• ** Local variables instead of library.** Colors and sizes are given only in this file. A month later, the tokens in another file are already different - dissynchron.
• Detached components. The button looks like a button, but it's a group of layers. Dev Mode will not tell you to “use an existing Button” and the developer will build a new one.
• Text picture. Screenshot from the brief inserted into the layout "to be clear." The developer will copy it as a picture and will not notice.
• Hidden layers with the "correct" version. The final is the layer off under the main one. No one but the author would guess.

## What should live in the file and what should live in the task

Dev Mode provokes the temptation to put everything in Figma: description of logic, analytics, requirements. It doesn't end well. The file is turned into a landfill and the tracker is empty - and vice versa, any updates to the requirements are lost.

Reasonable separation:

• **In the file: ** Visual, states, tokens, components, links to the used elements of the design system, short notes about behavior ("click - modal X").
• Task: Goal, success metric, edge cases, data requirements, decision history, research references.
• On the boundary: a reference from the task to a specific section in Figma and a reference from Figma to the task. Both ways.

The rule is simple: if information can change without redrawing the layout, its place in the task. If it's about how the screen looks and behaves, it's in the file.

## Workflow: from layout to commit

Putting the romance aside, transferring design to Dev Mode is four steps that don’t have to be telepathic.

### Step 1. Designer labels what's ready

Not "whole page, sort it out." And specific frames with Ready for dev status, tied to the task in the tracker. Anything that is not tagged, the developer has the right not to look – and that’s fine. Marking is a contract: “I promise you that I will not change my mind until the end of the sprint.”.

### Step 2. Developer reads tokens, not pixels

In Dev Mode, it looks not at 16px, but at the variable name space-md, color-surface-primary, radius-sm. If the code has the same system, it copies the token. If there's a number in the file instead of a token, it's either hardcoding or coming to ask. Both options are bad.

### Step 3. Reconciliation with existing code

Before you build a new component, the developer looks for a similar one in the codebase. Dev Mode only helps if the component in Figma has a name that matches the code, or there is a link to Storybook. Without that connection, Dev Mode is a beautiful but isolated picture.

### Step 4. Return questions to the file, not to the face

All clarifications - comments on the frame. Not in a conversation, not in a five-minute call. So the next developer who's going to be editing this screen in six months has a history of solutions.

## Diagnosis: where exactly the transmission breaks

When the developer comes back with “what you meant,” it’s not laziness that’s to blame, but a specific failure. It's good to learn to call him.

### Symptoms and causes

Что слышит дизайнер	Что на самом деле сломано
«А какой тут отступ?»	Auto layout не настроен, размер выставлен глазом
«Это та же кнопка, что на главной?»	Компонент detached или назван иначе, чем в коде
«Что показывать, если данных нет?»	Состояние empty не нарисовано
«Какой цвет hover?»	Нет варианта компонента для интерактивных состояний
«Шрифт точно такой?»	Использован локальный стиль вместо переменной типографики
«Эта иконка откуда?»	Иконка вставлена картинкой, а не из библиотеки

If the same questions are repeated from sprint to sprint – it is not the developer inattentive, it is in the file systemically underwrote something one. Fix the source, not the symptom.

### Quick self-diagnosis of the file

Open your layout with the eyes of the person who sees it for the first time. Ask three questions:

• If you remove you from chat for a week, will the developer get to the end without any questions?
• If the task changes and the frame needs to be redistributed, will it shrink itself or fall apart?
• If the token is updated in the design system, will the changes reach this screen automatically?

Three yes, the file is ready. At least one "no" - Dev Mode will highlight this hole.

## Typical Designer Mistakes Dev Mode Makes Visible

Previously, these sins were forgiven – now they are displayed in the developer’s right panel as fact.

• One component with twenty Boolean props. In Figma looks universal, in code turns into a monster. Better two honest components than one with a state matrix per thousand combinations.
• Layer names like Frame 1273. The developer sees exactly that name. No "he'll understand.".
• ** Magic numbers in indentations.** 13px, 27px, 41px. In the code, it will be either a hard code or a month of token disputes.
• **States on a separate state page. ** They are not related to the main component. Dev Mode doesn’t show them around and they’re forgotten.
• Design at the same scale. Desktop, mobile version later. The developer builds on a whim, and this “later” will remain forever.

## How to apply this in the layout right now

You don’t have to change the entire library over the weekend. It is enough to build a few habits.

### Checklist before giving a link to the developer

• Opened Dev Mode themselves and passed through the frame through the eyes of the developer
• All sizes and colors are highlighted as tokens, not as raw values
• Interactive elements show state variations
• The names of the components are the same as they are called in the code
• Attached to the frame is a reference to the task and a brief description of the behavior
• Removed or archived anything that is not in this release

### Questions for a double review with the developer

Once in a couple of sprints, sit down for half an hour and walk together on a fresh frame. Not for presentation, but to hear friction.

• What did you open first when you entered the file?
• Where did you guess?
• What tokens did you not find and hardcoded?
• What component did you reassemble when you could reuse it?
• What would you like to see in Dev Mode that is not there?

These five questions fix more processes in a quarter than any redesign of a design system.

## Segment summary

Dev Mode doesn’t make the layout clear – it makes it clear how disciplined the layout is. The workflow is based on four things: explicit marking of readiness, tokens instead of numbers, names that match the code, and states drawn next to the happy path. Everything else is derivative.

## When an AI appears on the team

As soon as the assistant – Copilot, Cursor, MCP plugin to Figma – is involved in the process, Dev Mode ceases to be just a showcase for a developer. It becomes the context the machine reads. And the machine reads literally.

If the frame is named Frame 1273 and the component is called Component 7 / Variant 3, the AI will generate exactly the same meaningless classes and props. If the indentation is exposed with the eye, it will substitute a number, not a token. The assistant doesn’t know – it reflects the discipline of the file.

### What changes in the work of the designer

• Layer and component names become part of the codebase, even if you don't commit them.
• The variant description (hover, disabled, loading) is converted into a state name in the code.
• The caption to the frame like "if we make a mistake, show a toast for 3 seconds" goes to the prompt as a requirement.
• Any “temporary stub” in the layout risks reaching the product repository.

### Anti-patterns when working with an AI assistant

• The gray area between the layout and the draft. AI does not distinguish "this is the final" from "this I sketched in the meeting." If there is no explicit marking of readiness in the file, everything will be generated.
• ** Hidden layers with alternatives.** Hidden version of the button in the layout is noise for the model. Take the alternatives to a separate frame or remove them.
• Comments instead of specifications. Stickers and Figma-comments assistant often does not see. Behavior should live in a component description or in a related task, not in a side cloud.
• Context, which is only in the head. "We agreed on the call that there will be a skeleton" - for AI does not exist. Not recorded, not counted.

## How to check the quality of transmission

A good sign is that the developer and assistant are assembling the screen without asking questions. The bad news is that the questions are gone, but there are weird solutions in PR. Silence doesn't equal understanding.

### Post-release mini-audit

Once in a sprint, compare three dots on one feature:

• what was drawn in the layout,
• what's in the code,
• what the user eventually saw.

The discrepancies are the map of the holes in the transmission. Not to catch anyone, but to understand where Dev Mode fell short and why.

### Signals that the process is working

• The layout is not returned with questions a week after the start of development.
• Magic numbers and local styles rarely appear in PR.
• The new person on the team makes up the file in the same way as the old-timer.
• Changing the token in the library reaches the screen without manual editing in the code.
• An AI-generated piece goes through a review without rewriting names.

If at least three points are consistently executed – you don’t have a “figma” – you have a work contract between design and code.

## How to explain this to your team, not just yourself

The discipline in the file is not sold with the phrase “let’s do it more carefully.” It sells at the price of error.

### Arguments that hear different roles

• **Developer: "Every magical indentation is a future ticket for editing, which will come in a month, when you have already forgotten the context.".
• **Product: "Every undrawn condition is either a bug in the sale or a lost week to fix.".
• Lead of design: "Without tokens, a redesign of any little thing is worth a redesign of the entire section.".
• “Every time I answer the question ‘what’s the indentation here,’ I pay for not finishing the layout ten seconds ago.”.

### Questions for retro transfer

• How many times during the sprint we returned to the already “ready” layouts?
• What questions did developers spend the most time on?
• Where did AI generate the wrong thing - and why did the layout allow it to?
• What are the three rules in a file that will reduce half of future questions?

## Segment summary

Dev Mode in a team with AI is no longer a viewbar, but an interface between the designer’s head and code that is not only written by a person. Check not the reaction of the developer, but the discrepancy between the layout, PR and sales. And explain the discipline of the file not in terms of “beautiful,” but in terms of the cost of each unsaid pixel.

## File Readiness Checklist for Dev Mode

Before you open the layout to the developer and especially the AI assistant, run the file through a short list. Not for beauty, not to answer the same questions in chat.

### Structure and navigation

• There is a “ready-to-develop” page in the file, and only what is really ready gets there.
• Drafts, searches, mudboards - on a separate page with a clear prefix (wip-, explore-).
• The main frame of the feature is named the same as the ticket or branch in the repository.
• The screen shows the entry point: where the user came from and where he will go.

### Components and tokens

• Colors, indentations, radii, shadows are of variables, not hammered into hands.
• The component describes all states: default, hover, focus, disabled, loading, error, empty.
• The names of the variants are the same as what they are called in the code, not "var 2 finale new.".
• Icons are in the library, not inserted as pictures in a particular frame.

### Behavior and logic

• Each button understands what happens when you click – either a link to another frame, or text in the description.
• The boundary states are described: empty list, long text, network error, slow loading.
• The adapter is shown on at least two widths, not "the developer will guess later.".
• Texts are final or explicitly marked as stubs (lorem, placeholder).

If at least 80% of the items have passed on this list, Dev Mode and the assistant will be useful. If less, you feed the model noise, and then you’re surprised that PR has random colors.

## Anti-patterns that break transmission

### Let's do it like we did in the past

The most expensive phrase in a chat. The past project lived on its grid, its tokens and its understanding of the secondary button. Drag the visually similar doesn’t mean dragging the system. Either transfer the entire tokens and components, or reassemble them and explicitly talk about it.

### One giant frame for everything

When the onboarding, the main script and the admin lie in the same canvas without boundaries, the developer and assistant see mush. Divide according to scenarios, even if it seems that “and so clear”.

### Final layout in the comments

If key behavioral decisions live in the Figma comment thread, consider them nonexistent. Comments are lost, filtered, not pulled up in Dev Mode. Behavior - in the description of the component, in the task or in the rules on the feature page.

### "AI will figure it out."

It will, but not in the way you wanted. The assistant will complete the logic on the statistics of similar interfaces, not on your product. If the layout does not indicate that the list is virtualized, get the usual map. If the form is not specified to work without JS, it will not work.

### Designer as the only source of truth

If you need to go to the author of the layout for any question on the screen, the system does not work. The file has to answer itself. The designer connects to controversial places, not to the question of “what type is here”.

## Questions for review layout before transfer

Run the layout out loud as if you’re a new developer seeing the feature for the first time.

• What happens if the data hasn’t loaded yet?
• What happens if there is no data at all?
• What happens if there's too much data -- a 500-line list, a three-paragraph header?
• How does the screen behave on a narrow mobile and on a wide desktop?
• What is available from the keyboard, and what is only a mouse?
• Which texts are translated and which are sewn into code?
• Which elements are clickable and which look clickable but shouldn’t be?
• Where does each number and each avatar come from — from the API, from the store, from the local state?

If the answer to half the questions is “I don’t know, we’ll ask back” – it’s okay, but these questions should hang on the layout explicitly, and not pop up on the third day of development.

### A separate unit for AI assembly

• Are layer names read as variable names?
• The names of the component variants match the props you would expect in the code?
• There are no "dead" hidden layers in the layout that the assistant can pull out?
• Do text styles have meaningful names instead of style 14?

## Practical outcome

Dev Mode doesn’t make it automatic; it makes it honest. You can immediately see where the layout is a system, and where the beautiful picture is. The AI assistant only enhances this effect: a disciplined file turns into a work contract, a sloppy one into a generator of weird PR.

The working process is based on three simple things: clear file structure, tokens and components instead of magical values, explicit description of behavior and boundary states. Everything else is details that you quickly get along. And most importantly, stop checking the transfer by whether the developer asks questions. Check by how the assembled screen matches the one you drew, without a long chat in the middle.