Атомарный веб-дизайн
Предлагаю читателям «Хабрахабра» перевод статьи Брэда Фроста (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.
Разобрать на атомы, собрать обратно: как атомарный подход повышает эффективность веб-дизайна
На пути внедрения методологии атомарного веб-дизайна, мы — в 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. В этом случае вам не придется переименовывать каждое название кнопки в ваших макетах, если ее цвет вдруг изменится. И таким образом, вы можете понять, какую роль играет элемент в системе, просто прочитав его название.»
Всё, что вам нужно знать об атомарном дизайне
Что такое атомарный дизайн?
В 2016 году Брэд Фрост представил атомарный дизайн — модульную методологию для создания библиотек паттернов, простых в поддержке, масштабировании и развитии. Вся суть в создании более крупных и сложных UI-компонентов из более мелких и простых¹. Атомарный дизайн объединяет компоненты в пять категорий: атомы, молекулы, организмы, шаблоны и страницы. Мы рассмотрим каждый тип ниже, но если коротко, то «атом» — это самый простой элемент дизайна, а «шаблон» — самый сложный.
Категории компонентов
Атомы (atoms) — это «основополагающие строительные блоки». Другими словами, это самые основные элементы интерфейса: кнопки, иконки и текстовые поля. Они служат ядром вашего приложения, несущими конструкциями.
Пример 1: Иконка поиска — один из «атомов» в большой библиотеке паттернов.
Молекулы (molecules) — это группы атомов, работающих вместе для выполнения одной задачи. Например, строка поиска представляет собой одну молекулу, построенную из одного текстового поля и одной иконки. Задача строки — помочь пользователям в поиске контента по всему сайту.
Пример 2: два атома (кнопка с иконкой поиска и поле ввода) объединяются для создания «молекулы».
Организмы (organisms) — это сложные группы, состоящие из молекул, атомов или даже других организмов. По сравнению с молекулами, организмы настолько сложны, что могут выполнять сразу несколько задач. Шапка сайта, например, может включать в себя логотип, гамбургер-меню и строку поиска. Это означает, что она может выполнять три функции: работать на узнаваемость бренда и помогать и в навигации, и в поиске. При этом организмы обычно стремятся к единой цели, но об этом позже.
Пример 3: соединяя два атома и молекулу вместе, можно получить единый «организм».
Шаблоны (templates) представляют собой законченные веб-страницы или экраны приложений, построенные из комбинаций более низкоуровневых предыдущих компонентов. В них отсутствует только финальный контент.
Пример шаблона главной страницы YouTube
Страницы (pages), в свою очередь, — это инстансы отдельно взятого шаблона, заполненные уникальным контентом. Например, шаблон главной страницы может быть заполнен персонализированным контентом для двух разных пользователей (как показано ниже).
У страниц есть несколько функций:
Два разных инстанса (примера использования) шаблона домашней страницы YouTube
Вот из этих элементов и состоит атомарный дизайн. Эта методология довольно проста и предназначена для «создания систем проектирования интерфейсов более продуманным и структурированным образом» — так сказано в гайдлайнах атомарного дизайна от его создателя, Брэда Фроста. В этой методологии кроется много пользы — но если у вас не было опыта создания собственной библиотеки паттернов, вы вполне резонно можете подумать: «А дальше-то что?»
Зачем вам атомарный дизайн?
Создавать библиотеки паттернов непросто, но (как мы обсудим позже) поддерживать их ещё сложнее. Некорректно собранная библиотека доставит вам больше проблем, чем пользы — и дальше лишь вопрос времени, когда вы прекратите ей пользоваться.
А у атомарного дизайна есть три основных преимущества, которые помогут избежать этого:
Когда следует применять атомарный дизайн?
Собрать атомарную библиотеку в своем проекте никогда не поздно — но вполне может быть слишком рано.
UI-дизайн состоит из трёх основных этапов:
Первый этап — свободное творческое мышление. Здесь опасения по поводу системности и простоты вас только замедлят. Атомарный дизайн может принести пользу на втором этапе, когда вы станете дублировать паттерны от одного юзер флоу к другому. С учётом сказанного я считаю наиболее эффективным применять атомарный дизайн на третьем этапе, после того как большинство паттернов уже определено и оформлено. Здесь у вас меньше шансов потерять терпение из-за ограничений и рамок, и больше возможностей оценить гайдлайны, которые помогут в поддержке существующих макетов.
Как применять атомарный дизайн?
Как и с написанием текстов, мало что может быть более пугающим, чем пустой холст в Figma, Sketch или AdobeXD². А атомарный дизайн предоставляет чёткие и легко выполнимые шаги для создания собственной библиотеки паттернов.
Первый шаг прост: создайте файл «Библиотека паттернов» и добавьте по одной странице для каждой категории компонентов (т.е. атомы, молекулы, организмы, шаблоны и страницы).
В этом примере я добавил в Figma страницу для каждой категории компонентов
Начните с «атомов». Дублируйте существующие вайрфреймы или макеты на страницу шаблоны в вашей библиотеке паттернов. Отделите основные элементы каждого экрана от их исходных фреймов³. Это и будут ваши первые атомы. Переместите каждый из них на страницу атомов и преобразуйте их в отдельные компоненты.
Скринкаст того, как дизайнер создаёт свои первые атомы из существующих макетов
Следующий этап — «молекулы». Скопируйте инстансы каждого атома и вставьте их обратно в исходные экраны на странице шаблонов. Используйте эти истансы для восстановления исходных экранов.
Как только экраны восстановлены, сгруппируйте атомы вместе по задаче, которую они выполняют. Например, можно сгруппировать поле для ввода электронной почты, поле для ввода пароля и кнопку «Зарегистрироваться сейчас», потому что они все работают вместе для выполнения одной задачи: регистрации пользователя. Каждая из этих групп — одна молекула. Переместите каждую молекулу на страницу молекул и преобразуйте их в отдельные компоненты.
Скринкаст того, как дизайнер создаёт первые молекулы для своей библиотеки паттернов
После этого беритесь за «организмы». На этом этапе процесс должен уже быть понятен. Так же, как вы сделали с атомами, скопируйте инстансы каждой молекулы в их исходные шаблоны и сгруппируйте. В прошлый раз вы группировали элементы по задачам, теперь нужно сгруппировать их по цели. Различие небольшое, но очень важное.
В то время как молекулы выполняют единственную задачу, сложные организмы могут выполнять множество задач, направленных на достижение одной цели. Например, хедер верхней панели может содержать меню и строку поиска. Задача меню — позволить пользователям посещать определенные страницы; задача панели поиска — позволить пользователям находить контент на любой странице. А цели хедера включают в себя и то, и другое: навигацию по всему приложению.
Дизайн авторства thebestdesigns
При создании организмов необходимо учитывать два важных момента:
Во-первых, организм может состоять из молекул или смеси молекул и атомов, но он не может быть только из атомов (поскольку тогда это была бы молекула, а не организм).
Во-вторых, не все экраны достаточно сложны, чтобы содержать организмы. Экраны загрузки и прелоадер, например, часто содержат только атомы или простые молекулы (см. ниже). Не ищите организмы на каждом экране.
Экран загрузки, дизайн Влада Грамы. Прелоадер Якуба Кослы
Однако, если вы нашли организм, обязательно повторите для него тот же процесс: преобразуйте его в отдельные компоненты, переместите его на страницу организмов, скопируйте истансы каждого организма и вставьте их обратно в исходные шаблоны.
Скринкаст того, как дизайнер создаёт первые организмы в своей библиотеки паттернов
Определите «шаблоны». На этом этапе каждый из ваших экранов на странице шаблонов должен быть полностью построен из атомов, молекул и организмов. Всё, что вам нужно сейчас сделать, — это преобразовать каждый отдельный экран в отдельный компонент. Та-да, и у вас есть свои шаблоны!
Скринкаст того, как дизайнер создаёт первый шаблон для своей библиотеки
Наконец, осталось создать «страницы». Страницы — это инстансы шаблонов с уникальным контентом, поэтому вам не нужно создавать их сразу. Если у вас есть свежий контент, который вы хотели бы протестировать или продемонстрировать с помощью шаблона, скопируйте этот шаблон на страницу «страницы» и просто добавьте в него контент.
Скринкаст того, как дизайнер создаёт пример страницы на основе нового шаблона
[Поделитесь своей библиотекой и импортируйте её в другие файлы]
Все современные инструменты для UI-дизайна поддерживают создание и использование UI-китов проекта/библиотек паттернов. Но то, как вы ими будете делиться и импортировать, зависит от вашего софта:
Figma: Перед публикацией сохраните свой файл в репозитории команды. После этого откройте файл и поставьте галочку (∨) справа от имени вашего файла. Затем выберите «Publish styles and components» (Опубликовать стили и компоненты). После этого вы и ваша команда сможете импортировать библиотеку в другие командные файлы. Просто кликните на логотип Figma, выберите «Libraries» (Библиотеки), найдите нужную в каталоге файлов и выберите её.
Sketch: Если вы используете Workspace (настоятельно рекомендую), просто загрузите файл библиотеки, выберите «Document Settings» (Настройки документа) в выпадающем меню файла и установите флажок «Use As Library» (Использовать как библиотеку). Затем редакторы смогут добавлять библиотеку в своё локальное приложение, выбрав «Add Library To Sketch» (Добавить библиотеку в Sketch) в веб-приложении, и им будут приходить уведомления о появлении новых версий.
Adobe XD: Запустите окно «Library» (Библиотеки), нажав на иконку «Document Assets» (Ресурсы документа) в левом нижнем углу. После этого выберите иконку «share» (поделиться) в списке ассетов. Нажмите кнопку «Publish» (Опубликовать), сохраните файл как облачный, а затем пригласите свою команду просмотреть или отредактировать файл.
Ваша работа не заканчивается на создании библиотеки и обеспечении доступа к ней. На самом деле, самая сложная часть использования библиотеки паттернов — это её поддержка во всех файлах.
Figma, Sketch и Adobe XD позволяют обновлять отдельные компоненты или их группы. Но даже если сама библиотека регулярно обновляется, нет никакой гарантии, что дизайнеры примут изменения в своих собственных рабочих файлах. В реальности дизайнеры нередко игнорируют изменения, которые, как они опасаются, могут поломать структуру тех проектов, что у них уже есть.
Кроме того, любой дизайнер с доступом «редактора» может вносить изменения в библиотеку без предварительного одобрения других участников. Повторяющиеся обновления от непослушных дизайнеров, не соблюдающих согласованные процессы, могут быстро подорвать надёжность вашей библиотеки. Существует сторонний инструмент под названием Abstract, который позволяет вам управлять библиотеками наподобие того, как это делает Git (правда, сейчас он работает только со Sketch). У Figma и Adobe XD есть базовые элементы управления версиями, но нет более сложных функций вроде разветвления и слияния (Figma выкатила в прод для тарифного плана «Организация»).
При отсутствии таких удобных автоматизированных средств управления крайне важно, чтобы вы в команде установили основные правила. Мои коллеги, например, согласились тестировать новые паттерны в личных закрытых проектах, показывая их остальным только по мере готовности. После того, как один из нас предлагает изменения, остальная часть команды голосует: утверждаем запрос? При этом ведущий дизайнер имеет право отменить голосование (и этим правом нужно пользоваться с умом). Это решение может вам не подойти, но у вас должно быть хоть какое-то решение, если вы хотите поддерживать свою библиотеку в наилучшем состоянии.
Ключевые выводы
Атомарный дизайн — это методология создания библиотек паттернов. Проще говоря, он позволяет составлять более крупные и сложные компоненты из более мелких и простых. Этот модульный подход обеспечивает согласованность паттернов в ваших рабочих документах и упрощает утомительные рабочие процессы. Вы можете использовать любой из современных инструментов для UI-дизайна, чтобы создать атомарную библиотеку паттернов — просто не забывайте регулярно её обновлять.
Примечания
¹ Хотя многие описывают его как методологию создания дизайн-систем, на самом деле он ограничен, в частности, библиотеками паттернов. Тем не менее, Крис Сид опубликовал блестящую статью о расширении атомарного дизайна, включив в него свойства компонентов и назвав их «эоны» — например, цвета, стили шрифтов, эффекты, отступы, радиус закругления кнопок, размер иконок и т. д..
(прим. редактора: речь идёт о токенах — базовых переменных визуального языка, которые передаются в любой компонентный фреймворк. Они позволяют проще управлять визуальным стилем продуктов и удешевить внедрение на практике. Чтобы углубить знания, советуем посмотреть эту лекцию Юрия Ветрова)
² В рамках этой статьи я буду создавать свои примеры в Figma — моём любимом инструменте.
³ Не обращайте внимания на любые текстовые элементы. Они будут сохранены как стили текста и включены в руководство по стилям (стайлгайд), а не в библиотеку паттернов.
Об авторе
Джереми Абрамс — senior fullstack-дизайнер с опытом работы в области дизайна, ориентированного на человека, исследования и разработки. У него также есть опыт управления локальными и удалёнными кросс-функциональными командами. До этого Джереми получил степень доктора права в Юридическом колледже Чикаго-Кент и был принят в коллегию адвокатов штата Иллинойс в 2014 году.