Atomic Design — podstawy, atomy, molekuły i organizmy w UI

Czym jest Atomic Design?

Atomic Design — metodologia tworzenia hierarchicznych systemów interfejsów, w której każdy element UI należy do jednego z pięciu poziomów: atomy (podstawowe elementy), molekuły (kombinacje atomów), organizmy (złożone bloki), szablony (szkielety stron) i strony (konkretne ekrany z danymi). Analogia zaczerpnięta z chemii: atomy łączą się w molekuły, molekuły — w organizmy, organizmy — w szablony, szablony wypełniane treścią stają się stronami.

Metodologia została zaproponowana przez projektanta stron internetowych Brada Frosta w 2013 roku jako odpowiedź na problem „myślenia stronicowego" — gdy każdy nowy ekran jest projektowany od zera, bez uwzględnienia istniejących już komponentów. W książce „Atomic Design" (2016) Frost opisuje wdrożenie metodologii w projektach dużych firm: IBM, GE, Starbucks. Według Nielsen Norman Group (2022), Atomic Design skraca czas projektowania nowych ekranów o 30–50% dzięki wielokrotnemu użyciu gotowych komponentów.

Atomic Design — to nie tyle technologia, co filozofia organizacji UI. Nie jest przywiązana do konkretnego frameworka i ma zastosowanie zarówno w sieci (React, Vue), jak i w programowaniu mobilnym (Jetpack Compose, SwiftUI). W IT Sectr używamy Atomic Design do budowy systemów projektowych klientów: wyodrębniamy komponenty atomarne na etapie projektowania i przenosimy je do komponentów kodu Compose/SwiftUI.

Pięć poziomów: atomy, molekuły, organizmy, szablony, strony

Każdy poziom Atomic Design rozwiązuje swoje zadanie i ma ścisły zakres odpowiedzialności. Atomy — najmniejsze bloki budowlane interfejsu, których nie można dalej podzielić bez utraty sensu: przycisk, pole tekstowe, ikona, etykieta, pole wyboru. Atomy nie zawierają logiki biznesowej i nie zależą od kontekstu. Określają podstawowe cechy wizualne: kolor, rozmiar, odstępy, typografię.

Molekuły — kombinacje dwóch lub więcej atomów, tworzące proste jednostki funkcjonalne. Pole wejściowe z etykietą i komunikatem o błędzie — molekuła. Karta produktu z obrazkiem, nazwą i ceną — molekuła. Molekuły mogą zawierać podstawową logikę (pokaż/ukryj błąd), ale nie zawierają procesów biznesowych. Molekuły to pierwszy poziom, na którym komponenty stają się wielokrotnego użytku między różnymi ekranami.

Organizmy — złożone bloki interfejsu, składające się z molekuł i atomów, realizujące konkretną funkcję aplikacji. Formularz logowania (pole email, pole hasła, przycisk wysyłania, link „nie pamiętam hasła") — organizm. Nagłówek z logo, wyszukiwarką i nawigacją — organizm. Organizmy mogą zawierać logikę biznesową i odwoływać się do API, ale tylko w ramach swojej funkcji.

Szablony — szkielety stron, określające rozmieszczenie organizmów na ekranie bez konkretnej treści. Szablon definiuje siatkę, kolumny, strefy treści — wireframe na poziomie kodu. Szablony nie zawierają danych, tylko placeholdery. Pozwalają ocenić strukturę strony przed wypełnieniem treścią.

Strony — konkretne ekrany aplikacji, gdzie szablon jest wypełniony rzeczywistymi danymi. Na tym poziomie sprawdza się, jak komponenty wyglądają z rzeczywistą treścią (długie ciągi znaków, brak danych, błędy). Strony to jedyny poziom widoczny dla użytkownika końcowego. Zmiany na poziomie stron nie powinny wpływać na atomy, molekuły i organizmy — jeśli komponent wymaga zmiany, zmiana jest wprowadzana na jego poziomie, a strona przejmuje ją automatycznie.

Zalety i ograniczenia Atomic Design

Zalety Atomic Design ujawniają się podczas skalowania interfejsów. Jednolita biblioteka komponentów gwarantuje spójność wizualną: przycisk wygląda tak samo na wszystkich ekranach, ponieważ to ten sam atom. Według Brada Frosta (2016), firmy, które wdrożyły Atomic Design, skracają czas tworzenia nowych ekranów o 30–50% dzięki wielokrotnemu użyciu gotowych molekuł i organizmów.

Ograniczenia — Atomic Design nie opisuje, jak zarządzać stanem aplikacji. Metodologia odpowiada tylko na pytanie „jak zorganizować komponenty UI", ale nie dotyka logiki biznesowej, routingu, pracy z danymi. Drugie ograniczenie — trudność określenia granic: gdzie kończy się molekuła, a zaczyna organizm? W praktyce granice są rozmyte, a różne zespoły mogą klasyfikować ten sam komponent inaczej. Zaleca się ustalenie zasad w tokenach projektowych i katalogu komponentów (Storybook, Jetpack Compose Preview).

Trzecie ograniczenie — nadmierna abstrakcja dla małych projektów. Jeśli aplikacja składa się z 5 ekranów, tworzenie hierarchii atomów i molekuł to zbędna praca. Atomic Design staje się opłacalny, gdy liczba ekranów przekracza 20, a komponenty są wykorzystywane na różnych stronach.

Atomic Design a Feature-Sliced Design

Atomic Design i Feature-Sliced Design (FSD) rozwiązują różne zadania i mogą być używane razem. Atomic Design to metodologia organizacji komponentów UI, FSD — metodologia organizacji warstw biznesowych i całej aplikacji. Atomic Design odpowiada na pytanie „jak podzielić UI na wielokrotnego użytku części", FSD — „jak zorganizować kod wokół funkcji biznesowych". Nie konkurują: można mieć strukturę FSD z warstwami features i entities, a wewnątrz każdej warstwy używać Atomic Design do organizacji komponentów UI.

Typowe połączenie: FSD definiuje modułową strukturę aplikacji (warstwy, plasterki), Atomic Design — wewnętrzną strukturę komponentów UI wewnątrz każdego plasterka. Na przykład, plaster feature.auth zawiera molekuły (LoginForm, PasswordInput) i organizmy (AuthPage), zbudowane według zasad Atomic Design. Warstwa shared zawiera atomy (Button, Input, Label), wielokrotnego użytku we wszystkich funkcjach.

Atomic Design w aplikacjach mobilnych: Compose i SwiftUI

Jetpack Compose i SwiftUI w naturalny sposób wspierają hierarchię Atomic Design poprzez kompozycję komponentów. Atomy w Compose — podstawowe funkcje @Composable: AppButton, AppTextField, AppCheckbox. Każda funkcja przyjmuje parametry dostosowania (kolor, rozmiar, stan) i nie zawiera logiki biznesowej. Atomy są definiowane w warstwie shared i eksportowane jako UI-kit.

Molekuły — funkcje @Composable łączące kilka atomów: LabeledTextField (etykieta + pole wejściowe + komunikat o błędzie), ProductCard (obrazek + nazwa + cena). Molekuły mogą zawierać podstawowy stan (poprawność pola), ale nie odwołują się do API ani ViewModel. Są wielokrotnego użytku w różnych organizmach.

Organizmy — funkcje @Composable na poziomie funkcji: LoginForm (LabeledTextField dla email + LabeledTextField dla hasła + AppButton wysyłania + link odzyskiwania). Organizmy współpracują z ViewModel poprzez funkcje Intent i mogą zawierać logikę biznesową. W SwiftUI analogiczna hierarchia budowana jest przez @ViewBuilder i niestandardowe struktury View.

W SwiftUI atom — niestandardowa struktura View AppButton, molekuła — pole wejściowe z etykietą na HStack, organizm — formularz logowania. Taka struktura pozwala na wielokrotne użycie komponentów na wszystkich ekranach — zmiana atomu (kolor przycisku) automatycznie stosuje się do wszystkich ekranów. Połączenie Atomic Design z systemem projektowym gwarantuje spójność interfejsu bez ręcznej kontroli każdego ekranu.