Atomic Design — fundamentals, atoms, molecules and organisms in UI

What is Atomic Design?

Atomic Design is a methodology for creating hierarchical interface systems, where each UI element belongs to one of five levels: atoms (basic elements), molecules (combinations of atoms), organisms (complex blocks), templates (page wireframes) and pages (specific screens with data). The analogy is borrowed from chemistry: atoms combine into molecules, molecules into organisms, organisms into templates, templates are filled with content and become pages.

The methodology was proposed by web designer Brad Frost in 2013 as a response to the problem of "page thinking" — when each new screen is designed from scratch without considering existing components. In the book "Atomic Design" (2016), Frost describes the implementation of the methodology in projects of large companies: IBM, GE, Starbucks. According to Nielsen Norman Group (2022), Atomic Design reduces the time for designing new screens by 30–50% through the reuse of ready-made components.

Atomic Design is not so much a technology as a philosophy of UI organization. It is not tied to a specific framework and is applicable both in web (React, Vue) and mobile development (Jetpack Compose, SwiftUI). At IT Sectr, we use Atomic Design to build design systems for clients: we identify atomic components at the design stage and transfer them into code components in Compose/SwiftUI.

Five levels: atoms, molecules, organisms, templates, pages

Each level of Atomic Design solves its own problem and has a strict area of responsibility. Atoms are the smallest building blocks of the interface that cannot be broken down further without losing meaning: button, text field, icon, label, checkbox. Atoms contain no business logic and do not depend on context. They define basic visual characteristics: color, size, spacing, typography.

Molecules are combinations of two or more atoms that form simple functional units. An input field with a label and an error message is a molecule. A product card with an image, name, and price is a molecule. Molecules can contain basic logic (show/hide error), but do not contain business processes. Molecules are the first level at which components become reusable across different screens.

Organisms are complex interface blocks consisting of molecules and atoms that implement a specific application function. A login form (email field, password field, submit button, "forgot password" link) is an organism. A header with logo, search, and navigation is an organism. Organisms can contain business logic and access the API, but only within their function.

Templates are page wireframes that define the arrangement of organisms on the screen without specific content. A template defines the grid, columns, content areas — a wireframe at the code level. Templates contain no data, only placeholders. They allow evaluating the page structure before filling it with content.

Pages are specific application screens where the template is filled with real data. At this level, it is verified how components look with real content (long strings, missing data, errors). Pages are the only level that the end user sees. Changes at the page level should not affect atoms, molecules, and organisms — if a component needs to be changed, the change is made at its level, and the page automatically picks it up.

Benefits and limitations of Atomic Design

Benefits of Atomic Design become apparent when scaling interfaces. A single component library guarantees visual consistency: a button looks the same on all screens because it is the same atom. According to Brad Frost (2016), companies that implemented Atomic Design reduce the time for developing new screens by 30–50% through reuse of ready-made molecules and organisms.

Limitations — Atomic Design does not describe how to manage application state. The methodology only answers the question "how to organize UI components" but does not address business logic, routing, or data management. The second limitation is the difficulty of defining boundaries: where does a molecule end and an organism begin? In practice, boundaries are blurred, and different teams may classify the same component differently. It is recommended to establish rules in design tokens and a component catalog (Storybook, Jetpack Compose Preview).

The third limitation is excessive abstraction for small projects. If an application consists of 5 screens, creating a hierarchy of atoms and molecules is unnecessary work. Atomic Design becomes beneficial when the number of screens exceeds 20 and components are reused across different pages.

Atomic Design vs Feature-Sliced Design

Atomic Design and Feature-Sliced Design (FSD) solve different problems and can be used together. Atomic Design is a methodology for organizing UI components, FSD is a methodology for organizing business layers and the application as a whole. Atomic Design answers the question "how to break UI into reusable parts", FSD answers "how to organize code around business features". They are not competing: you can have an FSD structure with features and entities layers, and within each layer use Atomic Design for organizing UI components.

Typical combination: FSD defines the modular structure of the application (layers, slices), Atomic Design defines the internal structure of UI components within each slice. For example, the feature.auth slice contains molecules (LoginForm, PasswordInput) and organisms (AuthPage) assembled according to Atomic Design rules. The shared layer contains atoms (Button, Input, Label) reused across all features.

Atomic Design in mobile applications: Compose and SwiftUI

Jetpack Compose and SwiftUI naturally support the Atomic Design hierarchy through component composition. Atoms in Compose are basic @Composable functions: AppButton, AppTextField, AppCheckbox. Each function accepts customization parameters (color, size, state) and contains no business logic. Atoms are defined in the shared layer and exported as a UI-kit.

Molecules are @Composable functions that combine several atoms: LabeledTextField (label + input field + error message), ProductCard (image + name + price). Molecules can contain basic state (field validity) but do not access the API or ViewModel. They are reused across different organisms.

Organisms are @Composable functions at the feature level: LoginForm (LabeledTextField for email + LabeledTextField for password + submit AppButton + recovery link). Organisms work with ViewModel through Intent functions and can contain business logic. In SwiftUI, a similar hierarchy is built through @ViewBuilder and custom View structures.

In SwiftUI, an atom is a custom View structure AppButton, a molecule is an input field with a label on HStack, an organism is a login form. This structure allows reusing components across all screens — changing an atom (button color) automatically applies to all screens. The combination of Atomic Design with a design system guarantees interface consistency without manual control of each screen.