Почему интерфейс в коде выглядит не так, как в Figma

Помню, открыл как-то готовый интерфейс после разработки. Формально всё на месте — но выглядит не так, как в Figma. Кнопка чуть выше. Отступ между блоками другой. Карточки разной высоты. Где-то радиус 8 px, где-то 10. Текст внезапно переносится иначе.

И вроде бы дизайнер передал макеты, разработчик их реализовал. Но проблема часто не в самом коде.

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

Макет — это не картинка

Одна из распространённых ошибок — воспринимать Figma-макет как картинку, которую нужно визуально воспроизвести. Посмотреть на экран → оценить расстояние → подобрать похожий размер → повторить.

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

• десятки компонентов;
• разные состояния;
• несколько ролей пользователей;
• адаптивные версии;
• повторяющиеся паттерны;
• разные типы контента;
• переменные значения;
• сложные пользовательские сценарии.

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

Что можно увидеть за пределами пикселей

Хорошо подготовленный макет содержит гораздо больше информации, чем просто положение элементов. В Figma можно определить:

• структуру Auto Layout?Инструмент Figma, который описывает, как элементы ведут себя внутри контейнера: как распределяются, как растягиваются, как реагируют на изменение контента.;
• расстояния между элементами;
• размеры и ограничения;
• Variables?Переменные Figma: цвета, отступы, радиусы, типографика. Хранятся в одном месте — и меняются сразу во всём файле.;
• значения цветов и типографики;
• компоненты и их свойства;
• состояния;
• взаимосвязь повторяющихся компонентов;
• поведение элементов внутри контейнера.

Например, если между двумя элементами используется определённый spacing?Система отступов в интерфейсе. Обычно строится по шагу: 4, 8, 12, 16, 24, 32 px. Не «на глаз», а по единой шкале., это не просто визуальное расстояние. Это может быть частью общей системы.

Сегодня между элементами 16 px, завтра появится новый экран — и этот же принцип должен продолжить работать там. Поэтому мне важно, чтобы разработчик видел не только результат, но и логику, которая за ним стоит.

Я документирую интерфейс прямо внутри Figma

В своих рабочих файлах я стараюсь не оставлять систему понятной только самому себе. Внутри Figma я отдельно документирую компоненты и их состояния: показываю варианты, подписываю их и объясняю, в каких сценариях и как они должны работать.

Если компонент имеет несколько состояний, я стараюсь не ограничиваться просто набором вариантов. Например, можно показать:

Default → Hover → Focus → Disabled → Loading → Error → Success

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

Я могу прямо внутри Figma развернуть такие состояния и показать их поведение, чтобы разработчику не приходилось восстанавливать логику по одному статичному экрану. Для меня это и есть часть handoff?Процесс передачи макетов из дизайна в разработку. Хороший handoff включает не только экраны, но и правила, состояния, спецификации и ответы на вопросы.. Не просто:

«Вот компонент».

А:

«Вот компонент, вот его состояния, вот правила их использования и вот как он ведёт себя в сценарии».

Даже названия слоёв имеют значение

Есть ещё одна мелочь, которая кажется незначительной, пока не открываешь огромный Figma-файл. Названия слоёв. Frame 1247, Group 32, Rectangle 18 и Text 94 могут существовать технически, но совершенно не помогают понять структуру интерфейса.

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

Frame 1247
Frame 1248
Group 39

гораздо понятнее увидеть:

Header
SearchField
ProductCard
FilterPanel
EmptyState
CheckoutSummary

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

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

Когда разработка начинает делать «на глаз»

У меня были ситуации, когда отдельные значения в интерфейсе фактически подбирались визуально. Этот отступ вроде 16. Здесь, наверное, 20. Этот блок чуть-чуть выше. А здесь сделаем как на соседнем экране.

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

А после нескольких итераций разработки дизайнеру приходится снова открывать Figma и объяснять, почему конкретный элемент должен вести себя иначе. В результате команда начинает исправлять не продукт, а последствия отсутствия общего правила.

Поэтому я начинаю с системы

Я не рассматриваю дизайн-систему как красивый UI-kit, который нужно собрать в конце проекта. Для меня она начинается гораздо раньше. Сначала появляются правила. Потом Variables и базовые значения. Затем компоненты. После этого — состояния, варианты использования и конкретные интерфейсы.

Получается примерно такая логика:

Правило → Variable → компонент → состояние → экран

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

Auto Layout — это тоже часть handoff

Auto Layout часто воспринимают просто как удобный инструмент для ускорения работы в Figma. Но для меня он ещё и показывает, как интерфейс должен вести себя при изменении контента.

Если карточка увеличилась из-за более длинного текста, что происходит? Если кнопка стала шире? Если в строке появился ещё один элемент? Если экран стал уже?

Статичный макет может показать только один конкретный результат. Auto Layout позволяет описать часть поведения системы. И это особенно важно для адаптивных интерфейсов.

Хороший handoff должен отвечать не только на вопрос «как это выглядит?», но и на вопрос «что должно произойти, если условия изменятся?»

Figma можно читать как структуру

Есть ещё один интересный момент. Современные инструменты позволяют разработчику смотреть на Figma гораздо глубже, чем просто через визуальный макет.

Например, Dev Mode?Режим Figma для разработчиков: показывает размеры, отступы, переменные, экспорт ресурсов и структуру выбранного фрейма. в Figma позволяет выбрать нужный фрейм и посмотреть его структуру и параметры. Это полезно именно потому, что снимает часть необходимости что-то угадывать. Можно посмотреть, как устроен выбранный элемент, какие у него параметры и из чего состоит конкретный фрейм.

Для меня это хороший пример того, куда вообще движется handoff: от передачи картинки → к передаче структуры. Чем сложнее продукт, тем важнее этот переход.

Но хороший handoff не заменяет коммуникацию

При этом я не считаю, что достаточно просто идеально настроить Figma и отправить ссылку разработчику. Некоторые вещи невозможно полностью выразить одним макетом. Например:

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

Поэтому хороший handoff для меня — это не «всё объяснить в Figma и больше ни с кем не разговаривать». Это создать понятную основу для разговора между дизайном и разработкой. Когда дизайнер может показать не только экран, но и систему, а разработчик понимает, почему эта система устроена именно так, вопросов становится значительно меньше.

Где особенно заметна разница

Чем сложнее продукт, тем дороже становятся маленькие расхождения. В простом лендинге разница между 16 и 20 px может вообще никого не волновать. В CRM, SaaS-платформе, личном кабинете или B2B-системе таких решений могут быть сотни.

И если каждый экран собирается немного по-разному, визуальная система начинает разрушаться. Поэтому в сложных интерфейсах я стараюсь проектировать не отдельные экраны, а систему, из которой эти экраны собираются. Это касается не только компонентов, но и:

• spacing;
• типографики;
• цветов;
• состояний;
• сетки;
• адаптива;
• поведения элементов;
• правил использования.

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

Что в итоге получает разработка

Хороший дизайн-файл не должен заставлять разработчика угадывать. Он должен помогать быстро ответить на вопросы:

• Что это?
• Из чего состоит?
• Какие у него состояния?
• Как меняется при изменении контента?
• Какие значения используются?
• Что происходит на другой ширине?
• Это отдельный элемент или часть существующего компонента?

Чем больше ответов уже заложено в системе, тем меньше решений приходится принимать заново. И тем меньше вероятность, что одинаковые вещи будут реализованы пятью разными способами.

Дизайн-система — это договорённость

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

Figma в этом случае становится не просто инструментом рисования. Она хранит часть правил продукта. Variables задают значения. Auto Layout описывает поведение. Компоненты фиксируют повторяемые решения. Состояния показывают варианты поведения. Названия слоёв делают структуру читаемой. Документация объясняет логику. А handoff связывает всё это с реализацией.

И тогда разработка уже не пытается воспроизвести картинку. Она реализует систему.

Хороший интерфейс должен переживать передачу в код

Для меня хороший результат — это не когда макет в Figma выглядит идеально. Хороший результат — когда после реализации продукт продолжает выглядеть и работать как единая система.

Без постоянного:

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

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