Dev Mode: почему разработчик перестал спрашивать «что ты имел в виду»

Раньше переписка дизайнера и разработчика выглядела примерно так: «А отступ тут 16 или 20?», «Это та же кнопка что на главной или новая?», «Какой цвет у hover, ты не выгрузил?», «А что с пустым состоянием?». На каждый макет — десятки сообщений в слаке, половина вечером, половина в пятницу в 19:00. Дизайнер злится, разработчик злится, продукт выходит позже срока.

Dev Mode в Figma — это не «новая вкладка для разработчиков». Это сдвиг в том, как описывается интерфейс. Макет перестаёт быть картинкой и становится спецификацией: с токенами, состояниями, ссылками на компоненты, привязкой к задаче. И разработчик действительно перестаёт спрашивать «что ты имел в виду» — потому что ответ уже в файле.

Но это работает только если дизайнер перестроил процесс. Просто включить Dev Mode недостаточно — он подсветит ровно ту дисциплину, которая есть в файле. Если её нет, разработчик получит те же фрустрации, только в новой обёртке.

## Почему «передать макет» — это не про экспорт

Передача дизайна — это не момент, когда дизайнер кидает ссылку в тред. Это процесс, который начинается задолго до и заканчивается после релиза. И в нём есть три типичные точки потерь.

Потеря контекста. Разработчик не знает, какую задачу решает экран. Видит UI, но не видит зачем. В итоге реализует буквально — без понимания, что важно, а что декоративно.

Потеря системности. Кнопка похожа на ту, что уже есть в коде, но не такая же. Разработчик собирает новую — а через месяц в продукте три кнопки, которые «почти одинаковые».

Потеря состояний. На макете нарисован happy path. Что показывать при загрузке, ошибке, пустых данных, длинных строках — додумывается на ходу. Чаще всего плохо.

Dev Mode помогает с двумя из трёх. Контекст всё равно остаётся на дизайнере — никакой инструмент не объяснит за вас, почему этот флоу важен.

## Минимальная гигиена файла перед тем, как открывать Dev Mode

Раньше можно было сдать макет «как есть» и решить остальное в переписке. Сейчас всё, что в файле, разработчик прочитает буквально. Поэтому до того как давать ссылку — пройдитесь по чеклисту.

### Чеклист готовности макета к разработке

• Все цвета — переменные, не hex-ы захардкоженные в слой
• Отступы и размеры — через auto layout, а не глазомером
• Шрифты — стили, не локальные настройки текста
• Компоненты используются как инстансы, а не копипастой
• Состояния (hover, active, disabled, loading, error, empty) — нарисованы, а не подразумеваются
• Экран помечен как Ready for dev
• К секции прикреплена ссылка на задачу в трекере
• Удалены черновики, эксперименты и старые версии рядом с финальным экраном

Последний пункт недооценён. Если рядом с финальным экраном лежат три варианта «на подумать», разработчик может взять не тот. Закон Мёрфи в дизайне работает безотказно.

### Анти-паттерны, которые ломают Dev Mode

• «Локальные переменные» вместо библиотеки. Цвета и размеры заданы только в этом файле. Через месяц токены в другом файле уже другие — рассинхрон.
• Detached-компоненты. Кнопка выглядит как кнопка, но это группа слоёв. Dev Mode не подскажет «используй существующий Button», и разработчик соберёт новый.
• Текст картинкой. Скриншот из брифа, вставленный в макет «чтобы было понятно». Разработчик скопирует его как картинку и не заметит.
• Спрятанные слои с «правильной» версией. Финал — выключенный слой под основным. Никто, кроме автора, не догадается.

## Что должно жить в файле, а что — в задаче

Dev Mode провоцирует соблазн положить в Figma вообще всё: описание логики, аналитику, требования. Это плохо кончается. Файл превращается в свалку, а трекер пустеет — и наоборот, любые обновления требований теряются.

Разумное разделение:

• В файле: визуал, состояния, токены, компоненты, ссылки на используемые элементы дизайн-системы, короткие пометки про поведение («при клике — модалка X»).
• В задаче: цель, метрика успеха, edge cases, требования к данным, история решений, ссылки на исследования.
• На границе: ссылка из задачи на конкретную секцию в Figma и ссылка из Figma на задачу. В обе стороны.

Правило простое: если информация может измениться без перерисовки макета — её место в задаче. Если она про то, как выглядит и ведёт себя экран — в файле.

## Рабочий процесс: от макета к коммиту

Если убрать романтику, передача дизайна в Dev Mode — это четыре шага, между которыми не должно быть телепатии.

### Шаг 1. Дизайнер маркирует, что готово

Не «вся страница, разбирайся». А конкретные фреймы со статусом Ready for dev, привязанные к задаче в трекере. Всё, что не помечено, разработчик имеет право не смотреть — и это нормально. Маркировка — это договор: «вот это я обещаю, что не передумаю до конца спринта».

### Шаг 2. Разработчик читает токены, а не пиксели

В Dev Mode он смотрит не на «16px», а на имя переменной — space-md, color-surface-primary, radius-sm. Если в коде такая же система — он копирует токен. Если в файле число вместо токена, он либо захардкодит, либо придёт спрашивать. Оба варианта плохие.

### Шаг 3. Сверка с уже существующим в коде

Прежде чем верстать новый компонент, разработчик ищет похожий в кодовой базе. Dev Mode тут помогает только если у компонента в Figma указано имя, совпадающее с кодом, либо есть ссылка на Storybook. Без этой связи Dev Mode — красивая, но изолированная картинка.

### Шаг 4. Возврат вопросов в файл, а не в личку

Все уточнения — комментариями на фрейме. Не в диалоге, не на созвоне «на пять минут». Так у следующего разработчика, который через полгода будет править этот экран, есть история решений.

## Диагностика: где именно ломается передача

Когда разработчик снова приходит с «что ты имел в виду», виновата не лень, а конкретный сбой. Полезно научиться его называть.

### Симптомы и причины

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

Если одни и те же вопросы повторяются от спринта к спринту — это не разработчик невнимательный, это в файле системно недокручено что-то одно. Чините источник, а не симптом.

### Быстрая самодиагностика файла

Откройте свой макет глазами человека, который видит его впервые. Задайте три вопроса:

• Если убрать вас из чата на неделю, разработчик дойдёт до конца без вопросов?
• Если задача поменяется и фрейм нужно переразложить — он сожмётся сам или развалится?
• Если в дизайн-системе обновится токен — изменения долетят до этого экрана автоматически?

Три «да» — файл готов. Хотя бы одно «нет» — Dev Mode подсветит именно эту дыру.

## Типичные ошибки дизайнера, которые Dev Mode делает видимыми

Раньше эти грехи прощались — теперь они выводятся в правой панели у разработчика как факт.

• Один компонент с двадцатью булевыми пропсами. В Figma выглядит универсально, в коде превращается в монстра. Лучше два честных компонента, чем один с матрицей состояний на тысячу комбинаций.
• Имена слоёв вроде Frame 1273. Разработчик видит ровно это имя. Никакого «он сам поймёт».
• Магические числа в отступах. 13px, 27px, 41px. В коде это будет либо хардкод, либо месяц споров про токены.
• Состояния на отдельной странице «states». Они не связаны с основным компонентом. Dev Mode не показывает их рядом — и про них забывают.
• Дизайн в одном масштабе. Сделано под десктоп, мобильная версия «потом». Разработчик сверстает по наитию, и это «потом» останется навсегда.

## Как применять это в макете прямо сейчас

Не обязательно переделывать всю библиотеку за выходные. Достаточно встроить несколько привычек.

### Чеклист перед тем, как дать ссылку разработчику

• Открыли Dev Mode сами и прошли по фрейму глазами разработчика
• Все размеры и цвета подсвечиваются как токены, а не как сырые значения
• У интерактивных элементов видны варианты состояний
• Имена компонентов совпадают с тем, как они называются в коде
• К фрейму прикреплена ссылка на задачу и краткое описание поведения
• Удалили или унесли в архив всё, что не идёт в этот релиз

### Вопросы для парного ревью с разработчиком

Раз в пару спринтов сядьте на полчаса и пройдите вместе по свежему фрейму. Не для презентации, а чтобы услышать трение.

• Что ты открыл первым, когда зашёл в файл?
• Где пришлось догадываться?
• Какие токены ты не нашёл и захардкодил?
• Какой компонент ты собрал заново, хотя мог переиспользовать?
• Что бы ты хотел видеть в Dev Mode, чего там нет?

Эти пять вопросов за квартал чинят больше процессов, чем любой редизайн дизайн-системы.

## Короткий итог сегмента

Dev Mode не делает макет понятным — он делает понятным, насколько макет дисциплинирован. Рабочий процесс держится на четырёх вещах: явная маркировка готовности, токены вместо чисел, имена, совпадающие с кодом, и состояния, нарисованные рядом с happy path. Всё остальное — производное.

## Когда в команде появляется AI

Как только в процессе участвует ассистент — Copilot, Cursor, MCP-плагин к Figma — Dev Mode перестаёт быть просто витриной для разработчика. Он становится контекстом, который читает машина. И машина читает буквально.

Если у фрейма имя Frame 1273, а у компонента — Component 7 / Variant 3, AI сгенерирует ровно такие же бессмысленные классы и пропсы. Если отступ выставлен глазом, он подставит число, а не токен. Ассистент не догадывается — он отражает дисциплину файла.

### Что меняется в работе дизайнера

• Имена слоёв и компонентов становятся частью кодовой базы, даже если вы их туда не коммитите.
• Описание варианта (hover, disabled, loading) превращается в имя состояния в коде.
• Подпись к фрейму вроде «при ошибке показываем тост 3 секунды» уезжает в промпт как требование.
• Любая «временная заглушка» в макете рискует доехать до прод-репозитория.

### Анти-паттерны при работе с AI-ассистентом

• Серая зона между макетом и черновиком. AI не отличает «это финал» от «это я набросал на встрече». Если в файле нет явной маркировки готовности — сгенерируется всё подряд.
• Скрытые слои с альтернативами. Спрятанный вариант кнопки в макете — это шум для модели. Уносите альтернативы в отдельный фрейм или удаляйте.
• Комментарии вместо спецификации. Стикеры и Figma-комменты ассистент чаще всего не видит. Поведение должно жить в описании компонента или в связанной задаче, а не в облачке сбоку.
• Контекст, который есть только в голове. «Мы договорились на созвоне, что тут будет скелетон» — для AI не существует. Не записано — не учтено.

## Как проверять качество передачи

Хороший признак — что разработчик и ассистент собирают экран без уточняющих вопросов. Плохой — что вопросы исчезли, но в PR появились странные решения. Молчание не равно понимание.

### Мини-аудит после релиза

Раз в спринт сравните три точки по одной фиче:

• что было нарисовано в макете,
• что собралось в коде,
• что в итоге увидел пользователь.

Расхождения — это и есть карта дыр в передаче. Не для того, чтобы кого-то ловить, а чтобы понять, где Dev Mode не дотянул и почему.

### Сигналы, что процесс работает

• К макету не возвращаются с вопросами через неделю после старта разработки.
• В PR редко появляются магические числа и локальные стили.
• Новый человек в команде верстает по файлу так же, как старожил.
• Изменение токена в библиотеке доезжает до экрана без ручной правки в коде.
• AI-сгенерированный кусок проходит ревью без переписывания имён.

Если хотя бы три пункта стабильно выполняются — у вас не «удобный Figma», у вас рабочий контракт между дизайном и кодом.

## Как объяснить это команде, а не только себе

Дисциплина в файле не продаётся фразой «давайте делать аккуратнее». Продаётся через цену ошибки.

### Аргументы, которые слышат разные роли

• Разработчику: «Каждый магический отступ — это будущий тикет на правку, который придёт через месяц, когда ты уже забудешь контекст».
• Продакту: «Каждое ненарисованное состояние — это либо баг в проде, либо потерянная неделя на доделки».
• Лиду дизайна: «Без токенов редизайн любой мелочи стоит как редизайн всего раздела».
• Самому себе: «Каждый раз, когда я отвечаю на вопрос „какой тут отступ“, я плачу за то, что не дописал в макете десять секунд назад».

### Вопросы для ретро по передаче

• Сколько раз за спринт мы возвращались к уже «готовым» макетам?
• На каких вопросах разработчики тратили больше всего времени?
• Где AI сгенерировал не то — и почему макет позволил ему это сделать?
• Какие три правила в файле сократят половину будущих вопросов?

## Короткий итог сегмента

Dev Mode в команде с AI — это уже не панель просмотра, а интерфейс между головой дизайнера и кодом, который пишет не только человек. Проверяйте не реакцию разработчика, а расхождение между макетом, PR и продом. И объясняйте дисциплину файла не через «красиво», а через стоимость каждого недосказанного пикселя.

## Чеклист готовности файла к Dev Mode

Перед тем как открывать макет разработчику и тем более AI-ассистенту, прогоните файл по короткому списку. Не для красоты — чтобы потом не отвечать на одни и те же вопросы в чате.

### Структура и навигация

• В файле есть страница «готово к разработке», и туда попадает только то, что действительно готово.
• Черновики, поиски, мудборды — на отдельной странице с понятным префиксом (wip-, explore-).
• Главный фрейм фичи назван так же, как тикет или ветка в репозитории.
• У экрана видна точка входа: откуда пользователь сюда попал и куда уйдёт.

### Компоненты и токены

• Цвета, отступы, радиусы, тени — из переменных, а не вбиты руками.
• У компонента описаны все состояния: default, hover, focus, disabled, loading, error, empty.
• Имена вариантов совпадают с тем, как их называют в коде, а не «вар 2 финал новый».
• Иконки лежат в библиотеке, а не вставлены как картинки в конкретный фрейм.

### Поведение и логика

• У каждой кнопки понятно, что происходит при клике — или ссылкой на другой фрейм, или текстом в описании.
• Описаны граничные состояния: пустой список, длинный текст, ошибка сети, медленная загрузка.
• Адаптив показан как минимум на двух ширинах, не «потом разработчик догадается».
• Тексты — финальные или явно помечены как заглушка (lorem, placeholder).

Если по этому списку прошло хотя бы 80% пунктов — Dev Mode и ассистент будут полезны. Если меньше — вы кормите модель шумом, а потом удивляетесь, что в PR оказались случайные цвета.

## Анти-паттерны, которые ломают передачу

### «Сделаем как на прошлом проекте»

Самая дорогая фраза в чате. Прошлый проект жил по своей сетке, своим токенам и своему пониманию «вторичной кнопки». Перетащить визуально похожее — не значит перетащить систему. Либо переносите токены и компоненты целиком, либо собираете заново и явно об этом говорите.

### Один гигантский фрейм на всё

Когда онбординг, основной сценарий и админка лежат в одном холсте без границ, разработчик и ассистент видят кашу. Делите по сценариям, даже если кажется, что «и так понятно».

### Финальный макет в комментариях

Если ключевые решения по поведению живут в треде Figma-комментариев, считайте, что их нет. Комменты теряются, скрываются по фильтру, не подтягиваются в Dev Mode. Поведение — в описании компонента, в задаче или в правилах на странице фичи.

### «AI сам разберётся»

Разберётся, но не так, как вы хотели. Ассистент достроит логику по статистике похожих интерфейсов, а не по вашему продукту. Если в макете не указано, что список виртуализируется, — получите обычный map. Если не указано, что форма должна работать без JS, — не будет работать.

### Дизайнер как единственный источник правды

Если на любой вопрос по экрану нужно идти к автору макета — система не работает. Файл должен отвечать сам. Дизайнер подключается к спорным местам, а не к вопросу «какой тут шрифт».

## Вопросы для ревью макета перед передачей

Прогоните макет вслух, как будто вы — новый разработчик, который видит фичу впервые.

• Что произойдёт, если данные ещё не загрузились?
• Что будет, если данных нет совсем?
• Что будет, если данных слишком много — список на 500 строк, заголовок на три абзаца?
• Как ведёт себя экран на узком мобильном и на широком десктопе?
• Что доступно с клавиатуры, а что только мышью?
• Какие тексты переводятся, а какие зашиты в код?
• Какие элементы кликабельны, а какие выглядят кликабельными, но не должны быть?
• Откуда берётся каждое число и каждый аватар — из API, из стора, из локального состояния?

Если на половину вопросов ответ «не знаю, спросим у бэка» — это нормально, но эти вопросы должны висеть на макете явно, а не всплывать на третий день разработки.

### Отдельный блок для AI-сборки

• Имена слоёв читаются как названия переменных?
• Имена вариантов компонента совпадают с пропсами, которые вы ожидаете в коде?
• В макете нет «мёртвых» скрытых слоёв, которые ассистент может вытащить наружу?
• Текстовые стили имеют осмысленные имена, а не style 14?

## Практический итог

Dev Mode не делает передачу автоматической — он делает её честной. Видно сразу, где макет — это система, а где красивая картинка. AI-ассистент только усиливает этот эффект: дисциплинированный файл превращается в рабочий контракт, неряшливый — в генератор странных PR.

Работающий процесс держится на трёх простых вещах: понятная структура файла, токены и компоненты вместо магических значений, явное описание поведения и граничных состояний. Всё остальное — детали, которые быстро доберёте по ходу. И главное — перестаньте проверять передачу по тому, задаёт ли разработчик вопросы. Проверяйте по тому, насколько собранный экран совпадает с тем, что вы нарисовали, без длинного чата посередине.