What are the five levels of atomic design?

Atoms are the smallest useful elements: a label, an input, a button. Molecules combine a few atoms into something with a job, such as a labelled field with its error text. Organisms are self-contained sections like a table toolbar or a navigation bar. Templates are page-level layouts without real content. Pages are templates filled with real data. Brad Frost published the model as a blog post in 2013 and expanded it into a book, and it has been the default mental model for component structure ever since.

Is atomic design still worth using?

As a way of thinking about composition, yes. As a literal folder structure, most teams abandon it, because the arguments about whether something is a molecule or an organism consume more time than the categories save. Keep the principle that components compose from smaller components, and be pragmatic about the labels.

What is the difference between atomic design and a design system?

Atomic design is a methodology for organising components. A design system is the actual thing you build: components, tokens, guidance and governance. You can build a design system without atomic design, and plenty of good ones use a flatter structure.

Where do design tokens fit in atomic design?

Underneath the atoms, sometimes called subatomic. A token is a named value rather than a component: a color, a spacing step, a type size. Atoms consume tokens, which is what lets a whole system be rethemed without any component being edited.

What is the hardest part of applying atomic design?

Deciding where the boundaries are, and knowing when to stop. Teams commonly build atoms nothing uses, and argue about classification for components that only ever appear in one place. The pragmatic rule is that something earns promotion to a shared level when it has appeared a third time.

Atomic Design

A methodology that organises an interface into five levels — atoms, molecules, organisms, templates and pages — so components compose predictably.

UI Components

Atomic design is a methodology for organising an interface into five levels, borrowed from chemistry: atoms, molecules, organisms, templates and pages. Brad Frost published it as a blog post in 2013 and later expanded it into a book, and it has been the default mental model for component structure ever since.

Its real contribution is not the vocabulary. It is the idea that an interface is built by composition rather than by drawing screens, and that the same small parts should assemble into everything.

The five levels

Level	What it is	Examples	Owns
Atoms	The smallest useful elements	Label, input, button, icon, badge	Its own states and nothing else
Molecules	A few atoms doing one job together	A labelled field with help and error text, a search box with its button	The relationship between its atoms
Organisms	Self-contained sections	Table toolbar, navigation bar, a filter panel	Layout and behaviour of a whole region
Templates	Page structure with no real content	A settings layout, a list-detail layout	Where regions sit and how they respond
Pages	Templates filled with real data	The billing settings page	Nothing structural; it is the proof

Design tokens sit underneath the atoms. They are values rather than components, and the fact that atoms consume tokens is what allows an entire system to be rethemed without editing a single component.

Where the model earns its keep, and where it does not

It earns its keep as a shared way of asking whether something should be built once or many times. A team that habitually asks "is this an atom or is it this screen's problem" builds fewer duplicates.

It stops earning its keep at the classification argument. Is a table an organism or a molecule? Is a card with a button inside it a molecule? These questions have no answer that changes anything, and teams have lost weeks to them.

The pragmatic version most mature teams end up with: keep the composition principle, keep a shared layer and a local layer, and stop insisting on five names. What matters is whether a component is shared, not which Greek-derived tier it occupies.

Applying it without building things nothing uses

The failure mode is bottom-up completeness: build every atom first, then every molecule, and discover that half of them have no consumer.

The order that works is the reverse. Take two or three real screens the product needs. Build them. Notice what repeats. Promote the repeats. A component earns a place in the shared layer when it has appeared a third time, which is the same bar recorded under component library and for the same reason: two occurrences is a coincidence.

This also settles the classification argument by making it unnecessary. Something that has appeared three times is shared, and what it is called matters far less than that it exists once.

Atomic design in dense B2B products

The model was described with marketing sites and consumer products in mind, and B2B strains it in two places.

Organisms carry most of the complexity. A B2B product is largely tables, toolbars, filter panels and detail views. These are big, stateful and full of permission variants, and the interesting design work lives at this level rather than at the atoms. A team over-invested in perfect atoms and under-invested in organisms has optimised the easy half.

Permission variants cut across every level. The same organism renders differently for an admin, a member and a viewer. Atomic design has nothing to say about this, and it is one of the most consequential structural decisions in an enterprise interface. Decide where the variant lives — inside the component, or in what the page passes it — before the third team invents its own answer.

Naming and the boundary problem

Two practical decisions cause more trouble than the five levels themselves.

What a component is called. Names get chosen from what the component looked like when it was first built, and the appearance changes. A BlueBanner outlives the decision to make it grey; a Notice does not. Name for the job, the same rule that applies to design tokens.

Where the boundary sits. A labelled input with help text and an error message can be one component or four assembled at the call site. One component is easier to use and harder to bend; four are flexible and get assembled inconsistently. The usable default is to bundle what is always used together and leave the rest composable, then revisit when somebody needs a variant that does not fit.

The related trap is prop sprawl. When a component accumulates eleven boolean flags, it has become several components merged for tidiness, and nobody outside the team that wrote it can tell which combinations are supported.

In practice

A team adopts atomic design and spends a quarter building a complete atom and molecule layer before any product screen uses it.

When the screens arrive, roughly half the library goes unused, and several of the components that are needed do not exist, because nobody had built the screens that would have revealed them. Meanwhile the components that do get used need variants the original design did not anticipate, so they are extended in ways that make the tidy taxonomy misleading.

The same quarter spent building three real screens and extracting what repeated would have produced a smaller library with no unused parts and no missing ones. The methodology was not the problem; the direction was.

Where teams get it wrong

Building bottom-up. A complete atom layer nothing consumes.
Arguing about tiers. Whether something is a molecule or an organism changes nothing anybody can act on.
Treating it as a folder structure. The value is in composition, not in directory names.
Ignoring organisms. In B2B they hold most of the complexity and most of the reusable value.
No answer for permissions. The variant that cuts across every level, and the one the model does not cover.

Learn more

Design System service →