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

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

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

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

• Сокращать текстовые описания. Самодокументируемый* макет требует меньше пояснений и комментариев на полях.

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

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

• Снижать нагрузку на компьютер. «Лёгкие» макеты быстрее загружаются, в них быстрее сохраняются изменения.

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

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

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

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

В Figma можно верстать очень близко к html-коду. Используйте это, включайте автолейауты и констрейнсы, чтобы помочь разработчику быстрее понять задумку дизайнера и точнее воспроизвести вёрстку макета средствами html и css.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте стили для разных ситуаций, в них можно добавлять не только цвета и типографику. Также в стили можно добавлять изображения (например, аватарки), обводки, тени и другие эффекты, а также настроенные сетки.

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

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

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

Неправильно

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

Правильно

Именуйте корневые фреймы. Их названия видны даже при зумировании. С осмысленными названиями проще найти нужный фрагмент макета.

Если хотите собрать кликабельный прототип, но он портит читабельность макета — собирайте его на отдельной странице.

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

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

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