Разобрать на атомы, собрать обратно: как атомарный подход повышает эффективность веб-дизайна
На пути внедрения методологии атомарного веб-дизайна, мы — в AIR Production — смотрим на кейсы и опыт западных коллег. В этой статье выяснили, как дизайн-процессы приспосабливаются к атомарному дизайну «в поле». Статья адаптирована и переведена на русский язык, оригинал принадлежит Игорю Сивцу, ведущему UX-дизайнеру из EPAM (разработчик ПО).
Четкая, задокументированная дизайн-система — ключ к успеху крупного проекта. Есть много способов создать подобную систему. Атомарный дизайн — один из методов ее проектирования.
Мы начали использовать атомарный подход еще летом 2016 года. Несмотря на то, что в теории он был понятен, нам понадобилось время, чтобы дизайнеры и разработчики нашли практические пути его использования.
Рассмотрим, в чем атомарный метод выигрывает перед другими, более распространенными подходами к созданию дизайн-систем. Также мы расскажем, как дизайнерам использовать его в работе с применением современных инструментов, такие как Sketch и InVision.
Системы компонент: что это значит?
Как только появились первые компьютеры, специалисты по ПО стали искать способы ускорить рабочие процессы и уменьшить количество ошибок.
Именно для этого появились системы компонент. Компоненты — это модули многоразовых фрагментов кода. Иными словами, с системами компонент вам не придется дважды кодировать одно и то же. Также вы сможете один раз изменить компонент системы — и он автоматически поменяется везде.
Метод системы компонент помогает выстроить более понятную архитектуру приложения, и в целом объединяет в себе весь процесс его разработки.
Но это не единственный подход, применяемый в разработке. Есть два общих метода, которые используют при создании сайтов для его реализации.
Фреймворки. Bootstrap, Materialize, Foundation, и так далее. Разработчики с радостью используют их, так как они экономят время и усилия. Однако, у этого метода есть много недостатков.
Дизайнер просто создаст новое всплывающее окно. Разработчик внесет его в код. И в итоге вы увидите, что ваш продукт содержит 10 разных всплывающих окон в ответ на похожие запросы.
Что такое атомарный дизайн?
Представьте, что вы можете использовать только сильные стороны фреймворков для frontend-разработки и руководства по стилю. Как это сделать? Одно из решений предложил веб-дизайнер из Питтсбурга Брэд Фрост — это и есть атомарный дизайн.
Это метод, который позволяет (и требует) описать и организовать все компоненты вашей дизайн-системы.
Как можно воспользоваться атомарным дизайном в реальном потоке работ?
Брэд Фрост и команда разработчиков создали инструмент, получивший название Pattern Lab. Он дает возможность сгенерировать статистический сайт — на нем вы сможете задокументировать вашу атомарную библиотеку. Там можно хранить как все предварительно созданные компоненты, так и их описания.
Это решение было придумано специально для разработчиков. Но как эффективнее всего воспользоваться атомарным методом дизайнерам?
Атомарный подход в работе дизайнера
Если вы UX/UI-дизайнер, вы, наверное, пользуетесь в работе такими инструментами, как Sketch или (все еще?) Photoshop — для создания дизайна. Вы также используете InVision/Zeplin/Avocode, чтобы передавать проекты разработчикам — так они могут ознакомиться с уровнями и размерами ваших макетов. Вдобавок ко всему, у вас есть руководство по стилю, которое описывает некоторые элементы вашего дизайна.
В этой статье я использую все эти знакомые инструменты, чтобы объяснить атомарный рабочий процесс.
Руководство по стилю
Вам нужно приготовиться к тому, что руководство по стилю будет объемным. Ведь каждая деталь вашего механизма должна быть задокументирована.
Используйте отдельный прототип проекта руководства по стилю в вашей версии InVision. Таким образом:
- множество руководств по стилю не создадут беспорядок в основном проекте
- вы создадите дизайн-систему, которая потенциально может быть использована во множестве проектов. И именно поэтому она должна быть доступна различным командам в компании!
Добавьте заглавную страницу, на которой вы обозначите все типы ваших атомов, молекул и организмов. У каждого элемента будет отдельная страница, так что сделайте ваше содержание интерактивным.
Теперь начните свою обычную работу. Добавляйте базовые структурные элементы в ваш проект: типы шрифтов, цвета, иконки, кнопки, выпадающие списки, поля заполнения... Все, что вам нужно сделать до того, как вы создадите первую страницу вашего нового проекта.
Важным дополнением к вашему руководству по стилю будет список изменений — с датой их произведения, описанием их сути и именем того, кто за них отвечает. Это позволит другим участникам вашей команды быстро определить обновленные элементы. Разработчики точно будут вам за это благодарны.
Соглашение о названиях
Давайте обратимся к соглашению о названиях. Чтобы команды дизайнеров хорошо понимали друг друга, оно должно быть последовательным и понятным.
Его нужно написать нижним регистром, разделяя слова дефисами. Оно должно быть:
- простым в использовании для дизайнеров
- простым в использовании для разработчиков — при работе с исходным кодом и при наименовании файлов.
Первая буква в названии будет обозначать категорию понятия: атом, молекула, организм. Второе слово — тип элемента. Остальные слова используются для описания изменений в элементах. Каждый слой, состоящий из атомов, молекул, организмов, или группы этих слоев, должны быть названы соответственно.
Такое подробное присвоение имен также позволит быстро найти «задокументированный» слой в вашем макете. У вас останутся такие слои, как bg, divider и т.д.
Макеты дизайна
Вы создали базовое руководство по стилю, и пришло время создавать страницы. Организуйте вашу работу следующим образом:
Шаг первый. Создайте макет страницы. Некоторые элементы страницы можно взять из руководства по стилю, другие же будут совсем новыми. Это нормально. Поместите ваши слои в соответствующие группы, как вы обычно это делаете.
Шаг второй. Когда страница ассемблирована, она обычно проходит несколько этапов правок и доработок. Вы должны обсудить и согласовать все с вашим клиентом, прежде чем начнете разработку. Поэтому не стоит сразу документировать страницу.
Шаг третий. Ваш дизайн был одобрен, настало время его атомизировать. Убедитесь, что ваши слои/группы структурированы и названы в соответствии с атомарным подходом. Добавьте новые элементы в ваше руководство по стилю.
Шаг четвертый. Наконец, ваша страница готова к разработке. Каждый элемент задокументирован. Это значит, что у команды разработчиков будет меньше вопросов, и продуктивность работы увеличится.
Чем этот подход поможет вашей команде?
Перечислю некоторые важные улучшения, которые произошли в нашей работе благодаря атомарному подходу.
Атомарный метод требует вдобавок к руководству по использованию: а) документацию каждого нового компонента в макете
б) универсальное структурирование слоев. И это помогает решить перечисленные выше проблемы.
В начале пути реализация атомарного подхода в дизайне потребует очень много усилий. Но со временем эти усилия окупятся. Вы не просто создаете кучу кнопок и страниц — вы создаете полностью задокументированную систему, которая может быть впоследствии использована в десятках проектов.
Покажите какой то пример именований в вашей структуре системы?
В оригинале статьи об этом также есть отдельная часть, вот она, приводим выдержку:
"Теперь давайте обратимся к соглашению о названиях. Для того чтобы команды дизайнеров хорошо понимали друг друга, оно должно быть последовательным и понятным.
Его нужно написать нижним регистром, разделяя слова дефисами. Оно должно быть простым в использовании для дизайнеров. Простым в использовании для разработчиков при работе с исходным кодом и для наименования файлов. Это подробное присвоение имен также позволяет быстро найти «задокументированный» слой в вашем макете. У вас останутся такие слои, как bg, divider и т.д.
Первая буква обозначает категорию понятия: атом, молекула, организм. Второе слово обозначает тип элемента. Остальные используются для описания изменений в элементах. Каждый слой, состоящий из атомов, молекул или же организмов или группы этих слоев должны быть наименованы соответственно.
Примечание: чтобы избежать при этом трудностей и стрессовых ситуаций, я рекомендую вам Sketch плагин 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. В этом случае вам не придется переименовывать каждое название кнопки в ваших макетах, если ее цвет вдруг изменится. И таким образом, вы можете понять, какую роль играет элемент в системе, просто прочитав его название."