Описываем логику сайта и готовим ТЗ для верстальщика

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

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

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

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

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

В студии ONE PAGE подготовка ТЗ для верстальщика входит в работу дизайнера. Этот навык полезен и на фрилансе: заказчик получает более полный результат, а количество вопросов и разночтений на этапе реализации сокращается.

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

В рамках курса отдельные документы и таблицы для ТЗ не создаём. Все пояснения размещаем непосредственно в Figma через комментарии.

Для материалов, предназначенных верстальщику, можно создать отдельную страницу, например «Вёрстка + ТЗ». На ней располагаются актуальные макеты, необходимые состояния элементов и комментарии к их поведению.

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

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

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

Также важно показать состояния интерфейсных элементов:

• хедера при скролле;
• кнопок при наведении;
• полей ввода;
• форм;
• бургер-меню;
• поп-апов;
• слайдеров;
• других интерактивных элементов.

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

Одна из основных задач ТЗ — объяснить, что должно происходить после взаимодействия пользователя с элементом.

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

При этом лучше указывать не только номер блока, но и его название. Порядок секций в проекте может измениться, а формулировка «скролл к блоку „Ассортимент“» останется однозначной.

Для ссылок и карточек также указываем, открывается ли целевая страница в текущей или новой вкладке.

Если хедер закрепляется при прокрутке страницы, это необходимо отдельно отметить.

Если его внешний вид при скролле меняется, показываем соответствующее состояние рядом с основным макетом.

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

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

Для повторяющихся кнопок не нужно каждый раз создавать отдельное пояснение.

Можно один раз показать Normal и Hover, добавить необходимые варианты в компоненты или UI Kit и в комментарии указать, что такое поведение распространяется на все аналогичные кнопки.

Для полей ввода при необходимости показываем состояния:

• обычное;
• активное;
• заполненное;
• с ошибкой.

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

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

Не каждую анимацию нужно самостоятельно моделировать в Figma.

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

Например:

• плавное появление текста при скролле;
• анимация кнопки;
• смена слайдов;
• фиксация секции во время прокрутки;
• последовательное наложение карточек.

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

Для слайдера недостаточно показать только первый экран.

Верстальщику нужно передать все изображения и описать механику переключения.

Например, можно указать:

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

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

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

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

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

В таком случае недостаточно написать «области подсвечиваются». Лучше рядом показать внешний вид активного состояния и указать названия регионов, если это требуется для реализации.

То же относится к обычным картам: указываем адреса и точки, которые должны отображаться.

Не нужно заставлять верстальщика самостоятельно искать информацию, которую дизайнер или заказчик уже может предоставить.

К моменту передачи макета не все материалы обязательно будут получены от заказчика.

В проекте может временно отсутствовать:

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

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

Так верстальщик понимает, что отсутствие материала предусмотрено и к этому месту ещё нужно будет вернуться.

ТЗ должно быть подробным, но не перегруженным.

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

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

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

Передача ТЗ не означает, что участие дизайнера в проекте полностью закончено.

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

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

Главная задача ТЗ — не предусмотреть абсолютно всё до последнего пикселя, а сделать логику проекта максимально понятной и сократить количество догадок на этапе разработки.

Домашнее задание