Верстка макета
В продуктовой разработке важно не только то, как выглядит дизайн, но и как организован сам макет. Мы призываем структурировать элементы макета как в html-верстке, повторяющиеся сущности превращать в компоненты, использовать семантические название слоев и фреймов. Такой подход помогает:
- Системно мыслить. Лучше продумывать детали реализации и краевые случаи ещё на этапе дизайна.
-
Ускорять разработку. Разработчик видит закономерности и иерархию сущностей. Это уменьшает количество ошибок на этапе разработки и количество правок при тестировании.
-
Сокращать текстовые описания. Самодокументируемый* макет требует меньше пояснений и комментариев на полях.
Самодокументируемым разработчики называют код настолько понятный, что к нему не нужны дополнительные комментарии. Здесь мы применили этот термин к макетам.
-
Дорабатывать дизайн в будущем. Легче поддерживать и дорабатывать макет, особенно когда дизайнеров в команде несколько.
-
Снижать нагрузку на компьютер. «Лёгкие» макеты быстрее загружаются, в них быстрее сохраняются изменения.
Блочная модель
Html-вёрстка имеет блочную структуру: все элементы — это прямоугольные контейнеры, идущие в потоке друг за другом. Они могут располагаться по вертикали или по горизонтали. Каждый элемент может содержать в себе другие элементы, и они также будут жить по законам блочной структуры.
Существуют особые случаи, когда можно положить элемент поверх блочной структуры. Для этого используется свойство position. Поведение таких элементов в динамике надо продумывать отдельно.
![](img/layout-html.png)
По умолчанию у элементов нет отступов внутри и снаружи, но их можно настроить. Для этого есть специальные css-атрибуты:
- Padding — это отступ от контента до края блока.
- Border — обводка.
- Margin — отступы до соседних элементов.
Содержимое — это сам контент, его размеры могут быть жёстко заданы или зависеть от условий: размера экрана, количества символов текста и пр.
![](img/layout-css.png)
Figma позволяет верстать очень близко к html-коду. Используйте это, включайте автолейауты и констрейнсы, чтобы помочь разработчику быстрее понять задумку дизайнера и точнее воспроизвести вёрстку макета средствами html и css.
Названия слоев и фреймов
Называйте слои так, чтобы было понятно, что это за элементы и как они себя ведут. Макет с хорошим неймингом можно понять, глядя на одно только дерево элементов.
Например, здесь названия слоев однозначного говорят о том, что перед нами список пунктов с буллитами:
![](img/layout-namesList.png)
А здесь, что перед нами не просто картинка, а аватарка:
![](img/layout-namesAvatar.png)
Размеры элементов
Задавайте размеры элементам, чтобы показать, как они ведут себя при изменении контента. Например:
![](img/layout-dimensionsWidth.png)
Произвольно заданный размер сбивает с толку и мешает понять, как работает макет.
Например, здесь задана высота текстовой области, которая чуть больше высоты строки. Текстовая область в такой конструкции не будет нормально масштабироваться при изменении контента и непонятно, что дизайнер имел в виду. Надо постараться показать вёрсткой макета, что должно случиться с текстом.
![](img/layout-dimensionsHeight.png)
Группировка элементов
Группируйте элементы так, как они будут связаны в html-вёрстке. Объединение по другим принципам может запутать разработчика. Например, здесь непонятно, связаны буллиты с текстом или нет:
![](img/layout-groupIllogical.png)
Группируя с помощью фреймов и автолейаутов, можно показать, какая область ховера у элемента, и объяснить логику отступов между элементами:
![](img/layout-groupHover.png)
Используйте группировку и выравнивания, чтобы проиллюстрировать, как элементы поведут себя при изменении размера экрана:
![](img/layout-groupResize.gif)
Используйте автолейауты и констрейнсы, чтобы упорядочить макет и избежать случайных отступов.
Компоненты
Если вы собираетесь скопировать фрагмент интерфейса, подумайте, а не сделать ли его компонентом. Несинхронизованные копии приведут к расхождениям версий и путанице при чтении макета.
Организация конкретного компонента
Используйте автолейауты и констрейнсы. Это поможет комфортно переиспользовать компонент в разных ситуациях — адаптировать его под размер экрана, количество контента и тд.
Для организации различных состояний компонента используйте вериантс, вместо скрытых слоев или множества компонентов. Так заполненные значения не будут сбрасываться при переключении состояний и этот способ меньше нагружает память компьютера.
![](img/showing-variants.png)
Организация множества компонентов
Для удобства поиска придумайте понятные названия для компонентов. А в их описании пропишите ключевые слова. Расспросите коллег или вспомните какими терминами они называют подобные контролы. Не забудьте прописать варианты с русско-английской транскрипцией.
![](img/showing-description.png)
Собирайте сложные компоненты из простых. Если вам нужен компонент, который будет использоваться только внутри других компонентов, сделайте его приватным, чтобы он не публиковался в библиотеке. Для этого поставьте нижнее подчёркивание в начале _названия компонента.
Например, можно сделать приватным «базовый» компонент, а его инстансы* изменять, чтобы создать разные состояния. И уже эти состояния оборачивать в новый компонент, который пойдёт в публикацию. При таком подходе изменения базового компонента будут распространяться на все копии.
Инстанс (instance) — так разработчики называют экземпляр объекта, который наследует характеристики родительского объекта
Как только новый компонент начинает использоваться в разных частях системы, лучше перенести его на отдельную страницу в Фигме. Если возникает необходимость использовать компонент в разных файлах, создавайте файл с библиотекой и подключайте её там где нужно.
Группируйте, чтобы структурировать библиотеку контролов и помочь в ней ориентироваться. Группы создаются объединением контролов во фреймы. Так же можно публиковать разные библиотеки из разных файлов.
Стили
Все цвета в макете должны быть занесены в библиотеку стилей. Это позволяет использовать цвет в интерфейсе системно — помогает избежать появления близких оттенков и не плодить варианты, когда они не нужны.
Как шутят фронтендеры — в макете неопытного дизайнера по пятьдесят оттенков серого
Называя стиль отталкивайтесь в первую очередь от его функции — как он используется в интерфейсе. Например:
![](img/showing-colorname1.png)
Семантические названия останутся актуальными, если вы решите изменить оттенок или даже цвет, например, при переходе на темную тему.
В исключительных ситуациях можно называть стили по их внешним атрибутам. Например, в наборе цветов для тегов: желтый, зеленый и красный всегда останутся такими.
![](img/showing-colorname2.png)
Когда стилей в макете становится много — собирайте их на отдельных страницах. Если возникает необходимость использовать одинаковые стили в разных файлах, создавайте файл с библиотекой стилей и подключайте её там где нужно.
Группируйте, чтобы структурировать библиотеку стилей и помочь в ней ориентироваться. Группы создаются с помощью слэшей в названиях. Так же можно создавать разные библиотеки в разных файлах.
Используйте стили для разных ситуаций, в них можно добавлять не только цвета и типографику. Также в стили можно добавлять изображения (например, аватарки), обводки, тени и другие эффекты, а также настроенные сетки.
![](img/showing-avatarstyles.png)
Как рисовать без лишних элементов
Используйте стили для разных ситуаций, в них можно добавлять не только цвета и типографику. Также в стили можно добавлять изображения (например, аватарки), обводки, тени и другие эффекты, а также настроенные сетки.
Например, аватарку можно сделать с помощью маски, но потребуется два элемента, объединенных в группу. Лучше сделать заливку фигуры картинкой. Тогда не нужны будут лишние элементы и изображение само встанет ровно посередине и растянется до нужного размера.
![](img/layout-simple.png)
Как описывать разные состояния интерфейса
Не дублируйте страницу целиком, когда нужно описать поведение элементов интерфейса.
Don't repeat yourself (DRY) — это принцип разработки, направленный на повторное использование кода. Но его также можно использовать и при вёрстке макетов. Следование правилу «не повторяйся» повышает читаемость и консистентность макетов.
Фокусируйтесь на конкретных изменениях и не изображайте окружающие контекстные элементы, если они и так понятны. Если нужно подробно показать где именно на странице произойдёт изменение, достаточно показать это один раз.
![](img/showing-manybourd.png)
Неправильно
Акцентируйте внимание на различиях. Показывайте состояния элементов рядом, используйте подписи где они нужны.
![](img/showing-fragments.png)
Правильно
Именуйте корневые фреймы. Их названия видны даже при зумировании. С осмысленными названиями проще найти нужный фрагмент макета.
![](img/showing-artboardsnames.png)
Если хотите собрать кликабельный прототип, но он портит читабельность макета — собирайте его на отдельной странице.
Как вовремя остановиться
Степень проработки макета зависит от этапа проектирования. Если вы только начали думать над задачей и работаете в режиме генерации концепций, не стоит верстать идеально. Это может помешать, потому что вы начнёте думать «как нарисовать» вместо «что нарисовать». А на этапе подготовки макета к передаче в разработку приходит время подумать о понятной вёрстке.
Макеты, которые дополняются новыми задачами и правками, со временем «захламляются». В них нужно периодически проводить уборку, подобно рефакторингу в коде.
Рефакторингом разработчики называют процесс улучшения кода без изменения его функциональности. Цель — написать «чистый» код, который просто читать, понимать и поддерживать.
Структурируя макет, будьте разумными в степени перфекционизма. Делайте макеты понятными, но не забывайте, что главный приоритет — продукт, а не макеты.