Проблема handoff-а
Год назад типичный путь экрана выглядел так: дизайнер делает 4 итерации в Figma, отдаёт фронтенду, фронтенд пишет первую версию, дизайнер находит 14 несоответствий, фронтенд правит, цикл повторяется ещё дважды. Итого — 9 часов работы вместо 3.
Что мы изменили: design tokens как источник истины
Мы перестали проектировать «значения». Мы проектируем токены. В Figma — переменные. В коде — CSS custom properties. Когда дизайнер меняет `--color-accent` с #b8ff00 на #c5ff00, фронтенд узнаёт об этом мгновенно — потому что значение читается из одной и той же таблицы. Не «синхронизация», а единый источник.
/* tokens.css — то же самое, что и в Figma Variables */
@theme {
--color-accent: #c5ff00;
--color-accent-dim: #9ec900;
--space-card: 1.5rem;
--radius-sm: 4px;
--ease-out-expo: cubic-bezier(0.22, 1, 0.36, 1);
}Правило: ноль ad-hoc значений в коде
В нашем линтере есть собственное правило: если фронтенд пишет `margin: 13px`, build падает. 13px нет в токенах. Хочешь 13px — добавь токен или используй ближайший. Это очень злая политика, но она убила 80% дизайн-багов.
- ▍Spacing — только из 4px шкалы
- ▍Color — только из tokens.css
- ▍Easing — только signature ease (есть 3 варианта, не больше)
- ▍Radius — четыре значения, дальше — отказать
Компонент-первая разработка
Когда дизайнер заканчивает экран, он не отдаёт «экран». Он отдаёт список компонентов. Фронтенд собирает компоненты в Storybook, валидирует с дизайнером, и только потом собирает экран. Это +1 этап, но он экономит 6 часов на проекте средней сложности — потому что компонент проверен один раз и работает везде.
«Хороший handoff — это когда фронтенд может собрать экран без вопросов, а дизайнер может ревьюить код, не открывая код.»
Результат
От финального экрана в Figma до production-merge — в среднем 3 часа против 9 раньше. Дизайн-багов в QA — 2 в неделю против 14. Самое главное — дизайнер и фронтенд перестали конфликтовать. Они теперь спорят о токенах, а не о пикселях.