Atomic Design — methodology for building scalable design systems

Atomic Design — methodology for building scalable design systems

Atomic design is a mental model for decomposing interfaces into reusable, composable parts and reassembling them into screens. It is not a folder structure you copy blindly; it is a vocabulary for talking about granularity and composition so designers and engineers agree on what a "component" is and where it lives. Use it to make a design system legible, not to satisfy a taxonomy.

The core insight: interfaces are not pages, they are systems of components. Build the system, and pages fall out of it. The five stages give you a shared language for the spectrum from raw style primitive to fully-composed screen.

The five stages

Atoms

The irreducible primitives. An atom has a single responsibility and no internal layout decisions about other components. A Button is an atom; a button with an icon and a dropdown is not. Atoms are where your design tokens become visible — an atom is the smallest place a color, font size, radius, or spacing token gets applied.

Litmus test: if removing a child element changes what the thing fundamentally is, you've gone below the atom. A label without its text is still a label; a search field without its input is no longer a search field.

Molecules

Atoms doing one job together. The classic example is a search form: a label atom + input atom + button atom become a SearchField molecule. Molecules are the "do one thing well" layer — they encapsulate a small interaction (enter a query, toggle a setting, pick a date) and become genuinely reusable. Most of your useful reusable components live here and at the organism level.

Organisms

Distinct, recognizable sections of an interface. A Header organism might contain a logo atom, a SearchField molecule, and a NavList molecule. Organisms can contain other organisms. They are where layout, responsive behavior, and meaningful state (loading, empty, error) tend to concentrate. On native platforms, a BottomTabBar or a NavigationStack header is an organism.

Templates

Templates strip out real content and show structure: where the header goes, how the grid flows, what stacks on mobile. They are the design-system equivalent of a wireframe made of real organisms. Templates answer "how is this page laid out and how does it reflow?" without committing to copy or data. In code, a template is often a layout component or a route's skeleton (e.g. a Next.js layout.tsx, an ArticleLayout with named slots).

Pages

Templates with real, representative content plugged in — including the edge cases that break naive designs: the 40-character name, the empty list, the 3,000-comment thread, the right-to-left locale. Pages are where you validate the system against reality. If a page looks wrong, you fix the template or the organisms, not the page. Pages are instances, not new components.

The chemistry analogy — and its limits

The atoms/molecules/organisms metaphor is a teaching device, not a law. Its value: it conveys hierarchy and composition at a glance and gives non-overloaded names (unlike "component," "module," "widget," which mean ten things). Its limits, which you must hold honestly:

• The boundaries are fuzzy. Is a labeled input an atom or a molecule? Reasonable teams disagree. Don't litigate it — pick a convention and document it.
• It implies strict containment that real UIs violate. Organisms contain organisms; molecules sometimes wrap a single atom. Chemistry doesn't, UIs do. That's fine.
• It says nothing about behavior, state, or data — only structure. A design system also needs token architecture, state conventions, and accessibility rules the metaphor doesn't address.