Как отличить атомарный дизайн от UI-kit. Введение в атомный веб-дизайн

19.07.2019

Атомарный дизайн позволяет нам переключаться между контекстами также, как это красноречиво описал художник Фрэнк. Атомы, молекулы и организмы, из которых состоят интерфейсы, не висят в вакууме. Интерфейсы и страницы в самом деле состоят из маленьких частей. Маленькие части влияют на всю конструкцию в целом, а целое влияет на более мелкие части. Эти два контекста переплетены, и атомарный дизайн признает этот факт.

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

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

Атомарный дизайн предоставляет нам схему для переключения между частями и целым, однако крайне важно повторить, что атомарный дизайн не является линейным процессом . Было бы глупо проектировать кнопки и другие элементы в изоляции, а затем, скрестив пальцы, надеяться, что все сойдется, и получится единое целое. Именно по этой причине пять этапов атомарного проектирования не должны звучать в вашей голове так: «Шаг 1: атомы; Шаг 2: молекулы; Шаг 3: организмы; Шаг 4: шаблоны; Шаг 5: страницы» .

Вместо этого относитесь к этапам атомарного проектирования как к ментальной модели, которая позволяет одновременно создавать итоговый интерфейс и систему проектирования, лежащую в его основе.

# Четкая граница между структурой и контентом

Обсуждение дизайна и контента немного схоже со спором про курицу и яйцо. Марк Боултон объясняет:

У контента должна быть структура, а структура, как и дизайн, влияет на контент. Неправильно говорить «сперва контент, потом дизайн» и «или контент, или дизайн». Они равноценны, поэтому: «И контент, и дизайн». ~ Марк Боултон

Продуманная система проектирования отвечает своему содержанию, а качественный контент соответствует своему представлению в интерфейсе. Утвержденные нами паттерны интерфейса должны точно отражать характер текста, изображений и другого контента, который в них содержится. Точно так же при создании контента необходимо учитывать то, как он будет представлен. Тесная связь между контентом и дизайном требует принимать в расчет оба компонента при проектировании UI.

Атомарный дизайн дает нам язык для обсуждения структуры паттернов UI и контента, который будет в них содержаться. Несмотря на четкое разграничение между структурой контента (шаблонами, паттернами) и самим контентом (страницами), в атомарном дизайне учитывается их влияние друг на друга. Для примера, давайте рассмотрим эту схему:

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

# Что в имени?

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

Столько, сколько я рассказываю об атомарном дизайне, всегда были люди, которые предлагали альтернативные названия для этапов проектирования. Один предлагает: «Почему бы просто не назвать их элементами, модулями и компонентами?», другой: «Почему бы просто не назвать их базой, компонентами и модулями?» Проблема с терминами вроде «компонент» и «модуль» заключается в том, что из одних только названий нельзя понять их иерархию. Атомы, молекулы и организмы подразумевают иерархию, так что любой, у кого есть базовые знания химии, догадается, о чем идет речь.

Давать названия трудно. Те, что я выбрал для этапов атомарного дизайна, отлично сработали для меня и команд, с которыми я работал при разработке UI. Но, возможно, они не сработают для вас и вашей компании. Это нормально. Вот вам подтверждение от команды разработчиков в GE:

При представлении концепций системы проектирования коллегам мы первоначально использовали терминологию атомарного дизайна. Однако, это вызвало недоуменные взгляды. […] Стало очевидно, что для успешной работы в нашей компании мы должны подобрать более подходящую таксономию. ~

В систему таксономии, к которой в итоге пришли ребята, вошли термины: «Принципы», «Основы», «Компоненты», «Шаблоны», «Характеристики» и «Приложения». Имеют ли эти названия для вас больший смысл? Это не важно. Они установили таксономию, которая имела смысл в их компании, но каждый, кто знает принципы атомарного дизайна смог бы эффективно работать с ними.

Термин «атомарный дизайн» воплощает идеи модулярного дизайна и разработки, что делает его полезным и емким словечком для убеждения заинтересованных сторон и общения с коллегами. Но атомарный дизайн не является жесткой догмой . В конечном итоге, любая таксономия, которую вы выберете, должна помочь вам и сотрудникам вашей компании более эффективно общаться для создания отличной системы проектирования UI.

Атомарный дизайн для UI

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

Вы можете использовать методологию атомарного проектирования при разработке интерфейса любого программного обеспечения: Microsoft Word, Keynote, Photoshop, интерфейса банкомата вашего банка, - чего угодно. Чтобы это доказать, давайте применим атомарный дизайн к нативному приложению Instagram.

Дизайн приложения Instagram, разобранный на атомы.

Давайте расщепим интерфейс Instagram на атомы:

Атомы. Этот экран пользовательского интерфейса Instagram состоит из нескольких иконок, нескольких текстовых блоков и двух типов изображений: главного изображения и аватара пользователя.
Молекулы. Несколько иконок образуют простые утилитарные компоненты: нижнюю панель навигации и панель действий с фотографиями, где пользователи могут лайкнуть или оставить комментарии. В дополнение, простые комбинации из текста и/или изображений образуют относительно простые компоненты.
Организмы. Здесь мы видим, как формируется организм фотографии. Он состоит из информации о пользователе, времени публикации, самой фотографии, действий с этой фотографией и информации о ней, в том числе количество лайков и подпись. Этот организм - основа Instagram, поскольку многократно повторяется в нескончаемом потоке сделанных пользователем фотографий.
Шаблоны. Мы видим, как компоненты работают вместе в контексте макета. Кроме того, здесь перед нами обнажается структура контента Instagram, в которой особенно выделяется динамический контент: никнейм пользователя, аватар, фотография, лайки и подпись.
Страницы. И, наконец, мы видим конечный продукт, наполненный контентом. Это помогает убедиться, чтобы основная система дизайна сложилась и формирует красивый и функциональный интерфейс.

Я нарочно выбрал в качестве примера не сайт, потому что есть тенденция ошибочно относиться к атомарному дизайну, как к подходу при работе с веб-технологиям: CSS, JavaScript и т.п. Позвольте внести ясность: атомарный дизайн не имеет ничего общего с такими узкими веб-темами, как CSS или JavaScript . В первой главе мы говорили о тенденции к модульности во всех аспектах проектирования и разработки. Это фантастическая тенденция, в том числе для CSS и JavaScript, но атомарный дизайн связан с созданием систем проектирования UI, независимо от того, какая технология используется.

Атомарный дизайн в теории и на практике

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

Атомарный дизайн позволяет нам расщеплять интерфейсы на атомы и одновременно наблюдать, как эти элементы объединяются для формирования итоговых интерфейсов.

Мы узнали о тесной связи между контентом и дизайном и о том, как атомарный дизайн позволяет нам создавать структуру, адаптированную к содержанию.

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

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

Предлагаю читателям «Хабрахабра» перевод статьи Брэда Фроста (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

Если кратко: Atomic Design с использованием Sketch – это будущее разработки продуктового дизайна.

Следуйте за мной

Брэд Фрост, потрясающая личность из видеоролика, является одним из основателей системы, о которой пойдет речь в этой статье. Atomic Design был разработан в ответ на этот цифровой, адаптивный мир, в котором мы все живем и работаем.

Мы создаем руководства по стилям, руководства по элементам, мудборды и прочие инструменты с целью упростить понимание и будущее применение наших дизайнов. Точно также разработчики используют вещи вроде Bootstrap, Foundation, Bourbon и прочие похожие инструменты, чтобы ускорить процесс кодинга. Когда мы работаем в команде, с помощью таких вещей жизнь заметно облегчается. И вот именно для этого существует Atomic Design.

Atomic design больше пригоден для дизайна большой картины в целом, чем создания какой-то отдельной сущности или страницы. Этот инструмент отлично подойдет для дизайна ядра системы.

Atomic design подразумевает создание системы отдельных фрагментов, которые могут использоваться для создания элементов и шаблонов, которые можно использовать повторно множество раз.

Атомы

Атомы – это абсолютный фундамент нашей системы. Атомы включают палитры цветов, шрифты, индивидуальные элементы (например, заголовки, абзацы, кнопки и т.д.) и прочие вещи, которые соединяются с другими атомами для создания молекулы.

Молекулы

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

Молекулы включают такие элементы, как поля формы с надписью или таблица с заголовками и колонками данных.

Организмы

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

Пример организма – главная навигация на страничке, которая включает лого, ссылки навигации и поле поиска или кнопку регистрации.

Шаблоны

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

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

Страницы

Страницы – это уже более детализированная версия шаблонов. Дизайн на картинке выше уже расценивается как страничка. Здесь уже даже новичок в дизайне может понять, что за проект мы создаем.

Страницы не всегда являются необходимостью, но кто же не любит красивую визуализацию?

Почему Sketch?

Хотя Sketch еще не стал таким мощным центром разработки дизайна, как Adobe Illustrator или Photoshop, это потрясающий инструмент для работы по методологии Atomic Design.

Организация

Sketch – это своего рода удачное дитя любви Adobe Illustrator и Photoshop. Несомненно, Sketch еще очень молод, но уже достаточно мощен, и помимо этого, невероятно прост в работе.

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

Если вы не организуетесь, как следует, скорее всего, вы начнете терять деньги на процессе дизайна, просто вы еще не осознали эти потери. Организация работы крайне важна в эффективном расходовании времени и прочих ресурсов!

Модульность

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

Создание символа позволяет вам менять все стили элемента, и эти изменения будут отражаться на всех сущностях символа в рамках одного файла.

Для начала нарисуйте свой элемент, каким вы хотите его видеть.

Затем выделите его и кликните на кнопку Create Symbol (создать символ) на верхней панели инструментов.

Совет от профессионала: Чтобы превратить элементы с текстом в идеально модульные символы в Sketch, обязательно отметьте галочкой опцию Exclude Text Value from Symbol в наборе инструментов справа.

Чтобы сделать это, вам нужно сначала выделить текст в символе, если вы этого не сделаете, вы не увидите нужную опцию в наборе инструментов.

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

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

Всегда, когда хотите разместить один из созданных элементов, нужно просто кликнуть на дропдаун Insert , найти опцию Symbols и выбрать символ, который хотите вставить.

Конвертация в код

Экспорт в код

Что может быть лучше модульных символов? Экспорт дизайна прямо в код. Это означает, что вам, дизайнерам, не нужно учиться правильно разделять исходники для кода. Хотя, и это не помешает.

Чтобы получить код ваших элементов, сначала нужно убедиться, что они соответствующим образом между собой сгруппированы и конвертированы в символы. После этого нужно просто кликнуть правой кнопкой мыши на элементе и выбрать Copy CSS Attributes в выпавшем меню.

Убедитесь, что вы позаботились обо всех нужных префиксах, так как они не включены в код из Sketch. Или же воспользуйтесь специальным пакетом для этого.

HTML

Как и при использовании Bootstrap или Foundation, у нас есть стилизованные элементы. Все, что осталось сделать – добавить класс к элементу в нашем коде HTML.

Здесь нужно превратить элементы в HTML-страничку, которую будут видеть только разработчики из команды. Можно создать страничку элементов с нужным примененным классом, чтобы проверить, как это все выглядит в браузере, на различных экранах.

Брэд Фрост и Дэйв Олсон из Pattern Lab создали отличный пример, посмотрите:

Использование шаблонизаторов

Это бонус для тех, кто освоил шаблонизаторы и CSS, вроде swig, jade, haml и множество других языков, доступных сегодня.

Множество организмов, которые мы создали, станут частичными шаблонами (partials), как только конвертируются в код.

Мы сделали это

Теперь можно притвориться, будто вы разбираетесь в науке. И до определенной степени, вы таки разбираетесь в этом. Atomic Design – это наука высококачественного дизайна.

Создавая модульные, повторяемые элементы и паттерны мы можем экспоненциально ускорить процесс дизайна и разработки. И ускорение затрагивает не только саму отрисовку элементов, а и процесс внесения изменения по всему проекту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

Оказалось, во многих сферах деятельности, таких как промышленный дизайн и архитектура, гибкие модулярные системы использовались для производства очень сложных объектов: самолетов, кораблей и небоскребов. Однако, в своих изысканиях я то и дело возвращался к миру природы… И это напомнило мне, как я сидел за шатающейся партой на уроке химии в школе.

Используем подсказки из химии

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

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

Пример химического уравнения, в котором атомы водорода объединяются с кислородом и образуют молекулы воды.

Химические уравнения демонстрируют химические реакции. Часто такой реакцией становится объединение атомов элементов для образования молекул. В приведенном выше примере мы видим, как водород и кислород объединяются и образуют молекулы воды.

В природе атомы объединяются для образования молекул. Молекулы в дальнейшем могут объединиться и образовать относительно сложные организмы . Давайте рассмотрим это подробнее:

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

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

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

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

Периодическая таблица химических элементов.

По-видимому, план мистера Рея, заключавшийся в том, чтобы заставить школьников щелкать химические уравнения, как орешки, в итоге сработал: я возвращаюсь к этому спустя столько лет, чтобы черпать вдохновение для проектирования интерфейсов.

Методология атомарного дизайна

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

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

Периодическая таблица HTML-элементов Джоша Дака.

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

Да здравствует атомарный дизайн!

Атомарный дизайн - это методология, состоящая из пяти независимых этапов, которые направлены на создание более продуманных и последовательных систем проектирования интерфейсов. Вот эти пять этапов атомарного дизайна:

Атомы
Молекулы
Организмы
Шаблоны
Страницы

Атомарный дизайн состоит из атомов, молекул, организмов, шаблонов и страниц, которые вместе создают эффективные системы проектирования интерфейсов.

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