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