Atomic Design — основы, атомы, молекулы и организмы в UI

Что такое Atomic Design?

Atomic Design — методология создания иерархических систем интерфейсов, в которой каждый элемент UI принадлежит одному из пяти уровней: атомы (базовые элементы), молекулы (комбинации атомов), организмы (сложные блоки), шаблоны (каркасы страниц) и страницы (конкретные экраны с данными). Аналогия заимствована из химии: атомы объединяются в молекулы, молекулы — в организмы, организмы — в шаблоны, шаблоны наполняются контентом и становятся страницами.

Методология была предложена веб-дизайнером Брэдом Фростом в 2013 году как ответ на проблему «страничного мышления» — когда каждый новый экран проектируется с нуля, без учёта уже существующих компонентов. В книге «Atomic Design» (2016) Фрост описывает внедрение методологии в проекты крупных компаний: IBM, GE, Starbucks. По данным Nielsen Norman Group (2022), Atomic Design сокращает время проектирования новых экранов на 30–50% за счёт переиспользования готовых компонентов.

Atomic Design — не столько технология, сколько философия организации UI. Она не привязана к конкретному фреймворку и применима как в вебе (React, Vue), так и в мобильной разработке (Jetpack Compose, SwiftUI). В IT Sectr мы используем Atomic Design для построения дизайн-систем заказчиков: выделяем атомарные компоненты на этапе дизайна и переносим их в code-компоненты Compose/SwiftUI.

Пять уровней: атомы, молекулы, организмы, шаблоны, страницы

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

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

Организмы — сложные блоки интерфейса, состоящие из молекул и атомов, реализующие конкретную функцию приложения. Форма логина (поле email, поле пароля, кнопка отправки, ссылка «забыл пароль») — организм. Хидер с логотипом, поиском и навигацией — организм. Организмы могут содержать бизнес-логику и обращаться к API, но только в рамках своей функции.

Шаблоны — каркасы страниц, определяющие расположение организмов на экране без конкретного контента. Шаблон задаёт сетку, колонки, зоны для контента — wireframe на уровне кода. Шаблоны не содержат данных, только placeholder-ы. Они позволяют оценить структуру страницы до наполнения контентом.

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

Преимущества и ограничения Atomic Design

Преимущества Atomic Design проявляются при масштабировании интерфейсов. Единая библиотека компонентов гарантирует визуальную консистентность: кнопка выглядит одинаково на всех экранах, потому что это один и тот же атом. По данным Brad Frost (2016), компании, внедрившие Atomic Design, сокращают время разработки новых экранов на 30–50% за счёт переиспользования готовых молекул и организмов.

Ограничения — Atomic Design не описывает, как управлять состоянием приложения. Методология отвечает только на вопрос «как организовать UI-компоненты», но не затрагивает бизнес-логику, роутинг, работу с данными. Второе ограничение — сложность определения границ: где заканчивается молекула и начинается организм? На практике границы размыты, и разные команды могут классифицировать один компонент по-разному. Рекомендуется зафиксировать правила в дизайн-токенах и компонентном каталоге (Storybook, Jetpack Compose Preview).

Третье ограничение — избыточная абстракция для маленьких проектов. Если приложение состоит из 5 экранов, создание иерархии атомов и молекул — лишняя работа. Atomic Design становится выгодным, когда число экранов превышает 20, а компоненты переиспользуются на разных страницах.

Atomic Design против Feature-Sliced Design

Atomic Design и Feature-Sliced Design (FSD) решают разные задачи и могут использоваться совместно. Atomic Design — методология организации UI-компонентов, FSD — методология организации бизнес-слоёв и приложения в целом. Atomic Design отвечает на вопрос «как разбить UI на переиспользуемые части», FSD — «как организовать код вокруг бизнес-фич». Они не конкурируют: можно иметь FSD-структуру с слоями features и entities, а внутри каждого слоя использовать Atomic Design для организации UI-компонентов.

Типичное сочетание: FSD определяет модульную структуру приложения (слои, слайсы), Atomic Design — внутреннюю структуру UI-компонентов внутри каждого слайса. Например, слайс feature.auth содержит молекулы (LoginForm, PasswordInput) и организмы (AuthPage), собранные по правилам Atomic Design. Shared-слой содержит атомы (Button, Input, Label), переиспользуемые во всех фичах.

Atomic Design в мобильных приложениях: Compose и SwiftUI

Jetpack Compose и SwiftUI естественным образом поддерживают иерархию Atomic Design через композицию компонентов. Атомы в Compose — базовые @Composable-функции: AppButton, AppTextField, AppCheckbox. Каждая функция принимает параметры кастомизации (цвет, размер, состояние) и не содержит бизнес-логики. Атомы определяются в shared-слое и экспортируются как UI-kit.

Молекулы — @Composable-функции, комбинирующие несколько атомов: LabeledTextField (лейбл + поле ввода + сообщение об ошибке), ProductCard (изображение + название + цена). Молекулы могут содержать базовое состояние (валидность поля), но не обращаются к API или ViewModel. Они переиспользуются в разных организмах.

Организмы — @Composable-функции уровня фичи: LoginForm (LabeledTextField для email + LabeledTextField для пароля + AppButton отправки + ссылка восстановления). Организмы работают с ViewModel через Intent-функции и могут содержать бизнес-логику. В SwiftUI аналогичная иерархия строится через @ViewBuilder и кастомные View-структуры.

В SwiftUI атом — кастомная View-структура AppButton, молекула — поле ввода с лейблом на HStack, организм — форма логина. Такая структура позволяет переиспользовать компоненты на всех экранах — изменение атома (цвет кнопки) автоматически применяется ко всем экранам. Сочетание Atomic Design с дизайн-системой гарантирует консистентность интерфейса без ручного контроля каждого экрана.