Figma → код: метрики дизайн-хэндоффа
Fintech-команда, с которой мы работаем, отгрузила одну 400-строчную фичу четыре раза. Figma-файл обновился во вторник. Разработчик взял в среду. Дизайн переоткрыл файл в четверг утром, чтобы «уточнить spacing», и ещё раз в пятницу вечером ради «ещё одной микро-интеракции». Фича уехала в понедельник. Потом инженер два дня чинил visual regressions, пойманные PM-ом после релиза. Итого 7 инженерных дней. Чистого нового кода — 400 строк. Handoff убил больше, чем сама работа.
Разговор про «Figma → код» обычно про инструменты: Zeplin, Figma Dev Mode, Locofy, Visual Copilot. Ни один из них не чинит реальную проблему: handoff дизайн→разработка — это пробел в измерении, прячущийся в пробеле процесса. Определим метрики, которые реально предсказывают хороший handoff, как их мерить без оверхеда, и где выбор инструмента важен (иногда), а где нет (обычно).
{/* truncate */}
Проблема: дизайн и инженерия меряют разное
Дизайн меряет завершённость («спека готова»). Инженерия меряет throughput («фича отгружена»). Никто не меряет сам handoff — момент между «дизайн готов» и «инженерия задеплоила» — там и прячется цена.
Работа Gloria Mark (UC Irvine) про переключение контекста применяется здесь точечно: каждый раз, когда Figma-спека меняется после старта реализации, разработчик платит 23-минутный refocus tax на следующей сессии. Умножьте на три цикла изменений — lead time фичи удваивается. Отчёт Figma 2024: в среднем спека получает 4.3 правки после старта разработки — это не ровно 4.3 цикла ревизий (большинство минорные), но хватает, чтобы в хотя бы одной итерации заставить переделать и перепроверить.
Шесть стадий handoff — только две из них про «писать код». Четыре остальные — где команды либо координируются, либо жгут время.
5 метрик handoff, которые реально важны
По убыванию предсказательной силы для качества и скорости:
1. Spec Stability Rate (SSR)
Определение: процент дизайн-спек, которые НЕ редактируются между dev-start и dev-complete.
Почему важно: главный сигнал здоровья handoff. Высокий SSR — инженерия бежит по спеке. Низкий — инженерия бегает по кругу.
| SSR | Что означает |
|---|---|
| >85% | Здорово. Дизайн лочится до handoff. |
| 60-85% | Нормально для growth-стадии с быстрой продуктовой итерацией. |
| <60% | Дизайн ещё торгуется в бэклоге разработчика. Hard-stop проблема. |
Мерить — экспортом version history Figma против timestamp dev-start. На enterprise Figma — это API-вызов. Без — ручная выборка (20 фич, метки dev-start и dev-complete, посчитать правки между).
2. Visual Diff Rework
Определение: число «visual polish» коммитов после первой зашипенной версии, делённое на общее число коммитов фичи.
Почему важно: ловит переделку из-за неясной спеки, не настоящие итерации. Фича на 12 коммитов с 2 polish — норма. С 6 polish — спека была недоописана.
| Visual diff rework | Интерпретация |
|---|---|
| <15% | Спека ясна, пиксельная работа минимальна |
| 15-30% | Немного design-dev туда-сюда |
| >30% | Либо спека мутная, либо коммуникация сломалась |
3. Inspect-to-First-Commit (IFT)
Определение: медианное время между открытием Figma в Dev Mode и первым коммитом на feature-branch.
Почему важно: прокси для стоимости понимания спеки. Если 4+ часа от инспекта до первого коммита — спека не inspect-ready: нет токенов, несогласованные имена компонентов, состояний нет.
Цель: <90 минут для фич средней сложности. Более 3 часов — смолл процесса.
4. Component Adoption Rate
Определение: какой процент UI зашипенной фичи собран из компонентов дизайн-системы vs bespoke-код.
Почему важно: высокое adoption = дизайн-система работает; низкое = либо библиотека неполная, либо разработчики не знают про неё. Обе проблемы решаемы, но нужно о них знать.
Зрелые команды целят >70%. Команды без дизайн-системы (или со старой) часто показывают <30%.
5. Design-Origin Defect Rate
Определение: доля багов за первые 30 дней после релиза, которые трассируются к неясности дизайна, а не к багам кода.
Почему важно: design-origin дефекты — самые дорогие: требуют и переделки спеки, и работы дева, часто с эскалацией PM. Команда выше 20% design-origin не получает ценности от дизайн-процесса.
Как измерять без оверхеда
Три варианта по нарастанию сложности:
Вариант A — аудит по календарю (2 недели, без тулинга). 10 зашипенных фич. На каждую:
- Figma timestamp «last edited» vs PR open timestamp
- Visual polish коммиты в PR
- Время открытия Dev Mode из Figma Activity log (если доступен)
В spreadsheet. Посчитать 5 метрик. Этого хватит откалиброваться.
Вариант B — CI-хук (один спринт на настройку). Теги на коммитах: [design], [feature], [polish]. Простой CI-парсер считает visual diff rework автоматически.
Вариант C — полная телеметрия (постоянно). Связать Figma-метаданные с Git-событиями. Большинство команд это переинженерит. Вариант B даёт 80% ценности.
6-шаговый фреймворк handoff
Шаг 1 — Дизайн лочится до старта dev
«Залочено» — это явный Figma branch tag, не сообщение в Slack. Для любого изменения после лока открывается новая ветка {feature}-v2. Инженерия работает с залоченной, не с main-файлом.
Шаг 2 — Спека включает состояния, которые забыла дизайн-система
Loading, empty, error, skeleton, keyboard focus, reduced-motion, RTL, overflow длинной строки. Figma Design Systems Report 2024: 71% дизайн-систем не покрывают задокументированно минимум 3 из этих состояний — разработчики изобретают их прямо в коде.
Шаг 3 — Разработчик инспектит ДО финальной спеки
Парадокс: включите инженерию в дизайн-ревью ДО лока. 20-минутная проверка feasibility ловит 80% разговоров «эта анимация не работает на Android», которые иначе происходят в code review.
Шаг 4 — Первый коммит в пределах 90 минут после inspect
Если нельзя начать кодить за 90 минут — спека не готова. Возврат к дизайну. Правило звучит жёстко; на практике это сразу всплывает «нет состояний», а не через три дня.
Шаг 5 — Visual diff с дизайном, не только инженерией
До merge дизайн смотрит PR preview vs Figma-спека. Это момент поймать visual diff, не после релиза. Chromatic, Percy, Figma Dev Mode — помогают; встреча важнее инструмента.
Шаг 6 — Пост-релиз ретро с тегом источника дефекта
Каждый баг первых 30 дней — тег design-origin, code-origin, product-origin. Это питает метрику 5 и даёт данные следующему ретро.
Где тулинг реально помогает и где нет
Инструменты закрывают шаг 4 (inspect) и шаг 5 (visual diff) хорошо. Инструменты не чинят шаги 1, 2, 3, 6 — это процессные решения. Купить Figma Dev Mode без enforcement lock-протокола (шаг 1) — это $15/user/мес за симптом.
Наш взгляд на ландшафт 2026:
| Инструмент | Решает | Не решает |
|---|---|---|
| Figma Dev Mode | Fidelity инспекта, экспорт токенов | Стабильность спеки |
| Zeplin | Инспект + экспорт ассетов | Стабильность спеки |
| Locofy / Visual Copilot / Builder.io | Первый черновик кода | Выравнивание с компонентной системой |
| Chromatic / Percy | Visual regression в CI | Upstream-изменения дизайна |
| Storybook | Каталог компонентов, видимость для dev | Adoption продуктовыми командами |
Контринтуитивно: ни один инструмент не делает команду с плохим процессом хорошей. Каждый инструмент делает команду с хорошим процессом быстрее. Если SSR = 45%, внедрение Figma Dev Mode это не починит.
Где вписывается PanDev Metrics
Два узких, но полезных применения:
Измерение time-to-first-commit. Мы видим IDE-опены на ветках — можем детектить момент, когда разработчик начал работать с feature-веткой, независимо от self-report. Свяжите с Figma «inspect» событием (Figma Enterprise экспортит), и IFT (метрика 3) становится дашбордом, а не таблицей.
Классификация polish-коммитов. Наша Git-интеграция категоризирует коммиты; простое правило («коммиты после первого deploy, трогающие только CSS/styles/design-token файлы») извлекает visual diff rework автоматически. Не нужна идеальная классификация — направленной верности достаточно.
Команды, которые это меряют, показывают ~40% снижение ср. lead time фич за 6 месяцев — не потому что кодить стали быстрее, а потому что переделок стало меньше. Это согласуется с нашим исследованием переключения контекста — 40% восстановления lead time приходят от удаления переключений, не от скорости печати. По стороне измерения см. разбор lead time на 4 стадии.
Честный лимит
Мы видим инженерную сторону handoff чисто — IDE-телеметрия, Git, PR-лайфсайкл. У нас нет first-party телеметрии внутри Figma; SSR требует Figma-API-интеграции, которую большинство клиентов не настраивают. Числа по Figma-правкам — из публичного ресёрча Figma, не нашего. Если серьёзно трекать — комбинируйте нашу инженерную сторону с Figma-данными; по отдельности — неполно.
Ещё: классификация design-origin дефектов субъективна. Два PM разойдутся, design-origin ли несоответствие rounded-corner или code-origin. Трекайте, но не стройте scoreboard.
Самый жёсткий тезис
Handoff дизайн↔инженерия — не проблема тулинга; это проблема контракта. Команды, определяющие, что значит «дизайн готов» — явно, с state-чеклистом и lock-механизмом — обгоняют команды с лучшими инструментами и мутным процессом. Компании с самым коротким lead time не используют самые модные плагины. Они используют 6-пунктный чеклист, не менявшийся два года.
По теме
- Переключение контекста убивает продуктивность — почему правки спеки — скрытый налог
- Lead Time: разбор на 4 стадии — где handoff-время сидит в DORA lead time
- Code Review Checklist 2026 — шаг ревью, где visual diff ловит проблемы
- Внешнее: Figma 2024 Design Systems Report — adoption и покрытие состояний
- Внешнее: Gloria Mark, Attention Span (2023) — базовое 23-минутное переключение