← Go Back

Atomic Design

What is atomic design?

Atomic design is a methodology (Brad Frost) for creating design systems by breaking the interface into five levels: atoms (smallest elements), molecules (small groups), organisms (sections), templates (page structure), and pages (concrete instances). You build from the smallest parts up so the system is consistent and reusable.

Use it when: you’re defining or documenting a design system and want a clear hierarchy and shared language for designers and developers. It’s a way to think about structure, not a requirement to use the exact names.

Copy/paste template (five levels)

  • Atoms – Buttons, inputs, labels, icons. Can’t be broken down without losing meaning.
  • Molecules – Search field (input + button), form row (label + input). Small, reusable groups.
  • Organisms – Header, card, nav bar. Distinct sections made of molecules and atoms.
  • Templates – Page layout (slots for header, main, sidebar, footer). Structure, minimal content.
  • Pages – Filled templates with real content. What users see.

Build and document from atoms up; design pages and slice down to see which organisms, molecules, and atoms you need.

Why atomic design matters

  • Gives teams a shared vocabulary (atoms, molecules, organisms) so everyone means the same thing.
  • Encourages reuse: fix or improve an atom and it updates everywhere.
  • Makes design systems easier to reason about and maintain.
  • Supports consistency and scalability by building from a finite set of parts.

What good atomic design includes

Checklist

  • [ ] Atoms defined – Smallest UI elements (buttons, inputs, labels, icons) with variants and states.
  • [ ] Molecules that combine atoms – No new primitives; reuse atoms only.
  • [ ] Organisms that form sections – Header, cards, forms, etc. that can be placed in templates.
  • [ ] Templates – Layout and placement; placeholder or example content.
  • [ ] Documentation – What each level contains; when to use which component. See design systems.
  • [ ] Code and design in sync – Components exist in design system and in code (e.g. component library).

Common formats

  • Strict atomic: Everything classified as atom, molecule, organism, template, or page. Good for large, formal systems.
  • Inspired: You use the idea (small → large, reuse) but don’t insist on the five names. Good when “molecule” vs “organism” is fuzzy and the team prefers different labels.

Examples

Example (the realistic one)

Atoms: Primary button, text input, label, icon. Molecules: Search (input + icon button); form field (label + input + error message). Organisms: App header (logo + nav + user menu); product card (image + title + price + button). Template: Dashboard layout (header, sidebar, main area with card grid). Page: Dashboard with real products. You document each level in your design system; devs implement atoms and molecules first, then organisms and templates.

Common pitfalls

  • Endless debate on “is it a molecule or organism?” → Do this instead: Use the hierarchy that helps your team; rename levels if it helps (e.g. “components” and “patterns”).
  • Atoms too big: “Form” as an atom. → Do this instead: Atoms are the smallest meaningful elements (button, input, label); forms are molecules or organisms.
  • No documentation: Levels exist in Figma or code but nobody knows when to use what. → Do this instead: Document each level and component with purpose, usage, and accessibility notes.
  • Design and code out of sync: Design has atoms; code has different components. → Do this instead: Align naming and structure between design system and component library.
  • Atomic design vs design system: Design system is the full set of tokens, components, and guidelines; atomic design is one way to structure the components (atoms → pages).
  • Atomic design vs component library: A component library is the code implementation; atomic design is the conceptual hierarchy. The library can follow atomic levels.
  • Atomic design vs design standards: Design standards are the rules; atomic design is the structure of the building blocks that follow those rules.
  • Design systems – atomic design structures the component layer.
  • Component libraries – the code side of atoms, molecules, organisms.
  • Design standards – standards apply to each level.
  • Hierarchy – visual hierarchy on the page; atomic structure is component hierarchy.
  • UI design – atomic components are the units of UI design.
  • Scalability – atomic design helps UIs scale consistently.

Next step

List your current UI building blocks and group them into atoms (single elements), molecules (small groups), and organisms (sections). Document one level (e.g. atoms) in your design system with usage and accessibility notes. Read Design systems to place atomic design in the full system.

Related Terms