Статьи
Cоздание дизайн-систем с помощью Atomic Design
5 апреля, 2018
avatar
Игорь Сивец
Senior Experience Designer в EPAM Киев
Мы любим тексты без ошибок. Если вы все же их обнаружили, выделите фрагмент и нажмите Ctrl+Enter.

Что такое atomic design? Как эта методология может упростить работу дизайнеров? А разработчиков? Как ее поэтапно внедрить? О чем важно помнить? На эти и другие вопросы в своей статье отвечает Senior Experience Designer в EPAM Киев Игорь Сивец.

Дизайн-система с детальной документацией может сыграть большую роль в успехе любого крупного проекта. Существует множество подходов к созданию такой системы. Atomic Design — один из недавно предложенных методов.

Я работаю в компании, которая специализируется на дизайне и разработке проектов для крупных корпоративных клиентов. Мы начали использовать atomic-подход летом 2016 года. С тех пор у нас была возможность испробовать эту методологию на нескольких длительных проектах.

В теории atomic-подход был достаточно понятным. Однако на практике нам потребовалось какое-то время, чтобы выработать методы его использования как дизайнерами, так и разработчиками.

В этой статье я хочу поделиться нашим опытом работы с Atomic Design. Сначала мы рассмотрим его преимущества над другими методами. Далее я расскажу, как применить эту методологию дизайнеру, использующему такие современные дизайн-инструменты, как Sketch и InVision.

Часть 1. Компонентно-ориентированные системы

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

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

Такой подход не уникален для программирования. Существует 2 наиболее распространенных компонентно-ориентированных метода в дизайне сайтов.

Фреймворки. Bootstrap, Materialize, Foundation и так далее. В них содержится огромное количество компонентов: от малейших кнопок до аккордеонов и панелей. Как правило, разработчики рады их использовать — это позволяет им сэкономить время и силы. Вместо того, чтобы кодить очередное выпадающее меню, можно просто взять протестированный и готовый компонент и вставить на сайт. Однако у фреймворков тоже есть недостатки.

Bootstrap и Materialize

  • Они не для дизайнеров. Большинство фреймворков позволяют разработчику собрать сайт достаточно быстро. Но сколько из них имеют актуальные .sketch, .psd или другие файлы с набором элементов, которые дизайнер может использовать в графическом редакторе? Front-end фреймворки не предназначены для дизайнеров.
  • В фреймворках доступен некоторый уровень кастомизации. С другой стороны, если вам необходимо сделать что-то с более-менее уникальным стилем, простого изменения цвета кнопок едва ли будет достаточно. В тоже время глубокая кастомизация фреймворка требует больших затрат с точки зрения разработки. И весь смысл фреймворка на этом теряется.
  • Они медленные. Как я уже упоминал, фреймворки содержат огромное количество компонентов, которые вы можете использовать. Но на каждый действительно нужный элемент придется пять абсолютно лишних. Получается, вы храните огромное количество неиспользуемого кода, негативно влияющего на скорость работы системы в целом.

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

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

Стайл-гайды — это отличный старт для вашей дизайн-системы. Автор Desk Metrics гайда: Матеус Дембек

  • Сложно проследить наследование компонентов. Для крупного проекта не редкость наличие нескольких стилей для кнопки, поля ввода или другого элемента. И когда разработчики (или другие дизайнеры) будут рассматривать ваш макет, у них могут возникнуть трудности с пониманием, какой конкретно компонент из стайл-гайда вы используете.
  • Большое количество компонентов не описывается в типичном стайл-гайде. Обычно он содержит информацию лишь о текстовых стилях, иконках, кнопках, полях ввода и так далее. Мелочах. Без детальной документации дизайна макеты зачастую имплементируются не так, как задумал дизайнер.
  • Плохая документация серьезно уменьшает повторное использование ваших дизайн-компонентов. Если в проекте больше десятка страниц, это может стать проблемой. Далеко не всегда другие дизайнеры или разработчики пройдутся по всем макетам вашего проекта, чтобы убедиться, что всплывающее окно «ну такое, с кнопочками» не было уже сделано ранее. Дизайнер рисует новое окошко. Разработчик кодит новое окошко. Прошел месяц, у вас в проекте пятнадцать15 разных версий всплывающего окна для простого вопроса «да/нет».

Часть 2. Что такое Atomic Design

Что, если бы вы могли использовать преимущества и фреймворков, и стайл-гайдов? Одно из решений было предложено Брэдом Фростом, веб-дизайнером из Питтсбурга, США. Оно называется Atomic Design.

Atomic Design — это методология, которая позволяет (и требует) описать каждый компонент в вашей дизайн-системе.

Этот подход делит элементы на пять категорий:

1. Атомы. Наименьшие конструктивные блоки вашего проекта. Прямо как кубики LEGO. Текстовые стили, кнопки, иконки, поля ввода, чекбоксы и так далее. Все эти компоненты не могут быть поделены на более мелкие части, не потеряв при этом всякого смысла (зачем, например, вам кнопка без текста или иконки?).

Атомы

2. Молекулы. Это уже более сложные элементы, состоящие из нескольких атомов. К примеру, «тостеры» с уведомлениями, поля ввода с кнопками (поле поиска), значения данных (например, «скорость: 343 м/c», где слово «скорость» написано в одном стиле, а значение — в другом) и прочие. Иногда молекулы уже становятся полноценно функционирующими элементами. Но, как правило, они должны быть частью организма, чтобы иметь практическую ценность.

3. Организмы. По-настоящему функционирующие части страницы, состоящие из групп атомов и молекул. Многие организмы могут полноценно работать, не полагаясь на остальные компоненты на странице. Обычно они достаточно большие. Например, главное меню сайта, боковая панель, форма для заполнения, всплывающее окно с множеством данных и так далее.

Организмы могут быть достаточно сложными и содержать более мелкие организмы (прямо как в жизни).

Организм «кот» с организмом «мышь» внутри. Фото Тимоти Мейнберг

4. Темплейты. По сути, это страницы без реального контента. Темплейты комбинируют организмы в полноценный макет сайта.

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

Организмы высокого уровня в статье из Википедии

Как atomic-подход используется на практике? Брэд Фрост вместе с командой разработчиков создали инструмент Pattern Lab. Он позволяет сгенерировать статический веб-сайт для документирования вашей atomic-библиотеки. Вы можете хранить там код ваших компонентов и их описание. Это решение для разработчиков.

Давайте рассмотрим, как применять atomic-методологию с точки зрения дизайнера.

Часть 3. Atomic в рабочем процессе дизайнера

Когда наша команда решила опробовать atomic-подход на очередном крупном проекте, в сети не было инструкций для использования методологии на практике. Совместно с разработчиками мы в течение нескольких встреч пришли к решениям для эффективной интеграции atomic в рабочий процесс.

Если вы веб/UI-дизайнер, то в повседневной работе, скорее всего, используете Sketch или (до сих пор?) Photoshop для создания дизайн-макетов. Также, с помощью InVision/Zeplin/Avocode вы передаете ваши макеты команде разработчиков, где они могут рассмотреть структуру и сделать все необходимые измерения. Кроме того, у вас есть какой-никакой стайл-гайд, где описаны некоторые дизайн-элементы.

В рамках этой статьи я буду использовать следующую комбинацию инструментов для описания процесса работы:

Atomic-подход со знакомыми инструментами

Стайл-гайд

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

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

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

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

Базовый стайл-гайд

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

Правила наименования

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

Слова всегда написаны в нижнем регистре и разделены дефисами. Так их просто использовать дизайнеру. И легко использовать разработчику в исходном коде и для наименования файлов. Более того, такой формат названий позволяет быстро понять, какие слои или группы из вашего макета описаны в стайл-гайде. У вас все равно останутся простейшие слои типа bg, divider и так далее.

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

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

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

Четко установленные правила наименования имеют немаловажную роль в успехе дизайн-системы. К примеру, разработчик изучает ваш макет и видит организм o-popup-alert-exit. Он открывает папку с исходным кодом проекта и видит, что компонент уже разработан в файле o-popup-alert-exit.html (ведь у него такая же система наименования). Вместо того, чтобы заново делать компонент, он оперативно добавляет его в нужное место проекта.

Несколько дополнительных рекомендаций по наименованию компонентов:

  • Старайтесь делать имена различимыми и понятными, не используйте числа. Например, a-dropdown-main, a-dropdown-secondary, вместо a-dropdown-1, a-dropdown-2. Имена, в которых содержится смысл, позволят избежать недоразумений (у нас на практике был случай, когда неправильная цифра повлекла за собой целую серию ошибок в макетах и имплементации).
  • Во время наименования старайтесь сосредоточиться на роли элемента в системе, а не его внешнем виде. Не называйте кнопку для главного действия a-button-blue только потому, что она синяя. Это главная кнопка, так что зовите её a-button-primary. В будущем, если цвет главных кнопок у вас поменяется, вам не придется переименовывать каждую синюю кнопку на каждой странице. И просто взглянув на название компонента, вы сможете прикинуть, какую роль он играет в системе.

Sketch Libraries

Libraries – отличная часть функциональности Sketch. Она позволяет присоединить обычный sketch-файл в настройках приложения и использовать его символы во всех дизайн-макетах. Любое изменение исходного файла будет доступно в других макетах с общими компонентам. Используйте ваш стайл-гайд как library. Вы можете подробнее почитать про эту функцию в Документации Sketch.

Примечание: не забудьте организовать и упорядочить символы вашего стайл-гайда на странице Symbols. Когда гайд растет, эта страница становится беспорядочной свалкой. Вам не нужно делать это вручную, достаточно использовать плагин, например, Symbol and Artboard Organizer. Если вы назвали ваши символы правильно, он сделает всё в один клик.

Дизайн-макеты

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

1. Соберите макет страницы. Некоторые элементы будут из стайл-гайда, но многие — абсолютно новые. Пока что организуйте ваши слои в группы так, как вы обычно делаете.

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

3. Дизайн-макет утвержден, настало время атомизировать его. Убедитесь, что все ваши слои и группы названы и структурированы согласно методологии, описанной выше. Добавьте компоненты и их описания в стайл-гайд. Как правило, на начальных этапах проекта этот шаг занимает существенное количество времени. Будьте готовы к этому.

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

5. Наконец, ваша страница задокументирована полностью. Это означает меньше вопросов от разработчиков и более продуктивный рабочий процесс.

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

Часть 4. Как Atomic-методология может помочь вашей команде

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

Разработчики пользуются Invision Inspect для просмотра структуры макетов

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

Улучшения имплементации дизайна и коммуникации в команде. Успех любого проекта значительно зависит от хорошей кооперации дизайнеров и разработчиков. Методология, описанная в статье, позволяет команде найти общий язык общения. Принятые правила наименования и детализированные описания компонентов играют существенную роль в этом. Любой участник команды имеет полную наглядную документацию. Это означает меньше недопониманий и более качественно имплементированный дизайн.

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

Выводы

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

 

avatar
Игорь Сивец
Senior Experience Designer в EPAM Киев
Колонка

У нас есть еще кое-что для вас

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: