Вёрстка макета

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

Мы призываем организовывать структуру макета таким образом, чтобы она была похожа на html-вёрстку. Такой подход помогает:

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

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

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

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

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

По умолчанию у элементов нет отступов внутри и снаружи, но их можно настроить. Для этого есть специальные css-атрибуты:

• Padding — это отступ от контента до края блока.
• Border — обводка.
• Margin — отступы до соседних элементов.

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

При вёрстке макета учитывайте эти принципы: используйте автолейауты (аналог padding и margin) и констрейнсы. Это поможет разработчику понять задумку дизайнера и быстрее воспроизвести вёрстку макета средствами html и css.

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

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

А здесь, что перед нами не просто картинка, а аватарка:

Задавайте размеры элементам, чтобы показать, как они ведут себя при изменении контента. Например:

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

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

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

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

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

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

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

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

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

Потрогать этот и другие примеры можно в специальном файле Фигмы.

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

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

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