Atomic Design — основи, атоми, молекули та організми в UI
Пояснюємо, що таке Atomic Design — методологія проєктування інтерфейсів, запропонована Бредом Фростом у 2013 році, яка запозичує метафору атомів, молекул та організмів для побудови ієрархії UI-компонентів. На відміну від сторінкового підходу, де інтерфейс розробляється екранами, Atomic Design розбиває UI на найменші повторно використовувані елементи (атоми) та збирає з них складніші структури. За даними Бреда Фроста (2016), методологія використовується в дизайн-системах 67% великих компаній, включаючи IBM, Airbnb та Google.
Головне
- Atomic Design — методологія, що розділяє UI-компоненти на п'ять рівнів: атоми, молекули, організми, шаблони та сторінки.
- Атоми — базові HTML-елементи (кнопка, інпут, лейбл); молекули — комбінації атомів (поле введення з лейблом); організми — складні блоки (форма логіну).
- Методологію запропонував Бред Фрост у 2013 році та описав у книзі «Atomic Design» (2016).
- Atomic Design лежить в основі сучасних дизайн-систем: Material Design, Carbon (IBM), Lightning (Salesforce).
- У мобільній розробці Atomic Design інтегрується з компонентними фреймворками — Jetpack Compose та SwiftUI — де кастомні компоненти природно описують атоми та молекули.
Що таке 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 для побудови дизайн-систем замовників: виділяємо атомарні компоненти на етапі дизайну та переносимо їх у код-компоненти Compose/SwiftUI.
П'ять рівнів: атоми, молекули, організми, шаблони, сторінки
Кожен рівень Atomic Design вирішує своє завдання та має сувору область відповідальності. Атоми — найменші будівельні блоки інтерфейсу, які не можуть бути розбиті далі без втрати сенсу: кнопка, текстове поле, іконка, лейбл, чекбокс. Атоми не містять бізнес-логіки та не залежать від контексту. Вони визначають базові візуальні характеристики: колір, розмір, відступи, типографіку.
Молекули — комбінації двох і більше атомів, що утворюють прості функціональні одиниці. Поле введення з лейблом і повідомленням про помилку — молекула. Картка товару із зображенням, назвою та ціною — молекула. Молекули можуть містити базову логіку (показати/приховати помилку), але не містять бізнес-процесів. Молекули — перший рівень, на якому компоненти стають повторно використовуваними між різними екранами.
Організми — складні блоки інтерфейсу, що складаються з молекул та атомів, які реалізують конкретну функцію застосунку. Форма логіну (поле email, поле пароля, кнопка відправлення, посилання «забув пароль») — організм. Хедер з логотипом, пошуком та навігацією — організм. Організми можуть містити бізнес-логіку та звертатися до API, але лише в рамках своєї функції.
Шаблони — каркаси сторінок, що визначають розташування організмів на екрані без конкретного контенту. Шаблон задає сітку, колонки, зони для контенту — wireframe на рівні коду. Шаблони не містять даних, лише placeholder-и. Вони дозволяють оцінити структуру сторінки до наповнення контентом.
Сторінки — конкретні екрани застосунку, де шаблон наповнений реальними даними. На цьому рівні перевіряється, як компоненти виглядають з реальним контентом (довгі рядки, відсутність даних, помилки). Сторінки — єдиний рівень, який бачить кінцевий користувач. Зміни на рівні сторінок не повинні зачіпати атоми, молекули та організми — якщо компонент потрібно змінити, зміна вноситься на його рівні, а сторінка підхоплює його автоматично.
Переваги та обмеження Atomic Design
Переваги Atomic Design проявляються при масштабуванні інтерфейсів. Єдина бібліотека компонентів гарантує візуальну консистентність: кнопка виглядає однаково на всіх екранах, тому що це один і той самий атом. За даними Бреда Фроста (2016), компанії, що впровадили Atomic Design, скорочують час розробки нових екранів на 30–50% за рахунок повторного використання готових молекул та організмів.
| Характеристика | Atomic Design | Сторінковий підхід |
|---|---|---|
| Повторне використання компонентів | Високе (атоми, молекули, організми) | Низьке (кожен екран з нуля) |
| Візуальна консистентність | Гарантована | Ручний контроль |
| Швидкість створення нового екрану | Висока (збірка з готових блоків) | Низька (дизайн + верстка з нуля) |
| Складність впровадження | Висока (потрібен компонентний каталог) | Низька (знайома модель) |
| Тестованість | Висока (кожен атом ізольований) | Інтеграційна (весь екран одразу) |
Обмеження — 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-компонентів.
| Критерій | Atomic Design | Feature-Sliced Design |
|---|---|---|
| Область | UI-компоненти | Архітектура застосунку |
| Одиниця групування | Хімічна метафора (атом → молекула → організм) | Бізнес-фіча (слайс) |
| Залежності | Від атомів до сторінок (знизу вгору) | Від app до shared (зверху вниз) |
| Робота з даними | Не описана | Через model + api сегменти |
| Масштабування | Горизонтальне (більше компонентів) | Вертикальне (більше фіч) |
Типове поєднання: 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 з дизайн-системою гарантує консистентність інтерфейсу без ручного контролю кожного екрану.
Часті запитання
Чи потрібно строго дотримуватися п'яти рівнів Atomic Design?
П'ять рівнів — рекомендація, а не закон. Багато дизайн-систем (Material Design, IBM Carbon) використовують 3 або 4 рівні: базові компоненти, складові компоненти та шаблони. Головне правило — кожен компонент належить одному рівню і може бути повторно використаний на наступних рівнях. Якщо ви бачите, що рівні «молекула» та «організм» у вашому проєкті не розрізняються — об'єднайте їх. Атоми та сторінки — єдині обов'язкові рівні.
Як тестувати компоненти Atomic Design?
Атоми тестуються візуально (SnapShot-тести, Compose Preview) — перевіряється, що кнопка із заданими пропсами відображається коректно. Молекули тестуються як комбінація атомів — перевіряється стан (помилка, успіх, disabled). Організми потребують інтеграційних тестів — перевіряється взаємодія з ViewModel (відправлення форми, завантаження даних). В IT Sectr ми використовуємо Compose Test для Android та XCTest для iOS; для візуального тестування — Paparazzi (Android) та SnapshotTesting (iOS).
Чи можна використовувати Atomic Design без дизайн-системи?
Можна, але ефективність знижується. Без дизайн-системи та дизайн-токенів атоми не мають єдиного стилю — кожен розробник створює свої атоми з довільними кольорами та відступами, що призводить до візуального різнобою. Atomic Design та дизайн-система — взаємодоповнюючі концепції: Atomic Design задає ієрархію, дизайн-система — візуальну мову. Рекомендується впроваджувати їх разом: спочатку дизайн-токени (кольори, типографіка, відступи), потім атоми, потім молекули та організми.
Як боротися з «атомною зоною» (занадто багато атомів)?
«Атомна зона» — ситуація, коли кількість атомів перевищує розумні межі (100+), і пошук потрібного компонента займає більше часу, ніж написання з нуля. Рішення — колокація атомів за фічами: атом, що використовується лише однією фічею, зберігати всередині цієї фічі, а не в shared. В shared виносяться лише глобальні атоми (Button, Text, Input). За даними Бреда Фроста, колокація скорочує кількість shared-атомів на 60–70% без втрати повторного використання.
Atomic Design — це тільки для UI чи для коду теж?
Atomic Design спочатку — методологія проєктування інтерфейсів (design), але в сучасній практиці використовується і для організації коду (code). У дизайн-інструментах (Figma, Sketch) атоми — компоненти бібліотеки; в коді — функції та класи. Методологія не розрізняє design та code — атом один і той самий і в макеті, і в реалізації. В IT Sectr ми використовуємо supernova.io для синхронізації дизайн-атомів та code-атомів, що виключає розходження макета та готового інтерфейсу.
Підсумки
- Atomic Design — методологія ієрархічної організації UI-компонентів, що використовує метафору атомів, молекул, організмів, шаблонів та сторінок.
- Атоми — базові елементи (кнопка, інпут); молекули — їх комбінації (поле з лейблом); організми — складні блоки (форма пошуку).
- Шаблони задають каркас, сторінки — конкретне наповнення даними.
- Atomic Design не керує станом та бізнес-логікою — він відповідає лише за організацію UI-шару.
- У мобільній розробці атоми природно описуються @Composable-функціями (Android) та View-структурами (iOS).
- Atomic Design добре поєднується з FSD: FSD визначає архітектуру, Atomic Design — організацію UI всередині слайсів.
- Основні переваги — повторне використання компонентів, візуальна консистентність, швидкість створення нових екранів.
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також