Atomic Design
Atomic design is a methodology created by Brad Frost for building UI component systems by decomposing interfaces into five hierarchical levels – atoms, molecules, organisms, templates, and pages – enabling consistent, maintainable design that can be assembled systematically rather than rebuilt from scratch for every new screen.
Why It Matters
Before component-based thinking, designing a new page often meant redesigning from first principles: what should a button look like? How should this form behave? What spacing does this section use? Each new screen was a series of micro-decisions that slowly accumulated into inconsistency across a product.
The atomic design methodology gives those decisions a home. A button isn’t designed fresh each time – it’s an established atom with defined states. A search bar isn’t rebuilt – it’s a molecule assembled from known components. By the time you’re designing a new page, most of the decisions have already been made. You’re assembling, not inventing.
The methodology also creates a shared vocabulary between designers and developers. “Let’s use the Card organism with the compact variant” is a more precise conversation than “make it look like the thing on the products page.” This vocabulary becomes the foundation of a design system, and it directly reduces the friction that causes design drift over time.
How It Works / The Five Levels
Atoms are the smallest functional UI units – they can’t be broken down further without losing their meaning. HTML elements are the clearest atoms: a button, an input field, a label, an icon, a color token, a typographic style. In design tools, atoms become base components and shared styles.
UI examples: A primary button, an avatar image, a text input, a chevron icon, a heading style, a status badge.
Molecules are simple combinations of atoms that function together as a unit. A search bar (input atom + button atom + search icon atom) is a molecule – the atoms don’t make complete sense in isolation in this context, but together they form a recognizable, reusable UI element.
UI examples: A search field, a form row (label + input + error message), a price display (amount + currency indicator + strikethrough original price).
Organisms are complex UI sections composed of molecules and atoms working together. They’re large enough to represent a meaningful section of a page but abstract enough to appear across multiple page types.
UI examples: A site header (logo + navigation molecule + search molecule + user avatar), a product card (image + title + price molecule + CTA button), a data table with sorting controls.
Templates are page-level wireframe structures that place organisms in a layout without real content. Templates define the page architecture – the grid, the proportions, the hierarchy of sections – but don’t yet contain final copy, images, or data. This level overlaps closely with the wireframe practice: templates are essentially annotated layout wireframes.
UI examples: A product listing page template, a dashboard layout template, an article page template.
Pages are templates filled with real, specific content. This is what users actually see and interact with. Pages also serve as the testing ground for the system – real content reveals whether the template actually works. Does the heading break at this character count? Does the card layout hold when the product name is unusually long?
Real-World Example
Consider an e-commerce product card, built bottom-up through the atomic levels:
Atoms: Product image, product name (H3 style), price text, star icon, “Add to Cart” button label.
Molecules: Price display (current price + original price with strikethrough), star rating (five star icons + review count), CTA button (button atom + label atom).
Organism: Product card – image + product name + price molecule + star rating molecule + CTA button, contained in a card with defined padding, border radius, and shadow.
Template: Product listing grid – three-column organism grid, filter sidebar, pagination controls, and sort dropdown. No real products yet.
Page: The actual Winter Sale listing page with 24 real products, real prices, real images, and a featured item promoted to a wider card at position 1.
The power of this hierarchy becomes clear at maintenance time: changing the button atom’s border radius updates every CTA across every organism that uses it. The change propagates through the system rather than requiring manual updates to every screen – which is what makes design systems actually scalable.
How to Apply
- Audit your existing UI before building atoms. Identify every button, input, and text style currently in use. You’ll likely find six button variants where two would serve the same purpose – reconcile before you codify inconsistency into the system.
- Define atoms in your design tool as shared components and styles. In Figma, atoms become base components. Changes to the atom propagate to all instances, which is the core maintenance benefit of the methodology.
- Name components by function, not appearance.
Card/Productis better thanWhiteBoxWithShadow. Functional names survive visual redesigns; appearance-based names don’t. - Don’t force everything into the hierarchy. One-off page layouts or highly specific elements don’t need to be atomized if they’ll never be reused. Apply the methodology where it pays off: the elements that repeat across many screens.
- Build living documentation alongside the component hierarchy. The atoms and molecules are only as useful as the guidelines that explain when and how to use them. A component library without documentation is a component library nobody trusts.
Common Mistakes
Treating atomic design as a deliverable format. The five levels are a mental model for building components, not a required output format. You don’t need to label every Figma frame “Atoms,” “Molecules,” etc. The taxonomy serves thinking and communication, not documentation compliance.
Over-atomizing one-off elements. Not every UI element needs to become a reusable component. A complex, highly specific header for a one-off campaign landing page doesn’t need atomizing if it will never appear elsewhere. Time spent building it into the system has negative ROI.
Neglecting the template level. Templates are where layout decisions live, and they’re frequently skipped. Without templates, pages get built with correct components but inconsistent spatial structure – the atoms are right, but the compositions are chaotic. Investing in template-level wireframing prevents this.
Related Concepts
- Design System – the broader structure that atomic components, tokens, and guidelines feed into
- Wireframe – the template and page levels of atomic design are closely related to wireframing practice
- Information Architecture – the structural layer that organisms and templates make visually concrete
- Accessibility – best baked in at the atom level, so every component that uses it inherits it automatically