Как дизайнеру подготовить макет к верстке

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

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

Порядок в слоях

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

Размеры

• Дробных размеров и отступов не должно быть, чтобы разработчик точно понимал, сколько пикселей должно быть. Чтобы избавиться от дробных значений, используйте в фигме плагин «Pixel Perfect».

Текст

• Задавайте корректные размеры текстовых слоев, не делайте пустую область внизу текста или пересекающиеся края текстовых слоев. Разработчик проверяет расстояние между объектами, зажимая Alt и, в случае пустой области под текстом внутри рамки слоя или при пересекающихся краях, он не сможет определить корректный отступ. Опция текста Auto Height решит эту проблему. Используйте Auto layout для создания текстовых блоков.

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

• Чтобы было понятно, сколько колонок занимает текст, подгоняйте ширину текстового слоя под сетку, но еще лучше используйте Auto layout.

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

• Оставляйте разработчику шрифты, чтобы он не искал их сам в интернете.

Отступы

• Создайте систему отступов и придерживайтесь ее.

• Стремитесь делать элементы размеров, кратных сетке, которую вы используете. Это избавит разработчика от необходимости вручную измерять отступы. Опять же, чтобы упростить работу себе, используйте Auto layout.

Компоненты

• Собирайте компоненты в библиотеку. Создайте отдельный фрейм, а еще лучше страницу, куда поместите все компоненты.

• Называйте компоненты согласно их состояниям, в идеале давайте им такие же названия, как в HTML/CSS. Укажите в названии вид, размер, состояние и другие параметры.

• Сделайте таблицу состояний, это будет максимально подробно и сократит вероятность совершить ошибку.

Иллюстрации и пиктограммы

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

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

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

• Растровые изображения лучше передавать в формате WEBP, они меньше весят.

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

• Называйте иллюстрации и пиктограммы корректно: используйте латиницу, не пишите латиницей по-русски, вместо пробелов используйте дефисы и нижние подчеркивания. Для разных типов контента используйте разные обозначения, префиксом ic обозначайте иконки, ill — иллюстрации, pic — фото.

Документация

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

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

• UI-кит — это стайл-гайд плюс компоненты со всеми состояниями.

• Дизайн-ситема — содержит в себе, помимо информации из двух предыдущих видов документации, все сценарии пользователя при взаимодействии с продуктом.

Выводы:

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