Atomic design что это
Атомарный веб-дизайн
Предлагаю читателям «Хабрахабра» перевод статьи Брэда Фроста (Brad Frost) «Atomic Web Design».
Мы не проектируем страницы, мы проектируем системы компонент. — Stephen Hay
По мере того, как ремесло веб-дизайна продолжает развиваться, мы всe больше ощущаем нужду в продуманной, системной разработке, в отличие от создания простых наборов веб страничек.
Многое было сказано насчeт создания систем дизайна, и наибольший акцент делается, в основном, на установление цветов, типографии, сеток, текстур и т.п. Такой тип мышления, несомненно, важен, но я чуть меньше заинтересован в этих аспектах дизайна, потому что, по большому счeту, они всегда субъективны. В последнее время меня больше озадачил вопрос о том, из чего состоят наши интерфейсы, и как мы можем проектировать их более систематично.
В поисках вдохновения я возвращался к химии. Всe вещества (будь то твeрдые тела, жидкости, газы, простые, сложные и т.д) состоят из атомов. Атомы связываются между собой и образуют молекулы, которые, в свою очередь, комбинируются и формируют организмы. В конечном счeте так создается все вещество в нашей вселенной.
Аналогично интерфейсы состоят из меньших компонент. Это означает, что мы можем разбить интерфейсы на фундаментальные блоки и комбинировать их, постепенно наращивая сложность. Это суть атомного веб дизайна.
Переодическая система элементов HTML.
Что такое атомарный дизайн
Атомарный дизайн это методология создания систем дизайна. В атомном дизайне есть пять отчётливых уровней:
Атомы
Атомы в природе — это основные строительные блоки материи. В контексте веб-интерфейсов атомы — это HTML тэги, такие как форма, поле ввода, или кнопка.
Атомы могут включать в себя даже более абстрактные элементы, такие как цветовые палитры, шрифты, или даже такие более скрытые аспекты интерфейса как анимации.
Как и атомы в природе, они довольно абстрактны и зачастую бесполезны сами по себе. Однако польза от их проектирования состоит в задании единого общего стиля интерфейса.
Молекулы
Всё становится интересней и ощутимей, когда мы начинаем комбинировать атомы. Молекулы — это совокупности связанных между собой атомов. Они имеют собственные свойства и играют роль скелета нашей системы дизайна.
Например — метка, поле ввода и кнопка не так уж применимы сами по себе, но могут быть действительно полезными, если их соединить.
Построение молекул из атомов способстует умонастроению «делай что-то одно, но хорошо». В то время как молекулы могут быть достаточно сложными, чаще всего это простая комбинация атомов, построенная для повторного использования.
Организмы
Молекулы дают нам некоторые строительные блоки для работы. Теперь мы можем соединять их вместе для формирования организмов. Организмы — это объединения молекул, которые образуют довольно сложные, отдельные разделы интерфейса.
Мы всё быстрее переходим к конкретике. Клиент может быть не очень заинтересованным в молекулах системы дизайна, но с появлением огранизмов можно наблюдать начало формирования конечного продукта. Дэн Молл (с которым я работаю над несколькими проектами) использует коллажи элементов, которые показывают ключевые идеи и направления интерфейса без нужды проектирования сайта целиком.
Огранизмы могут состоять из похожих или разных типов молекул. К примеру, заголовок страницы может состоять из разных компонент — логотипа, главного меню, формы поиска и списка медиа-каналов. Но организм, отображающий сетку товаров, может содержать одну молекулу (изображение продукта, название и цена), которая повторяется много раз.
Переход от молекул к организмам способствует созданию самостоятельных компонент, готовых к повторному использованию.
Шаблоны
На этой стадии мы перестанем проводить аналогии с химией, чтобы общаться на более осмысленном для наших клиентов языке. Шаблоны чаще всего состоят из групп организмов, связанных вместе и формирующих страницы. Именно на этом этапе становится видна общая картина.
Шаблоны очень конкретные и предоставляют контекст ко всем довольно абстрактным молекулам и организмам. Именно шаблон позволяет видеть конечный дизайн. В моём опыте работы с этой методологией шаблоны начинаются с HTML wireframe’ов, но со временем становятся более точными. В итоге они становятся конечными продуктами. Bearded Studio в Питтсбурге имеют похожий процесс, при котором дизайны начинают разрабатывать чёрно-белыми и без разметки, но постепенно набирают конкретики и деталей до тех пор, пока не становятся конечными работами.
Страницы
Страницы — это конкретные экземпляры шаблонов. В них для точной передачи того, что увидит пользователь, «заглушечный» контент заменён настоящим.
Страницы — это высший уровень конкретики и, т.к. они наиболее осязаемы. В работе над ними тратится большинство времени большинства людей, вовлечённых в процесс, и на них пишется большинство обзоров.
Страничная стадия необходима, потому что именно на ней проверяется эффективность всей системы дизайна. Видя всё в контексте можно сделать шаг назад и изменить наши молекулы, организмы и шаблоны для того, чтобы лучше подстроиться под реальный контекст дизайна.
Также это стадия для тестирования изменений в шаблонах. Например, вам нужно удостовериться в том, что заголовок с 40 символами выглядит согласованно с заголовком из 340 символов. Или проверить, как вместо корзины с одной вещью выглядит она же с 10 вещами и со скидкой по промо-коду. Эти ситуации влияют на то, как мы строим нашу систему.
Почему атомарный дизайн
Во многих смыслах именно так мы и делали сайты, даже если мы не задумывались об этом сознательно.
Атомарный дизайн предоставляет ясную методологию для создания систем дизайна. Клиенты и члены команды могут оценить идеи конкретной системы дизайна благодаря тому, что они видят этапы её разработки.
Атомарный дизайн даёт нам возможность переходить от абстрактного к конкретному. Поэтому мы можем создавать системы, являющиеся масштабируемыми и обладающие единым, постоянным стилем, и в то же время показывающие итоговую общую картину. Процесс вместо деструктурирования превращается в сборку — мы создаём структуру с самого начала, а не тщательно выбираем подходящие шаблоны после.
Pattern Lab
Для применения этой методологии в своей работе я (с помощью Дейва Ослена) разработал инструмент Pattern Lab, предназначенный для создания атомных систем дизайна. Расскажу о Pattern Lab в деталях позднее, но не стесняйтесь посмотреть исходники на Github.
Как атомарный дизайн помогает проектировать веб-интерфейсы
Автоматизация дизайн-процесса
Вы уже определились со стилистикой и создали макеты первых страниц веб-интерфейса. Чтобы ускорить работу, разберите макет на части и используйте их как детали при конструировании остальных страниц.
Используйте методологию атомарного дизайна
Атомарный дизайн — это система маленьких элементов — атомов, которые можно использовать повторно и комбинировать друг с другом.
Атомы. Разберите интерфейс на кусочки: кнопки, поля ввода, чекбоксы, радио-кнопки, стили для типографики.
Молекулы. Комбинируйте два атома — вы получите молекулу. Например кнопка и поле ввода.
Организмы. Несколько молекул в совокупности образуют организм. Это крупные части интерфейса. Например основная навигация в верхней части страницы.
Шаблоны. Сочетайте организмы друг с другом, соберите из них весь интерфейс. У вас получится каркас страницы — это ваш прототип.
Страницы. Заполните шаблоны реальной информацией. Проверьте визуально насколько хорош ваш дизайн.
Расставляйте элементы по сетке в 8px. Так вы не будете задумываться какой отступ поставить между элементами интерфейса. Просто выровняйте их по квадратам.
Атомарный дизайн — это методология организации вашей работы. Он не требователен к инструменту. Вы можете работать в любой программе. Мыслите системно, создавайте повторяющиеся шаблоны и собирайте интерфейс из них.
Мыслить от меньшего к большему
Не путайте атомарный дизайн с библиотекой готовых элементов. В атомарном подходе главное — мыслить от меньшего к большему. Прорабатывайте дизайн с мелких атомов и закончите собранной страницей заполненной информацией. Если страница выглядит негармонично — измените атомы и проделайте весь путь еще раз.
Очистка от графического мусора
Веб-разработчики проводят рефакторинг написанного кода — так они ищут ошибки, оптимизируют скорость работы. Учитесь у них. По ходу сборки атомарного шаблона оптимизируйте дизайн. Срезайте лишнюю графику если не удается уместить ее в систему атомарного дизайна. Оптимизируйте количество цветов: используйте доминантный и один дополнительный цвет. Создайте пять или шесть оттенков серого. Этого цвета всегда не хватает, осторожнее с ним.
Быстрая сборка
Базовый атомарный шаблон готов. Новые страницы скомпонуйте из готовых блоков. Это удобно на средних и крупных проектах. Например интернет-магазине детских игрушек, сервисе по доставке пиццы, биржае через которую молодые родители ищут няню для ребенка. Пятистраничный сайт через месяц может превратиться в высоконагруженный сервис — он востребован пользователями. Срочно потребуются дополнительные страницы. Используя набор интерфейсных элементов дизайнер не будет задумываться над отступами или цветами. Он сосредоточится на проектировании системы целиком.
Легкая поддержка шаблона
Целевая аудитория сервиса над которым вы работали последние шесть месяцев может резко измениться. Нужно срочно изменить цвет или шрифт на всем сайте, использовать другие иконки и иллюстрации. Внесите изменения в шаблон с атомами и молекулы с организмами изменятся автоматически.
Форма обратной связи может быть неудобной для пользователя. Это выяснится только после запуска и тестирования сервиса. А эта форма используется в пяти местах сайта. Внесите изменение в организм с этой формой и дело сделано.
Кнопки на собранной странице могут оказаться слишком маленькими или поля ввода не контрастыми. Значит атомарный шаблон надо менять. Поправьте его пока не поздно. Отладка дазайна должна войти в привычку.
Верстайте на БЭМ
Если вы работаете в команде с разработчиком, обсудите с ним атомарный шаблон. Расскажите почему вы выбрали такой подход. Попросите его верстать на БЭМ — это методология веб-разработки от яндекса. Она позволяет создавать шаблонизируемые элементы интерфейса, чтобы использовать их повторно. Методология схожа с атомарным дизайном, но создавалась для веб-разработчиков.
Я, Белицкий Алексей. Занимаюсь дизайном, проектированием интерфейсов. Увлекаюсь веб-технологиями и всем, что упрощает современную жизнь. Можете найти меня в фейсбуке.
Разобрать на атомы, собрать обратно: как атомарный подход повышает эффективность веб-дизайна
На пути внедрения методологии атомарного веб-дизайна, мы — в AIR Production — смотрим на кейсы и опыт западных коллег. В этой статье выяснили, как дизайн-процессы приспосабливаются к атомарному дизайну «в поле». Статья адаптирована и переведена на русский язык, оригинал принадлежит Игорю Сивцу, ведущему UX-дизайнеру из EPAM (разработчик ПО).
Четкая, задокументированная дизайн-система — ключ к успеху крупного проекта. Есть много способов создать подобную систему. Атомарный дизайн — один из методов ее проектирования.
Мы начали использовать атомарный подход еще летом 2016 года. Несмотря на то, что в теории он был понятен, нам понадобилось время, чтобы дизайнеры и разработчики нашли практические пути его использования.
Рассмотрим, в чем атомарный метод выигрывает перед другими, более распространенными подходами к созданию дизайн-систем. Также мы расскажем, как дизайнерам использовать его в работе с применением современных инструментов, такие как Sketch и InVision.
Как только появились первые компьютеры, специалисты по ПО стали искать способы ускорить рабочие процессы и уменьшить количество ошибок.
Именно для этого появились системы компонент. Компоненты — это модули многоразовых фрагментов кода. Иными словами, с системами компонент вам не придется дважды кодировать одно и то же. Также вы сможете один раз изменить компонент системы — и он автоматически поменяется везде.
Метод системы компонент помогает выстроить более понятную архитектуру приложения, и в целом объединяет в себе весь процесс его разработки.
Но это не единственный подход, применяемый в разработке. Есть два общих метода, которые используют при создании сайтов для его реализации.
Фреймворки. Bootstrap, Materialize, Foundation, и так далее. Разработчики с радостью используют их, так как они экономят время и усилия. Однако, у этого метода есть много недостатков.
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. В этом случае вам не придется переименовывать каждое название кнопки в ваших макетах, если ее цвет вдруг изменится. И таким образом, вы можете понять, какую роль играет элемент в системе, просто прочитав его название.»