Вёрстка сайта по макету Figma: этапы и частые ошибки

01

С чего начинается вёрстка сайта по макету

Вёрстка сайта по макету начинается не с HTML и CSS, а с проверки исходных решений. Figma показывает внешний вид интерфейса, но не всегда отвечает на вопросы, которые нужны разработчику: что происходит с меню на планшете, как выглядит ошибка в форме, сколько строк допустимо в карточке товара и какой блок редактор сможет изменить в 1С-Битрикс. Если эти условия не зафиксировать, команда будет принимать решения по ходу работы — и согласованный дизайн начнёт расходиться с готовым сайтом.

В типовом проекте ICONICA перед стартом составляют карту экранов: главная, разделы, детальная страница, поиск, 404, личный кабинет или оформление заказа — если они входят в задачу. Затем отмечают повторяющиеся компоненты: шапку, футер, карточки, кнопки, форму, табы, модальные окна. Один компонент должен иметь единые размеры, отступы и состояния, а не отдельную реализацию на каждой странице.

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

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

03

Что передать из Figma в разработку

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

Проверьте права доступа к файлу и порядок версий. В ссылке должен быть доступ к финальным экранам, а не к рабочей доске с десятками вариантов. Если в макете есть комментарии с решениями, соберите их в отдельный список: комментарий в Figma легко закрыть, но требование при этом не исчезает. Для иконок, фотографий и иллюстраций определите источник и формат: SVG подходит для интерфейсной графики, а крупные фото после оптимизации обычно отдают в WebP.

В проектах на 1С-Битрикс полезно сразу маркировать динамические зоны. Редактору нужно понимать, где будут менять заголовок, изображение, SEO-поля, цену или список преимуществ. Требования к шаблонам и компонентам можно сверить с документацией разработчика 1С-Битрикс, но структуру контента всё равно определяет задача бизнеса.

04

Сетка, типографика и изображения: где макет чаще всего расходится с сайтом

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

Шрифт нельзя проверять только по названию семейства. Один неверно подключённый weight меняет ширину слов и высоту строк; кнопка переносится, карточки становятся разной высоты, а первый экран перестаёт совпадать с макетом. Изображение тоже является частью логики: нужно определить его соотношение сторон, кадрирование, минимальный размер и поведение на маленьком экране.

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

05

Адаптив — это сценарий, а не уменьшенная десктопная версия

Макет на 1440 пикселей не определяет, как сайт поведёт себя на 1024, 768 или 375 пикселях. На мобильном устройстве пользователь читает страницу в другом порядке, нажимает пальцем, использует экранную клавиатуру и часто открывает меню в один клик. Поэтому задача адаптива — сохранить смысл сценария и удобство действия, а не просто уместить все блоки в узкую колонку.

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

Мини-кейс из практики: в макете корпоративного сайта форма на десктопе стояла рядом с преимуществами. На мобильном экране порядок блоков определял конверсию: сначала короткое объяснение предложения, затем преимущества и форма. Команда зафиксировала этот порядок до вёрстки, проверила его на реальном смартфоне и не получила «случайную» перестановку элементов после запуска.

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

06

Как принять вёрстку до интеграции и запуска

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

Для сайта на Битрикс добавьте административную проверку. Создайте тестовый элемент инфоблока с длинным названием и пустой картинкой, измените описание, замените изображение. Страница должна сохранить структуру, а редактор — не обращаться к разработчику ради каждого изменения текста. Если форма является частью сценария заявок, после интеграции проверьте обязательные поля, источник, UTM и создание лида или сделки в CRM.

Сравнение через наложение скриншотов полезно для отступов, но не заменяет функциональные тесты. Зафиксируйте замечания списком с URL, шириной экрана, шагами воспроизведения и ожидаемым результатом. Тогда подрядчик не будет интерпретировать фразу «на мобильном всё съехало».

1. 1

   Проверьте маршруты. Откройте все страницы, ссылки, хлебные крошки, кнопки и состояния 404 без ручного ввода адресов.

2. 2

   Сверьте макет. Сравните контейнеры, интервалы, типографику, изображения и видимые границы блоков на контрольных ширинах.

3. 3

   Пройдите интерактив. Проверьте меню, модальные окна, табы, слайдеры, формы и сообщения об ошибке с клавиатуры и мышью.

4. 4

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

5. 5

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

07

Частые ошибки при вёрстке из Figma

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

Третья ошибка касается «магических» значений в CSS: отдельные отрицательные отступы и жёсткие высоты помогают быстро повторить один экран, но ломают компонент при смене контента. Четвёртая — заменить смысловую HTML-структуру набором кликабельных div. Такой интерфейс сложнее поддерживать, тестировать и использовать с клавиатуры.

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

08

Когда достаточно вёрстки, а когда нужен полный фронтенд

Если задача ограничена статичными страницами или стандартными шаблонами CMS, достаточно качественной HTML/CSS-вёрстки с небольшим JavaScript. Но сложный личный кабинет, калькулятор, фильтрация без перезагрузки, многошаговая анкета или обмен с внешним API требуют отдельной оценки фронтенда и бэкенда. Попытка назвать такую работу «просто вёрсткой» обычно приводит к неверному сроку и неполному ТЗ.

Руководителю проекта стоит разделить смету на слои: интерфейс по макету, интеграция с 1С-Битрикс, серверная логика, CRM и аналитика, тестирование. Тогда изменение одного слоя видно в плане работ. Например, новая форма может не менять дизайн, но потребовать полей в CRM, валидации телефона, согласия на обработку данных и событий для аналитики.

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

09

Что решить перед началом работ

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

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

Подключайте подрядчика на этапе, когда макет уже согласован по смыслу, но ещё можно менять спорные решения без переделки кода. Если интерфейс связан с каталогом, личным кабинетом, CRM или нестандартными компонентами Битрикс, попросите предварительно описать технические зависимости и подготовить план тестирования. Это даёт понятный объём работ и снижает риск дорогостоящих исправлений после запуска.