Figma Dev Mode: почему разработчики наконец перестали жаловаться на хендофф

Раньше передача макета в разработку выглядела примерно так. Дизайнер кидает ссылку на Figma в чат. Разработчик открывает, ищет нужный экран среди двадцати фреймов, наводится на отступ, видит «16» и пишет в чате «а это точно padding или margin?». Дизайнер отвечает «padding, наверное». Через два дня выкатывается фича, в которой кнопка стоит не там, цвет чуть-чуть другой, а тень вообще пропала.

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

## Почему хендофф ломался годами

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

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

Разработчик мыслит токенами, переменными, состояниями, breakpoints. Ему важно: какой именно цвет из дизайн-системы, какое имя у этого token, какой это компонент в коде, что считается финальной версией.

До Dev Mode оба смотрели в одно окно. Разработчик пробирался через «design-draft-v3-FINAL-вот-это-точно» фреймы, путался в неотвязанных стилях, тыкал в локальный hex вместо токена и в итоге переписывал значения руками. Каждый второй баг в верстке начинался словами «а я думал, тут вот это».

## Что реально поменялось с Dev Mode

Если коротко — у разработчика появился собственный режим работы с файлом, в котором:

• Видны только те фреймы, которые помечены как готовые к разработке (Ready for dev).
• Каждое значение по возможности показано как переменная или токен, а не как сырое число.
• Есть отдельные секции про статус, ссылку на задачу, ветку и связанный компонент в кодовой базе.
• Можно сравнить две версии фрейма и увидеть диф — что именно поменялось с прошлой выкатки.

Это звучит просто, но именно эти четыре вещи закрывают примерно весь старый список претензий. Разработчик больше не догадывается, что считается актуальным. Он не выковыривает «16px» из воздуха — он видит spacing/md. Он не спрашивает «а это новая иконка или просто черновик» — у фрейма есть статус.

## Сценарий: как теперь устроена передача фичи

Чтобы было предметно, вот как это выглядит в команде, где Dev Mode действительно прижился.

### Шаг 1. Дизайнер закрывает фичу

Дизайнер заканчивает экран, прогоняет себя по короткому внутреннему чеклисту:

• Все цвета и отступы — переменные, а не локальные значения
• Компоненты — из библиотеки, а не «нарисованные руками копии»
• Состояния (hover, disabled, loading, empty, error) — представлены, а не подразумеваются
• У фрейма выставлен статус Ready for dev
• К фрейму прикреплена ссылка на задачу в трекере

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

### Шаг 2. Разработчик открывает Dev Mode

Он видит только Ready-фреймы. Кликает в элемент — справа получает значения в виде токенов, размеры, ассеты, ссылку на компонент в Storybook (если настроена связь с кодовой базой). Скачивает только нужные ассеты, а не всю папку.

### Шаг 3. Возникает вопрос — комментарий прямо на элементе

И вот тут ломается старая привычка «спросить в чате». Комментарий ставится прямо на элементе, в треде остаётся история, дизайнер отвечает там же. Через месяц, когда кто-то третий придёт чинить баг, он увидит контекст, а не археологию из Slack.

## Анти-паттерны, которые сводят пользу Dev Mode к нулю

Сам по себе Dev Mode не дисциплинирует. Если команда продолжает работать как раньше, разработчик просто получит чуть более красивый интерфейс к тому же хаосу. Самые частые провалы:

• Никто не ставит статус Ready for dev. Разработчик снова не знает, что считать актуальным.
• Дизайнер красит «на глаз», а не токенами. В Dev Mode видны цифры вместо имён переменных — и весь смысл теряется.
• «Черновая» страница и «прод» лежат в одном файле без разметки. Dev Mode честно покажет всё, включая то, что вы рисовали в обед.
• Компоненты в Figma не совпадают с компонентами в коде по названиям. Разработчик каждый раз переводит «Button/Primary/Large» в <PrimaryButton size="lg"> вручную и ошибается.

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

## Короткий итог раздела

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

## Как понять, что у вас сейчас плохо с хендофом

Прежде чем включать Dev Mode и радоваться, что теперь «всё будет хорошо», полезно честно посмотреть на текущий файл глазами разработчика. Чаще всего диагностика занимает минут пятнадцать и больно бьёт по самооценке.

Откройте свой основной продуктовый файл и пройдитесь по пяти вопросам:

• Если я выключу все слои, кроме помеченных Ready for dev, останется ли хоть один экран?
• Сколько на типовом экране локальных значений цвета и отступа, которые не привязаны к переменной?
• Совпадают ли названия компонентов в Figma с тем, как они называются в коде?
• Понятно ли постороннему человеку, какой из трёх похожих фреймов — актуальный?
• Есть ли у каждого ключевого экрана состояния пустоты, ошибки и загрузки — или только «идеальный» вариант?

Если на большинство вопросов ответ «ну, как бы нет», у вас не проблема Dev Mode. У вас проблема гигиены файла, и никакой режим её не закроет.

## Рабочий процесс дизайнера: что меняется в макете

Dev Mode требует от дизайнера думать не только о картинке, но и о том, как фрейм будет читаться как спецификация. Это другой режим внимания.

### Структура файла

Минимум, который окупается почти сразу:

• Отдельная страница Production — только то, что уже в продукте или будет в ближайшем релизе.
• Отдельная страница In progress — то, над чем идёт активная работа, статус Draft или Ready for review.
• Отдельная Explorations — концепты, варианты, мудборды, всё, что разработчик видеть не должен.
• Archive — старые версии, чтобы не было соблазна держать их рядом с боевыми.

Dev Mode видит весь файл, но статусы и страницы позволяют отсечь шум. Главное правило — ни одного «финального» фрейма за пределами Production.

### Токены вместо магических чисел

Если радиус скругления у вас 6, 7 и 8 на трёх соседних карточках — это не «авторский почерк», это будущий тикет «почему у нас три разных радиуса». В Dev Mode такие расхождения видны мгновенно: разработчик кликает в элемент и видит сырое число вместо radius/sm. Любое сырое число — кандидат на токен либо на исправление.

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

### Состояния как часть макета, а не как «потом дорисуем»

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

Для каждого экрана с данными держите явные варианты:

• Загрузка (скелетон или спиннер — определитесь, что именно)
• Пустое состояние (нет данных у нового пользователя)
• Пустое состояние после фильтра (данные есть, но не нашлось ничего)
• Ошибка сети
• Ошибка валидации на уровне поля и на уровне формы
• Состояние «нет прав» или «функция недоступна на тарифе»

Если хотя бы два из этих пунктов отсутствуют, не помечайте фрейм Ready for dev. Серьёзно.

## Вопросы, которые стоит задавать на ревью макета

Перед тем как передать экран в разработку, прогоните себя или коллегу по короткому списку. Это не бюрократия, это страховка от переписок в духе «а как тут должно быть».

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

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

Когда команда впервые включает режим всерьёз, всплывает один и тот же набор грешков.

• Дубликаты компонентов. Две кнопки «Primary» в разных библиотеках, отличающиеся на пиксель. Разработчик не угадает, какую вы имели в виду.
• Оторванные инстансы. Компонент вроде из библиотеки, но кто-то отвязал и подкрасил. В Dev Mode это видно как «почти кнопка, но значения локальные».
• Скрытые слои с устаревшим контентом. Их не видно глазами, но они попадают в спецификацию и сбивают с толку.
• Auto layout «для красоты». Если отступы выставлены вручную поверх auto layout, разработчик получит противоречивые цифры и будет угадывать намерение.

## Короткий итог раздела

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

## Продвинутые сценарии: когда Dev Mode перестаёт быть просто инспектором

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

### Сценарий 1: дизайнер ведёт правки прямо по продакшен-коду

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

В продвинутом сценарии дизайнер открывает страницу в браузере, сравнивает с фреймом и фиксирует расхождения через комментарии прямо в Dev Mode. Не «кажется, отступы поехали», а «здесь должен быть spacing/md, в проде стоит 14». Разработчик получает не настроение, а конкретный диф.

### Сценарий 2: компонент в Figma связан с компонентом в коде

Dev Mode позволяет привязать к фрейму ссылку на код — на Storybook, на файл в репозитории, на страницу документации. Звучит мелко, но эффект ощутимый: разработчик не ищет, какой Button имелся в виду, он попадает на конкретный, с актуальными пропсами.

Что стоит привязывать:

• К каждому published-компоненту — ссылку на его Storybook-story.
• К каждой странице — ссылку на роут или на feature-флаг в админке.
• К сложному фрейму — ссылку на PR или тикет, в рамках которого его делают.

Это занимает у дизайнера минуты, а у разработчика экономит часы поиска.

### Сценарий 3: AI и MCP-ассистенты как читатели макета

Когда к Figma подключается ассистент через MCP или плагин, ситуация переворачивается: теперь макет читает не только человек, но и модель, которая на его основе генерирует разметку. И здесь все слабые места файла усиливаются.

Если у вас фрейм с тремя радиусами, человек спишет это на «дизайнерское чутьё». Модель добросовестно сгенерирует три разных значения и зафиксирует беспорядок в коде. Если слой называется Frame 482, модель напишет компонент Frame482. Если состояние пустого экрана нарисовано «на соседнем артборде без подписи», модель его просто не увидит.

Практические правила работы с AI-генерацией по макету:

• Перед генерацией убедитесь, что все значения — токены, а не сырые числа.
• Имена слоёв должны читаться как имена компонентов: CardProduct, ButtonPrimary, а не Group 12 copy.
• Скрытые слои, отвязанные инстансы и «черновые» дубли уберите — модель не понимает, что «вон тот фрейм слева — старый».
• Никогда не принимайте сгенерированный код без диффа против дизайн-системы: AI охотно изобретает токены, которых у вас нет.

AI не заменяет ревью макета. Он его жёстко наказывает за неаккуратность.

## Как проверять качество хендоффа

Не «макет красивый», а «по нему можно писать код, не задавая вопросов». Это разные критерии.

### Мини-аудит фрейма перед Ready for dev

• Все цвета и отступы — это переменные, а не сырые значения.
• Все используемые компоненты — из библиотеки, инстансы не отвязаны.
• Состояния (загрузка, пусто, ошибка, нет прав) присутствуют рядом.
• Имена слоёв осмысленные, без Frame, Group, copy 3.
• Привязаны ссылки на код или на Storybook там, где это уместно.
• Поведение текста и контейнеров при изменении длины описано или показано примером.
• Минимальная и максимальная ширина проверены явно.

Если по списку проходит меньше пяти пунктов — фрейм ещё не готов, как бы хорошо он ни выглядел.

### Метрика, которую видно глазами

Самый честный показатель — количество вопросов от разработчика в первый день после хендоффа. Если их ноль, файл в порядке. Если их десять, проблема не в разработчике.

## Как объяснить команде, что это не «дизайнер усложняет себе жизнь»

Чистый файл выглядит как лишняя работа ровно до момента, когда он начинает экономить чужое время. Аргументы, которые работают на ревью и в разговоре с менеджером:

• Каждый сырой пиксель в макете — это потенциальный тикет в бэклог визуальных багов.
• Каждый отвязанный инстанс — это будущий разговор «почему у нас две кнопки».
• Каждое отсутствующее состояние — это инцидент в проде, который обязательно произойдёт.
• Каждое осмысленное имя слоя — это минус минута разработчика и минус ошибка у AI-ассистента.

Это не перфекционизм. Это перенос работы из дорогой стадии (разработка, тестирование, фикс) в дешёвую (макет).

### Короткий итог раздела

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

## Анти-паттерны, которые ломают хендофф даже на хорошем макете

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

### «Финальный финал v3 (правки от Лены)»

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

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

### Дизайн «поверх» продакшена

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

В норме правки идут через отдельный фрейм, ветку или хотя бы аннотацию «here is what changed». Молчаливые правки в живой макет — это поломанное доверие, которое потом восстанавливается дольше, чем сама правка.

### Состояния спрятаны в компонент, который никто не видит

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

Состояния должны быть видны на холсте рядом с основным сценарием. Варианты в компоненте — это про переиспользование, а не про спецификацию.

### «Это же очевидно по макету»

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

Если поведение можно показать вторым фреймом или описать одной строкой в аннотации — лучше показать и описать. Любое «и так понятно» — это будущий вопрос в чате в 23:40.

### Аннотации вместо системы

Обратная крайность: разработчику передают фрейм, обвешанный двадцатью комментариями про отступы, цвета и поведение. Это значит, что система не работает: правила, которые должны жить в библиотеке и токенах, переехали в текстовые подписи. На следующем экране их придётся писать заново.

Аннотация — это для специфики этого экрана. Для всего остального есть гайдлайны, токены и компоненты.

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

Эти вопросы стоит задавать себе или коллеге на дизайн-ревью — до того, как фрейм попадёт к разработчику. Они короткие, но за ними обычно вылезает всё, что не доделано.

### Про сам макет

• Можно ли по этому фрейму собрать экран, не открывая Slack?
• Если убрать автора файла из доступа — останется ли макет понятным?
• Какие три состояния этого экрана я не нарисовал и почему?
• Что будет, если текст в этом блоке станет в три раза длиннее? А в один символ?
• Какие значения здесь — токены, а какие я набил руками «на глаз»?

### Про связь с кодом

• Каждый компонент здесь существует в кодовой базе под тем же именем?
• Если разработчик кликнет в Dev Mode, он попадёт в Storybook, а не в пустоту?
• Где в этом макете я переизобрёл то, что уже есть в системе?

### Про команду

• Кто-то кроме меня смотрел на этот фрейм глазами разработчика?
• Если завтра я в отпуске, разработчик задаст вопросы — кому?
• Что в этом макете решено, а что — «обсудим по ходу»? Второе обычно превращается в баги.

## Финальный чеклист перед Ready for dev

Не дублирует мини-аудит выше — это шаг шире, про процесс, а не про сам фрейм.

• Старые версии экрана убраны со страницы или явно помечены как архив.
• Статус Ready for dev стоит ровно на одном варианте.
• Все правки после первого хендоффа задокументированы — комментарием, аннотацией или сообщением в тикете.
• Спорные решения зафиксированы письменно, а не «договорились голосом».
• Разработчик, который будет это делать, в курсе, что фрейм готов, — а не узнаёт об этом из case-by-case переписки.
• У дизайнера есть слот в календаре под вопросы по этой задаче в ближайшие дни.

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

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

Dev Mode перестал быть отдельной болью не потому, что Figma добавила волшебную кнопку. Он перестал быть болью там, где команда поняла простую вещь: качество хендоффа — это не свойство инструмента, а свойство привычки.

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

Инструмент при этом помогает: связывает макет с кодом, показывает токены, отдаёт переменные в нужном формате, открывает дорогу AI-ассистентам. Но он усиливает ровно то, что в файле уже есть. Аккуратный файл становится в Dev Mode прозрачным. Неаккуратный — становится прозрачно неаккуратным, и это видно всем: и разработчику, и модели, и тимлиду на ретро.

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

Выбор делается не на стадии передачи. Он делается каждый раз, когда вы решаете, набить ли число руками или взять переменную.