Атомарный дизайн: методология создания масштабируемых интерфейсов

Атомарный дизайн появился в 2013 году: 10 июня американский веб-дизайнер Брэд Фрост опубликовал пост «Atomic Design», где предложил собирать интерфейсы из пяти уровней по аналогии с химией. Его главная мысль: «Мы проектируем не страницы, а системы компонентов». В 2016 году идея выросла в книгу, её полная версия открыта онлайн. В октябре 2025 года W3C Design Tokens Community Group выпустила первую стабильную версию спецификации дизайн-токенов (2025.10). Так у «субатомного» слоя методологии появился общий формат обмена между дизайном и кодом.

Зачем это бизнесу, видно по любому продукту, который прожил пару лет без системы. Кнопки везде немного разные, в макетах 14 оттенков серого, а одну форму заявки приходится править вручную в 30 файлах. Каждая такая мелочь стоит часов дизайнера и разработчика, и со временем их становится только больше. Мы в YuSMP Group ведём проектирование интерфейсов и дизайн-систем по атомарной методологии. Поэтому в этой статье делимся тем, как она работает на реальных проектах, а не только в теории.

Ниже разберём пять уровней атомарного дизайна с примерами и сравнительной таблицей. Покажем, как разложить реальный экран интернет-магазина на атомы, и дадим пошаговый план внедрения. Отдельно поговорим о связи с Figma и кодом (React/Vue, Storybook, дизайн-токены). Честно расскажем, когда методология не нужна, чем она отличается от UI-kit и дизайн-системы и какие ошибки чаще всего встречаются при переходе.

Что такое атомарный дизайн

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

Название взято из химии. Всё вещество во вселенной состоит из ограниченного набора атомов, которые соединяются в молекулы, а те — в сложные организмы. Фрост перенёс эту модель на веб: у интерфейса тоже есть «таблица Менделеева» из базовых элементов, и всё многообразие экранов получается из их комбинаций. Во второй главе своей книги он подчёркивает, что пять стадий идут не строго по очереди. Это ментальная модель, которая помогает одновременно видеть интерфейс и как целое, и как набор частей.

Здесь важна одна мысль: атомарный дизайн — это не набор файлов и не конкретная программа, а способ думать. Команда перестаёт рисовать каждую страницу с нуля и начинает проектировать систему компонентов. Из неё страницы собираются как из конструктора: быстро, предсказуемо и в одном стиле. Отсюда и главный тезис методологии: мы проектируем системы, а не страницы.

Из чего состоит атомарный дизайн: 5 уровней

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

Атомы

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

В современной практике под атомами выделяют ещё один, «субатомный» слой — дизайн-токены. Токен — это именованное значение вроде color.brand.primary или space.md, которое атомы используют вместо «зашитых» цифр. Меняете значение токена — и оно обновляется во всех атомах, а через них в каждом компоненте продукта.

Молекулы

Молекулы — это простые группы атомов, которые вместе выполняют одну задачу. Классический пример — поле поиска: лейбл, инпут и кнопка «Найти». По отдельности это три атома, вместе — законченный функциональный блок. Другие примеры молекул: строка «иконка + текст», поле формы с подсказкой и сообщением об ошибке, блок цены со старой и новой суммой.

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

Организмы

Организмы — это относительно сложные, самостоятельные секции интерфейса, собранные из молекул и атомов. Типичные организмы: шапка сайта (логотип, навигация, поиск, корзина), карточка товара, форма оформления заказа, футер, блок отзывов. Организм уже можно показать пользователю как законченную часть страницы.

Один и тот же организм может выглядеть по-разному в зависимости от контекста. Например, карточка товара бывает в сетке каталога, в списке избранного и в блоке «С этим товаром покупают». Строятся все варианты из одних и тех же молекул, поэтому остаются визуально согласованными.

Шаблоны

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

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

Страницы

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

Главная ценность этого уровня — проверка крайних случаев. Что будет, если название товара займёт три строки? Если у пользователя очень длинная фамилия? Если в корзине пусто или в каталоге 2 000 позиций? Проблемы, найденные на страницах, возвращают дизайнера к шаблонам и компонентам, и система становится устойчивее.

Уровень	Что это	Пример в интернет-магазине	Где живёт (Figma / код)
Атомы	Неделимые элементы и базовые стили	Кнопка «В корзину», иконка сердечка, цвет цены, шрифт заголовка	Библиотека компонентов и токены / atoms/, файл токенов
Молекулы	Группа атомов с одной функцией	Поле поиска, блок цены со скидкой, счётчик количества	Компоненты с вариантами / molecules/
Организмы	Самостоятельная секция интерфейса	Шапка с поиском и корзиной, карточка товара, фильтры каталога	Составные компоненты / organisms/
Шаблоны	Каркас страницы без контента	Макет страницы каталога: фильтры слева, сетка карточек, пагинация	Фреймы-шаблоны / templates/, layout-компоненты
Страницы	Шаблон с реальным контентом	Каталог «Кроссовки» с настоящими товарами, ценами и отзывами	Экраны макета / pages/, маршруты приложения

Как разобрать реальный экран по атомарной модели

Разобрать экран по атомарной модели — значит пройти его снизу вверх и назвать каждый элемент его уровнем. Возьмём типичный экран каталога интернет-магазина с карточками товаров и посмотрим, из чего он состоит.

• Атомы. Кнопка «В корзину» (обычное, наведённое, нажатое и неактивное состояние), иконка «в избранное», бейдж «−20%», изображение товара, текстовые стили для названия и цены, звёздочка рейтинга. Под ними лежат токены: брендовый цвет, акцентный цвет скидки, отступ 16 px, радиус 12 px.
• Молекулы. Блок цены (новая цена + зачёркнутая старая), рейтинг (пять звёзд + число отзывов), селектор количества (минус, число, плюс), поле поиска в шапке.
• Организм. Карточка товара. Она объединяет фото, бейдж, название, рейтинг, блок цены и кнопку. Рядом другие организмы экрана: шапка, панель фильтров, футер.
• Шаблон. Каркас каталога: шапка сверху, фильтры в левой колонке, сетка из 3–4 карточек в ряд, пагинация снизу. На мобильном фильтры уходят в выдвижную панель, а сетка становится двухколоночной.
• Страница. Раздел «Кроссовки» с реальными товарами. Здесь выясняется, что длинное название модели ломает высоту карточек, и в компонент добавляют ограничение в две строки с многоточием.

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

Зачем бизнесу атомарный дизайн: преимущества

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

• Скорость сборки новых экранов. Когда библиотека компонентов готова, новый экран собирается из существующих организмов. Дизайнер не рисует кнопки и формы заново, а решает задачу пользователя.
• Консистентность. Одна кнопка — один компонент. Пользователь везде видит одинаковые элементы, которые одинаково себя ведут, и быстрее осваивает продукт.
• Дешёвая правка. В Figma изменение главного компонента автоматически обновляет все его экземпляры (подробнее в справке Figma о компонентах). В коде то же даёт общий компонент в библиотеке: одна правка вместо ручного поиска по всем файлам.
• Понятный handoff разработчикам. Когда структура в Figma совпадает со структурой в коде, разработчик видит не «картинку», а набор уже знакомых компонентов с состояниями. Вопросов и расхождений становится заметно меньше.
• Масштабирование команды. Новый дизайнер или фронтенд-разработчик быстрее входит в проект: вместо сотни уникальных макетов ему нужно изучить библиотеку и правила её использования.
• Доступность закладывается один раз. Требования WCAG 2.2 к контрасту, размеру цели касания и видимому фокусу проверяются на уровне атомов. Если кнопка доступна, она доступна во всём продукте.

По нашему опыту, самый заметный эффект бизнес чувствует на втором-третьем релизе. Дорабатывать продукт становится быстрее, а визуальный «дрейф» между разделами, собранными разными людьми в разное время, практически исчезает.

Когда атомарный дизайн не нужен: минусы и ограничения

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

• Накладные расходы на старте. Первые экраны делаются медленнее: сначала нужно собрать токены, атомы и молекулы, а уже потом страницы. На горизонте 2–3 недель это чистые затраты.
• Одностраничники и промо. Для лендинга под одну акцию, промо-страницы на месяц или сайта-визитки из трёх экранов полноценная атомарная система избыточна. Хватит аккуратного набора стилей.
• Короткий MVP. Если цель — за две недели проверить гипотезу, а продукт может быть переписан с нуля, лучше вложить время в исследование пользователей, а не в идеальную библиотеку.
• Споры о классификации. «Это молекула или организм?» — вопрос, на который команды тратят часы. Фрост сам говорит, что уровни — это ментальная модель, а не строгая таксономия, но в команде без договорённостей споры неизбежны.
• Риск бюрократии. Если любое изменение кнопки требует согласования и нового релиза библиотеки, система начинает тормозить работу вместо ускорения.
• Нужна дисциплина поддержки. Без владельца системы и регулярной ревизии библиотека обрастает дубликатами и устаревшими компонентами, и выгода исчезает.

Практическое правило: если в продукте больше 15–20 уникальных экранов, над ним работают несколько человек и он будет развиваться хотя бы год, атомарный подход окупается. Если нет — можно взять из него только идею токенов и базовых компонентов, не выстраивая полную иерархию.

Как внедрить атомарный дизайн: пошаговый план

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

1. Проведите аудит интерфейса (interface inventory). Соберите скриншоты всех кнопок, полей, карточек, модальных окон и заголовков из текущего продукта и разложите их по группам. Так сразу видно, где у вас 9 вариантов одной кнопки, и становится понятно, с чего начинать унификацию.
2. Зафиксируйте дизайн-токены. Определите палитру, типографическую шкалу, шкалу отступов, радиусы, тени и дайте им смысловые имена: не «синий-500», а «цвет основного действия». Токены — фундамент, на который опираются все остальные уровни.
3. Соберите атомы со всеми состояниями. Для каждого атома опишите состояния: обычное, наведение, фокус, нажатие, неактивное, ошибка, загрузка. Сразу проверьте контраст и размер области касания по WCAG 2.2.
4. Постройте молекулы и организмы. Соберите из атомов типовые блоки: поля форм, карточки, шапку, фильтры. В Figma используйте варианты (variants) и Auto Layout, чтобы компоненты тянулись под контент так же, как в вёрстке.
5. Сделайте шаблоны и проверьте их на реальных страницах. Соберите каркасы ключевых экранов и наполните их настоящим контентом: длинными названиями, пустыми состояниями, большими списками. Всё, что ломается, исправляйте на уровне компонентов.
6. Задокументируйте систему и синхронизируйте её с кодом. Опишите правила применения каждого компонента, договоритесь о версионировании и владельце библиотеки. Передайте токены и компоненты разработчикам, чтобы структура в Figma и в коде совпадала.

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

Атомарный дизайн в Figma

Атомарный дизайн в Figma реализуется через компоненты, варианты и командные библиотеки: главный компонент хранит «эталон» элемента, а его экземпляры на экранах автоматически получают все изменения. Именно поэтому Figma стала основным инструментом для работы по этой методологии. Если вы только знакомитесь с редактором, начните с нашего разбора возможностей Figma.

• Компоненты и экземпляры. Атом (например, кнопка) создаётся как главный компонент. На макетах используются только его экземпляры. В них можно менять текст и иконку, но базовые стили приходят из главного компонента.
• Варианты и свойства компонентов. Все состояния и размеры кнопки — один компонент с вариантами (size, state, type), а не десять отдельных. Свойства компонента (boolean, text, instance swap) позволяют включать иконку или менять подпись без отсоединения экземпляра.
• Auto Layout. Молекулы и организмы собираются на авто-макете, чтобы они вели себя как флекс-контейнеры в вёрстке: растягивались под текст и сохраняли отступы.
• Переменные и стили. Токены хранятся как переменные Figma (цвета, числа) с режимами, например светлая и тёмная тема. Так смена темы или бренда делается переключением режима.
• Командные библиотеки. Атомы, молекулы и организмы публикуются в отдельном файле-библиотеке, который подключён ко всем продуктовым файлам. Обновление библиотеки приходит в проекты через уведомление об обновлениях.

Отдельно договоритесь о наименовании и структуре файла. Удобная схема — префикс уровня в названии компонента: Atoms/Button/Primary, Molecules/SearchField, Organisms/ProductCard. Страницы файла-библиотеки тоже удобно разбить по уровням: «Токены», «Атомы», «Молекулы», «Организмы», «Шаблоны». Тогда новый участник команды находит нужный элемент за секунды, а не листает бесконечный холст.

Как атомарный дизайн связан с кодом

Атомарный дизайн связан с кодом через компонентные фреймворки: в React, Vue или Angular интерфейс и так строится из компонентов, и атомарная иерархия ложится на них почти один к одному. Когда дизайн и код организованы по одной модели, «кнопка в макете» и «кнопка на сайте» становятся одним и тем же элементом, описанным в двух местах по одним правилам.

Типичная структура папок фронтенд-проекта по атомарной модели выглядит так:

src/components/
  atoms/        Button, Input, Icon, Badge
  molecules/    SearchField, PriceBlock, QuantityPicker
  organisms/    Header, ProductCard, CatalogFilters
  templates/    CatalogLayout, CheckoutLayout
  pages/        CatalogPage, ProductPage

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

Для изоляции и документирования компонентов в коде используют Storybook. Каждый атом и молекула получает свою «историю» со всеми состояниями, и их можно проверить отдельно от приложения. Исторически первым инструментом под методологию был Pattern Lab, созданный при участии самого Фроста. Это генератор библиотек паттернов, изначально устроенный по атомарной модели.

Связующее звено между Figma и кодом — дизайн-токены. Спецификация W3C DTCG 2025.10 описывает единый JSON-формат, который понимают инструменты дизайна и сборщики стилей. Токен цвета и отступа в этом формате выглядит так:

{
  "color": {
    "action": { "$type": "color",
      "$value": { "colorSpace": "srgb", "components": [0.357, 0.298, 1], "hex": "#5b4cff" } }
  },
  "space": {
    "md": { "$type": "dimension", "$value": { "value": 16, "unit": "px" } }
  }
}

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

Чем атомарный дизайн отличается от UI-kit и дизайн-системы

Атомарный дизайн — это метод организации интерфейса. UI-kit — набор готовых элементов. Дизайн-система — целый продукт с компонентами, правилами, кодом и документацией. Их часто путают, потому что они тесно связаны: по атомарной методологии обычно и строят UI-kit, который становится ядром дизайн-системы.

Критерий	Атомарный дизайн	UI-kit	Дизайн-система
Что это	Методология, способ мыслить интерфейс уровнями	Набор визуальных элементов интерфейса	Продукт: компоненты, токены, код, правила и документация
Результат	Иерархия компонентов от атомов до страниц	Библиотека кнопок, полей, карточек, иконок	Единый источник правды для дизайна и разработки
Кто использует	Дизайнеры и фронтенд-разработчики при проектировании	В основном дизайнеры	Дизайнеры, разработчики, продакт-менеджеры, контент-команда
Масштаб	Применим к любому проекту как подход	Один продукт или серия макетов	Несколько продуктов, платформ и команд компании

Проще говоря, атомарный дизайн отвечает на вопрос «как организовать», UI-kit — «из чего собирать», а дизайн-система — «как всё это живёт и развивается в компании». Подробнее о составе и пользе набора элементов мы писали в статье «Что такое UI kit», а о том, когда продукту нужна полноценная система, — в материале «Дизайн-система: что это и когда она нужна продукту».

Типичные ошибки при переходе на атомарный дизайн

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

• Слишком мелкое дробление. Каждый отступ и каждая линия оформлены отдельным компонентом. Библиотека разрастается до сотен элементов, в которых сложно ориентироваться. Компонент нужен тогда, когда он реально переиспользуется.
• Атомы без состояний. Кнопка нарисована только в обычном виде, а наведение, фокус, ошибку и загрузку каждый дизайнер дорисовывает сам. В итоге появляются разные версии одного и того же состояния.
• «Почти одинаковые» дубликаты. Card, Card-new, Card-v2, Card-final с разницей в 4 пикселя. Вместо дубликата нужно добавить вариант в существующий компонент или договориться, что разница не нужна.
• Нет токенов, цвета захардкожены. Если цвета и отступы вписаны в компоненты числами, а не токенами, смена бренда или тёмная тема снова превращается в ручную правку всех элементов.
• Дизайн и код живут отдельно. Библиотека в Figma и компоненты во фронтенде развиваются параллельно и расходятся. Нужна общая структура, общие названия и регулярная сверка.
• Нет владельца системы. Когда за библиотеку «отвечают все», не отвечает никто. Нужен человек или небольшая группа, которые принимают изменения, следят за качеством и выпускают версии.
• Попытка перерисовать всё разом. Полная остановка разработки ради «идеальной системы» почти всегда затягивается. Надёжнее итеративная миграция: начать с самых частых компонентов и переводить экраны на новую библиотеку по мере доработок.

Хорошая новость: все эти ошибки исправимы без переделки продукта с нуля. Достаточно провести ревизию библиотеки, слить дубликаты, вынести значения в токены и назначить владельца — и система снова начинает работать на скорость, а не против неё.

Частые вопросы (FAQ)

Кто придумал атомарный дизайн?

Методологию предложил американский веб-дизайнер Брэд Фрост: 10 июня 2013 года он опубликовал пост «Atomic Design», где описал пять уровней интерфейса по аналогии с химией. В 2016 году идея вышла отдельной книгой «Atomic Design», полная версия которой бесплатно доступна онлайн.

Чем атом отличается от молекулы?

Атом — неделимый элемент интерфейса: кнопка, поле ввода, иконка, лейбл, а также цвета и шрифты. Молекула — простая группа атомов, которая вместе выполняет одну задачу. Например, лейбл, поле ввода и кнопка по отдельности — атомы, а вместе они образуют молекулу «поле поиска».

Атомарный дизайн и дизайн-система — одно и то же?

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

Подходит ли атомарный дизайн для небольшого сайта?

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

Как применять атомарный дизайн в Figma?

Атомы создают как главные компоненты, состояния и размеры описывают вариантами, а молекулы и организмы собирают из экземпляров на Auto Layout. Токены хранят в переменных Figma, всё публикуют в командную библиотеку. Компоненты удобно называть с префиксом уровня, например Atoms/Button/Primary.

Нужно ли разработчикам повторять атомарную структуру в коде?

Буквально повторять папки atoms, molecules и organisms не обязательно: многие команды группируют компоненты по фичам. Важно, чтобы компоненты в коде соответствовали компонентам в Figma по составу, названиям и состояниям, а общие значения шли из одних и тех же дизайн-токенов. Тогда дизайн и код не расходятся.

Сколько времени занимает внедрение атомарного дизайна?

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