Atomic Design

Origin & evolution

Brad Frost introduced Atomic Design in a blog post on bradfrost.com in 2013, at a moment when the industry was grappling with the complexity of building responsive interfaces across a proliferating range of screen sizes. The page-centric mental model that had dominated web design, where designers handed off full-page mock-ups and developers rebuilt each page from scratch, was producing inconsistent UIs that were expensive to maintain. Pattern libraries existed but lacked a coherent way to talk about the relationship between pieces.

Frost's insight🔦InsightUser ResearchA synthesised finding from researchView reference → was to name the levels explicitly and tie them to a delivery artefact: the pattern library. If your team agreed that a Button was an Atom, a Search Field was a Molecule, and a Navigation Bar was an Organism, you had a shared vocabulary that cut across design and engineering. The methodology gained significant momentum through the early 2010s, popularised by the Pattern Lab tool Frost co-created, which generated a living pattern library from templates. Frost published the full Atomic Design book in 2016 through his own imprint at atomicdesign.bradfrost.com, making the text freely available online. The book has become a foundational reference for design systems practice and is read widely alongside Brad Frost's ongoing writing and workshops.

How it works in practice

The five levels describe both granularity and purpose.

Atoms are the smallest functional UI units: an HTML tag rendered with its styles, a colour swatch, a typographic scale entry, an icon. They are not useful in isolation to a user, but they are the non-divisible building blocks. A text input, a primary button, a form label.

Molecules are combinations of Atoms that function as a unit. A search form that joins a text input, a submit button, and a label is a Molecule. The rule of thumb is that a Molecule does one thing. A user can interact with it and understand its purpose without surrounding context.

Organisms are complex components assembled from Molecules (and sometimes Atoms) that form a distinct section of an interface. A site header containing a logo, a navigation bar, and a search form is an Organism. Organisms represent a meaningful chunk of a screen and can contain business logic.

Templates are page-level layouts with no real content. A Template shows the structural arrangement of Organisms and sets the proportions of a design: a two-column article layout, a checkout flow with a sidebar. Templates are the point where design and content requirements meet; they show how Organisms behave together.

Pages are specific instances of Templates with real content filled in. The homepage of a live product is a Page. Pages let teams test whether the underlying system holds up when confronted with real text lengths, real images, and real edge cases.

A worked example. A fintech onboarding flow might define a Button Atom and a Text Input Atom, combine them into a Password Field Molecule, assemble a Login Form Organism, place it in a Single-Column Auth Template, and then render both the Login Page and the Reset Password Page as two different instances of the same Template. When the design system evolves the Button Atom, every Molecule, Organism, and Page that uses it updates consistently.

The methodology is most effective when it governs both design files and code. Teams that maintain a Figma component library organised by Atomic level alongside a component library in code (React, Vue, Svelte) find the mapping natural and the communication cost between design and engineering reduced.

When to use it (and when not)

Atomic Design is well suited to teams building products that will grow, that serve multiple surfaces (web, mobile, email, marketing site), or that have a dedicated design systems function. It pays back the upfront taxonomy work over the medium term.

It fits especially well when a product is being built from the ground up, or when an existing product is being systematised after a period of organic growth that has produced inconsistent UI. The naming convention gives design and engineering a shared language that reduces review cycles.

It is less valuable for one-off campaigns, short-lived prototypes📱PrototypeExperience DesignAn interactive mockup for testingView reference →, or products with a fixed small scope that will never add surfaces. The overhead of maintaining five levels of hierarchy is real, and a team of two building a single-page tool may find it constraining.

The common failure modes: conflating Atoms and Molecules because the line feels arbitrary (agree once, commit, move on), treating the levels as rigid boxes when some components genuinely sit between levels (use your judgement and document it), and building a thorough component library in Figma without an equivalent in code (the pattern library only helps both sides if both sides use it). A second frequent trap is conflating Atomic Design with design tokens🪙Design TokenDesign SystemA design token (colour, spacing, typography)View reference →. Tokens are a related but distinct concept; they define the raw values (colours, spacing, radii) that Atoms consume.

In the Unified Product Graph

Atomic Design is a tree framework in the design category. Its five levels map onto entity types that represent progressively more composed interface artefacts:

• Atoms and Molecules both map to design_component🧱Design ComponentDesign SystemA reusable UI componentView reference → entities. The Unified Product Graph models both at the same entity type, distinguishing their level of composition through properties and parent-child relationships. A Button and a Search Form are both design_component🧱Design ComponentDesign SystemA reusable UI componentView reference → nodes; the Search Form's parent is the Button.
• Organisms map to design_pattern🧩Design PatternDesign SystemA documented design patternView reference → entities, the named, reusable interface patterns that encapsulate a section of a product's UI and carry their own interaction behaviour.
• Templates map to wireframe▭WireframeExperience DesignA low-fidelity structural layoutView reference → entities, the structural layout artefacts that define page proportion and component placement before real content is introduced.
• Pages map to screen🖥️ScreenExperience DesignA distinct screen or view in the productView reference → entities, the specific, content-filled instances of a product interface that a user actually encounters.

Modelling the Atomic hierarchy this way means a change to a design_component🧱Design ComponentDesign SystemA reusable UI componentView reference → at the Atom level can be traced forward through the design_pattern🧩Design PatternDesign SystemA documented design patternView reference → and screen🖥️ScreenExperience DesignA distinct screen or view in the productView reference → entities that depend on it, giving teams an impact surface before a change ships.