A systematic way to think about interfaces as compositions of reusable parts — not individual screens.
Atomic Design is a methodology for building design systems by breaking interfaces into five hierarchical levels — atoms, molecules, organisms, templates, and pages.
Where it came from
Atomic Design was introduced by Brad Frost in a 2013 blog post and later expanded into a full book. The central idea: interfaces aren't individual pages — they're systems of reusable components. Frost borrowed the metaphor from chemistry, where atoms combine into molecules, molecules into organisms, and so on.
The framework arrived at a moment when UI component libraries were becoming standard practice but nobody had a shared vocabulary for thinking about them systematically. It gave that vocabulary a name.
The five levels
- Atoms: The smallest UI elements — buttons, inputs, labels, icons. They can't be broken down further without losing their function.
- Molecules: Simple combinations of atoms that form a functional unit. A search bar (input + button + label) is the classic example.
- Organisms: More complex components assembled from molecules — a navigation header, a product card grid, a comment thread.
- Templates: Page-level arrangements of organisms. No real content yet — just structure and layout.
- Pages: Templates with real content populated. This is what users actually see and what gets tested against reality.
Why it matters for teams building design systems
The vocabulary gives teams a shared language for discussing component scope and responsibility. Asking "is this a molecule or an organism?" forces a useful conversation about whether a component is doing too much.
Teams building a Design System find that Atomic Design helps prevent two failure modes: components too granular to be useful on their own, and components so monolithic they can't be reused in different contexts. Both problems are expensive to fix after a library grows large.
Atomic Design vs. a component library
A component library is a collection of built UI components. Atomic Design is a methodology for thinking about how those components relate to each other. You can have a component library without applying Atomic Design — most teams do — but without a structural model, libraries tend to sprawl: similar components get built independently, naming conventions drift, and nobody is sure which component to use where.
Atomic Design doesn't prevent that drift. It gives teams a framework to push back against it.
Where it falls short
The chemistry metaphor is intuitive at the start but gets strained in practice. Organisms are particularly hard to classify consistently — teams regularly argue about whether a given component is a molecule or an organism, with no clear rule to resolve it.
Atomic Design also says nothing about behavior, states, or interactions — only visual composition. For teams working with heavily interactive products, the structural model needs supplementing with documentation on how components behave, not just how they look. Pairing it with thorough Design Tokens governance gets you most of the way there.