Atomic design
Brad Frost's atomic design names five levels — atoms, molecules, organisms, templates, pages — so a UI composes from primitives instead of one-off screens.
In one line: atomic design gives you a five-rung vocabulary — atoms, molecules, organisms, templates, pages — so every screen is composed from a handful of primitives rather than drawn from scratch.
What it is
Atomic design is a mental model Brad Frost borrowed from chemistry to describe how interfaces are built. It names five levels, each made of the one below it:
- Atoms — the irreducible primitives: a button, a label, an input, an icon, a badge. On their own they do little, but nothing smaller is useful.
- Molecules — a few atoms bonded into a small, reusable unit with a single job: a search field is a label + input + button.
- Organisms — relatively complex sections built from molecules and atoms: a header, a search panel, a product card.
- Templates — page-level layouts that arrange organisms into a structure, with content left as placeholders. They show the skeleton, not the final copy.
- Pages — specific instances of a template with real content poured in, where you finally test whether the system holds up.
The live demo below walks the first four rungs — atoms through templates — because those are where the composition idea is clearest. Pages are simply a template filled with real data.
Why it matters
Without a shared vocabulary, teams describe UI in screen-sized chunks ("the checkout page," "the settings screen"), and every new screen gets redrawn from zero. That is how you end up with nine subtly different buttons and three flavors of search box.
Atomic design forces the opposite habit: you build (and name, and test) the small parts once, then assemble bigger things from them. A bug fixed in the Button atom is fixed everywhere it appears. A new screen is mostly arrangement of things that already exist. The vocabulary also gives designers and engineers the same words, so "make this a molecule" means the same thing on both sides of the handoff.
See it
Tweak it3
Step through the levels with the controls. Watch the same primitives compose upward: the Button and Input atoms you meet first reappear inside the search molecule, the molecule reappears inside the organism, and the organism slots into the template. Nothing new is invented as you climb — the parts just combine.
How it works
Each level is defined entirely by what it is made of.
- Atoms are concrete elements with no further breakdown — a
<button>, a<label htmlFor>paired with its<input>, a small status<span>badge. - Molecules group a handful of atoms toward one purpose. A search field molecule pairs a label, a text input, and a submit button so the three always travel together and stay accessible as a unit.
- Organisms stitch molecules and atoms into a self-contained region. A search panel organism wraps the search molecule with a heading atom and a list of result rows — something you could lift onto many pages.
- Templates drop organisms into a page-level grid (header, sidebar, main) and leave the unfilled regions as muted placeholders, proving the layout works before any real content exists.
Build it
The smallest honest example: two atoms composed into a molecule. The Input and Button atoms know nothing about search — the SearchField molecule is what gives them a shared job and keeps the label wired to the input.
// Atom: a labelled text input
function Input({ id, label, ...rest }: { id: string; label: string } & React.InputHTMLAttributes<HTMLInputElement>) {
return (
<div className="field">
<label htmlFor={id}>{label}</label>
<input id={id} type="text" {...rest} />
</div>
);
}
// Atom: a button
function Button({ children, ...rest }: React.ButtonHTMLAttributes<HTMLButtonElement>) {
return (
<button type="button" {...rest}>
{children}
</button>
);
}
// Molecule: the two atoms bonded into one reusable unit
function SearchField({ onSearch }: { onSearch: (q: string) => void }) {
return (
<form
role="search"
onSubmit={(e) => {
e.preventDefault();
const data = new FormData(e.currentTarget);
onSearch(String(data.get("q") ?? ""));
}}
>
<Input id="q" name="q" label="Search the library" placeholder="Type a term…" />
<Button type="submit">Search</Button>
</form>
);
}Make it yours
Use the controls beside the demo above to change level, annotate the parts, and button atom style — each change updates the example live.
Experiment in the playground- Trace one atom up the ladder. Notice the Button you see at the atoms level is the same component inside the molecule, organism, and template — that reuse is the whole point.
- Name your parts as you build them. Calling something "a molecule" out loud is what stops it from being re-invented on the next screen.
- Stop the model where it stops being useful. Most teams never formalize "templates" and "pages" — atoms, molecules, and organisms carry the vocabulary; the top two rungs are optional.
Reproduce it with an LLM
Reproduce it with an LLM
You are a front-end architect. Take a screen — 'a product search results page for a fictional store called Lumen' — and decompose it with atomic design. List the atoms (the smallest primitives: button, input, label, badge, icon), the molecules (small groups, e.g. a search field = label + input + button), the organisms (sections composed from molecules, e.g. a results toolbar, a product card), the templates (the page-level layout with content regions as placeholders), and finally the page (the template filled with real content). For each level, name what composes it from the level below. Then propose a component folder structure that mirrors these levels. Return labelled sections plus the file tree.
Pitfalls & accessibility
- Don't let the diagram become the deliverable. Atomic design is a way to think about reuse, not a folder structure to enforce — arguing whether something is a molecule or an organism wastes time the composition itself was meant to save.