Објашњавамо шта је Atomic Design — методологија пројектовања интерфејса, коју је предложио Бред Фрост 2013. године, која позајмљује метафору атома, молекула и организама за изградњу хијерархије UI компоненти. За разлику од приступа заснованог на страницама, где се интерфејс пројектује екранима, Atomic Design дели UI на најмање елементе који се могу поново користити (атоме) и од њих гради сложеније структуре. Према Бреду Фросту (2016), методологија се користи у дизајн системима 67% великих компанија, укључујући IBM, Airbnb и Google.
Главно
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-а решава свој задатак и има строгу област одговорности. Атоми — најмањи градивни блокови интерфејса, који се не могу даље разбити без губитка смисла: дугме, текстуално поље, икона, ознака, поље за потврду. Атоми не садрже пословну логику и не зависе од контекста. Они дефинишу основне визуелне карактеристике: боју, величину, размаке, типографију.
Молекули — комбинације два или више атома, које формирају једноставне функционалне јединице. Поље за унос са ознаком и поруком о грешци — молекул. Картица производа са сликом, називом и ценом — молекул. Молекули могу садржати основну логику (прикажи/сакриј грешку), али не садрже пословне процесе. Молекули су први ниво на коме компоненте постају поновно употребљиве између различитих екрана.
Организми — сложени блокови интерфејса, састављени од молекула и атома, који реализују конкретну функцију апликације. Формулар за пријаву (поље за е-пошту, поље за лозинку, дугме за слање, веза „заборавио сам лозинку") — организам. Заглавље са логотипом, претрагом и навигацијом — организам. Организми могу садржати пословну логику и обраћати се API-ју, али само у оквиру своје функције.
Шаблони — окири страница, који одређују распоред организама на екрану без конкретног садржаја. Шаблон дефинише мрежу, колоне, зоне за садржај — оквирни распоред на нивоу кода. Шаблони не садрже податке, само чуваре места. Они омогућавају процену структуре странице пре попуњавања садржајем.
Странице — конкретни екрани апликације, где је шаблон испуњен стварним подацима. На овом нивоу се проверава како компоненте изгледају са стварним садржајем (дуги редови, недостатак података, грешке). Странице су једини ниво који види крајњи корисник. Промене на нивоу страница не би требале да утичу на атоме, молекуле и организме — ако компоненту треба изменити, промена се уноси на њеном нивоу, а страница је аутоматски преузима.
Предности 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 (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) који се могу поново користити у свим функцијама.
Jetpack Compose и SwiftUI природно подржавају хијерархију Atomic Design-а кроз композицију компоненти. Атоми у Compose-у — основне @Composable функције: AppButton, AppTextField, AppCheckbox. Свака функција прима параметре прилагођавања (боју, величину, стање) и не садржи пословну логику. Атоми се дефинишу у shared слоју и извозе као UI-kit.
Молекули — @Composable функције које комбинују више атома: LabeledTextField (ознака + поље за унос + порука о грешци), ProductCard (слика + назив + цена). Молекули могу садржати основно стање (валидност поља), али не приступају API-ју или ViewModel-у. Они се поново користе у различитим организмима.
Организми — @Composable функције на нивоу функције: LoginForm (LabeledTextField за е-пошту + LabeledTextField за лозинку + AppButton за слање + веза за опоравак). Организми раде са ViewModel-ом кроз Intent функције и могу садржати пословну логику. У SwiftUI-ју се слична хијерархија гради кроз @ViewBuilder и прилагођене View структуре.
У SwiftUI-ју атом — прилагођена View структура AppButton, молекул — поље за унос са ознаком на HStack, организам — формулар за пријаву. Таква структура омогућава поновно коришћење компоненти на свим екранима — промена атома (боја дугмета) се аутоматски примењује на све екране. Комбинација Atomic Design-а са системом дизајна гарантује конзистентност интерфејса без ручне контроле сваког екрана.
Често постављана питања
Пет нивоа су препорука, а не закон. Многи дизајн системи (Material Design, IBM Carbon) користе 3 или 4 нивоа: основне компоненте, сложене компоненте и шаблоне. Главно правило — свака компонента припада једном нивоу и може се поново користити на следећим нивоима. Ако видите да се нивои „молекул" и „организам" у вашем пројекту не разликују — спојите их. Атоми и странице су једини обавезни нивои.
Атоми се тестирају визуелно (SnapShot тестови, Compose Preview) — проверава се да ли дугме са задатим својствима исправно приказује. Молекули се тестирају као комбинација атома — проверава се стање (грешка, успех, онемогућено). Организми захтевају интеграционе тестове — проверава се интеракција са ViewModel-ом (слање формулара, учитавање података). У IT Sectr-у користимо Compose Test за Android и XCTest за iOS; за визуелно тестирање — Paparazzi (Android) и SnapshotTesting (iOS).
Може, али ефикасност опада. Без система дизајна и дизајн токена, атоми немају јединствени стил — сваки програмер ствара своје атоме са произвољним бојама и размацима, што доводи до визуелног нереда. Atomic Design и систем дизајна — комплементарни концепти: Atomic Design поставља хијерархију, систем дизајна — визуелни језик. Препоручује се имплементација заједно: прво дизајн токени (боје, типографија, размаци), затим атоми, па молекули и организми.
„Атомска зона" — ситуација када број атома прелази разумне границе (100+), а проналажење потребне компоненте траје дуже него писање од нуле. Решење — колокација атома по функцијама: атом који користи само једна функција чувати унутар те функције, а не у shared-у. У shared се износе само глобални атоми (Button, Text, Input). Према Бреду Фросту, колокација смањује број shared атома за 60–70% без губитка поновне употребе.
Atomic Design је првобитно методологија пројектовања интерфејса (design), али се у савременој пракси користи и за организацију кода (code). У алатима за дизајн (Figma, Sketch) атоми су компоненте библиотеке; у коду — функције и класе. Методологија не прави разлику између design и code — атом је исти и у макету и у имплементацији. У IT Sectr-у користимо supernova.io за синхронизацију дизајн атома и код атома, што елиминише одступање између макета и готовог интерфејса.
Завршни закључци
Развићемо мобилну апликацију под кључ
IT Sectr креира iOS и Android апликације за стартапе и предузећа од 2017. године. Саветоваћемо вас и предложити најбоље решење.
Прочитајте такође