In short
Atomic design is a methodology, introduced by Brad Frost in 2013, for building interfaces from a hierarchy of components: atoms (buttons, inputs, labels), molecules (a search field made of an input and a button), organisms (a header made of a logo, navigation and search), templates (page layouts with placeholder content) and pages (templates with real content). Its value is in making teams design and build reusable parts rather than one-off pages, which is the foundation of a design system. Most teams keep the mindset and simplify the naming.
The five levels
Atoms are the smallest usable elements: a button, a text input, a label, a heading, an icon, a colour, a typographic style. On their own they do little.
Molecules are small groups of atoms that do one thing together: a label, an input and a button make a search form; an avatar and a name make a user chip.
Organisms are larger sections assembled from molecules and atoms: a site header with logo, navigation and search; a product card grid; a comment thread. They are recognisable parts of an interface with their own behaviour.
Templates are page-level layouts that arrange organisms with placeholder content, showing structure without specifics: an article template, a product page template.
Pages are templates filled with real content: this article, this product. They are where the design is tested against reality, since real headlines are longer than placeholders and real lists are sometimes empty.
The chemistry metaphor is Frost's, and its purpose is to make the hierarchy memorable. It is not meant to be taken literally, and nobody has ever needed to decide whether a dropdown is an atom or a molecule for the product to ship.
Why it helps
Reuse. A button designed once and used everywhere is consistent everywhere and changes everywhere when it needs to. This is the whole case for a design system, and atomic design is one of the clearest ways of explaining it to people who have not built one.
A shared vocabulary. Designers and developers who both think in components can talk about the same things. The header organism in Figma and the header component in code are the same object, and the handoff becomes a matter of matching names rather than interpreting pictures.
Bottom-up and top-down at once. Atoms and molecules are designed for consistency; pages are designed for the actual content. Working at both ends catches the failures of each: a component that looks fine in isolation and breaks with real text, or a page that looks fine once and cannot be built from reusable parts.
Testing at the right level. Atoms can be tested for accessibility and states once. Pages can be tested with real content. Neither has to do the other's job.
Where it gets in the way
Taxonomy arguments. Teams lose afternoons debating whether a card is a molecule or an organism. The answer does not matter; the component's name, behaviour and states do.
Five levels is often too many. Most teams find two or three sufficient: elements, components and layouts, or tokens, components and patterns. The naming is a means; if it does not help, change it.
Over-abstraction. Building every conceivable atom before any page exists produces a library of parts nobody needs and delays the product. Components should be extracted from real pages as patterns repeat, not invented in advance.
The metaphor implies stability that interfaces lack. Atoms in chemistry do not change; a button's design does. Treat the levels as a way of organising work, not as a claim about permanence.
How teams actually use it
The common adaptation in 2026 is to keep the idea and flatten the hierarchy: a layer of design tokens (colours, spacing, type, the things that were called atoms before they were things), a layer of components with variants and states (buttons through to headers, without insisting on molecule-versus-organism), and a layer of page templates or patterns. Component libraries in Figma and in code mirror each other at the component layer, and pages are assembled from them.
That structure delivers atomic design's benefits with fewer arguments, and it is what most design systems, whether or not they use the word, converge on.
A worked example
Take a product listing page. The tokens are the brand colours, the spacing scale and the type sizes. The atoms are a price label, a star-rating icon, an image frame and a button. A product card is a molecule: image, title, price, rating and an add-to-basket button arranged in a fixed way. The product grid, with its filter bar and pagination, is an organism. The listing template arranges the header organism, the grid organism and the footer organism with placeholder products. The page is that template showing this season's actual range, where the team discovers that one product name wraps to three lines and the card needs a rule for truncation. Every one of those parts is reused elsewhere, and the truncation rule, once decided, applies wherever the card appears.
Does it fit your project?
A small marketing site with five pages gains little from a formal component hierarchy; consistency can be kept by one careful designer. A product with dozens of screens, several contributors and a lifespan of years needs component thinking, and atomic design is a good way to introduce it. The signal is repetition: the third time a pattern appears, it should become a component, and the practice of noticing that is the real content of the methodology.
If you are starting a design system and want the structure without the ceremony, book a call; we usually set up three layers and a naming convention in an afternoon.
Common questions
What are the five stages of atomic design?
Atoms, the smallest elements such as buttons, inputs and labels; molecules, small functional groups such as a search form; organisms, larger sections such as a header or a card grid; templates, page layouts with placeholder content; and pages, templates filled with real content. Each level is built from the ones below it.
Is atomic design the same as a design system?
No. Atomic design is a methodology for organising an interface into a component hierarchy; a design system is the actual collection of tokens, components, patterns and documentation a team uses, plus the process around it. Atomic design is one way to structure a design system, and many systems borrow its thinking without its five-level naming.
What is the difference between a molecule and an organism in atomic design?
A molecule is a small group of atoms doing one thing, such as an input and a button forming a search field. An organism is a larger, recognisable section built from molecules and atoms, such as a site header containing a logo, navigation and that search field. The boundary is fuzzy and teams should not spend long on it.
Do developers use atomic design?
The component thinking, yes; the strict taxonomy, less often. Front-end frameworks are built around reusable components, and code libraries typically mirror the design library at the component level. Most teams organise code as tokens, components and layouts rather than five chemical levels, while keeping the principle of building pages from reusable parts.
Is atomic design still relevant?
The principle is more relevant than ever, since design systems and component-based frameworks are standard. The five-level vocabulary is used less, with most teams flattening it to tokens, components and patterns. Its lasting contribution is the habit of extracting reusable components from repeated patterns rather than designing pages one at a time.
