Atomic Design

011 min

The problem atomic design solves

Picture a subscription app with a search box on three screens: the help page, the account page and the checkout page. Each search box was designed and built as part of its own page. One has a grey button. One has a blue button. One has no label at all. When the brand colour changes, a developer edits three files and still misses a fourth copy in an old settings screen.

This case is illustrative, but the cause behind it is common. Teams plan, design and approve websites one page at a time. The page is the unit the work is scoped in, so each page gets its own copy of the shared parts. Over months, the copies become more and more different. Designers and developers also end up with different names for the same thing, so a request about "the search bar" can mean three different pieces of code.

Brad Frost argued that the page is the wrong unit of work. An interface now has to run on phones, tablets, laptops and large screens, often across several products. What stays the same across all of them is not the page. It is the set of parts the pages are made from. Atomic design gives a team a way to name those parts by size, build each one once, and share one vocabulary between design and code.

022 min

Where atomic design comes from

Brad Frost, a web designer, published atomic design as a blog post on 10 June 2013. While looking for a model for interface parts, Frost kept going back to chemistry. In chemistry, atoms join to form molecules, and molecules join to form larger organisms. Frost took those three names and added two of his own, templates and pages, for the levels where the chemistry comparison stops helping. He also pointed readers to Josh Duck's HTML Periodic Table, which arranges HTML elements the way the periodic table arranges chemical elements.

To use the method in client work, Frost and developer Dave Olsen built Pattern Lab, an open-source tool that assembles small parts into complete pages. Frost later expanded the post into a book, Atomic Design, which can be read in full on its own website.

What atomic design took from Object Oriented CSS

The idea of reusable interface parts did not start with Frost. Nicole Sullivan had presented Object Oriented CSS at the Web Directions North conference in Denver. Her method treated a repeated visual pattern as an object: a self-contained piece of HTML and CSS. Its central rule was that an object should look the same wherever it is placed.

Atomic design depends on that rule. The search form from the subscription app can move from the help page into the site header only if nothing about its look depends on the page around it. When a part's style is written for one location, such as "buttons inside the sidebar", the part cannot be reused. Anything built from it then has to be built again for each new place.

032 min

The five levels of atomic design

Atomic design sorts every part of an interface by its size and by what it contains. Each level is made from parts of the levels below it.

Content designers apply the same levels to words. A button label or an error message is written once, as part of its atom or molecule, so the wording matches on every screen that uses it.

041 min

Why atomic design is not a step-by-step process

The five levels read like a sequence, but Frost says they are not one. Frost wrote that atomic design is not a linear process. It is a way of looking at an interface as one whole and as a collection of parts at once. A designer does not finish every atom before starting the first molecule. They move up and down between the levels as they learn what the product needs.

Back in the subscription app, the team builds the search form molecule and places it in the header organism. Then a real page shows a problem. On a small phone screen, the header has no room for a full-width search form. The fix does not belong on the page. The team goes back to the molecule and adds a compact version that shows only a search icon button. Every page that uses the header gets the fix at the same time.

This movement is the main practical value of the five names. A problem seen on a page is traced down to the smallest part that causes it. The change to that part is then checked again at page level, with real content.

052 min

Atomic design vs. nearby concepts

Because atomic design names parts, people often mix it up with the place those parts are kept, and with an older coding idea that shares its name.

A design system is what a team ends up with: the shared parts, the rules for using them, and the documentation. Atomic design is one method for building and sorting that system. A team can have a design system without ever using the words atom or molecule. A pattern library is narrower again: it is the catalogue where the parts are shown and described. Atomic design is also a specific case of modularity, the general idea of building a system from separate parts that can be swapped. What atomic design adds is a set of levels, so a team can say how big a part is and what it may contain.

Atomic design is not atomic CSS

The similar names cause a real mix-up. In October 2013, four months after Frost's post, Thierry Koblentz published an article in Smashing Magazine called "Challenging CSS Best Practices". He argued that each CSS class should apply one style, not several. That approach became known as atomic CSS.

Atomic CSS is a rule for writing style code. Atomic design is a way to organise visible interface parts. An atom in atomic CSS is one style rule, such as a margin. An atom in atomic design is a part a user sees, such as a button. A team can use either one without the other.

062 min

Where atomic design breaks down

Once a team starts sorting parts into levels, the borders between levels become the first argument.

The GOV.UK Design System, used across UK government services, shows another way to sort the same parts. It uses three groups: styles, components and patterns. Styles cover layout, type, colour and images. Components are reusable parts such as text inputs and tables. A pattern solves one task a user is trying to complete, and it usually uses one or more components. Asking a user for an address is one of its patterns. The parts are the same kind of parts. Only the names and the number of levels differ.

When one atom change reaches every page

The main benefit of atomic design is that a change to one part appears everywhere. That is also its main risk. If the subscription app's team changes the button atom, the checkout page changes on the same day, even if nobody has tested checkout with the new button.

A passage in Frost's book describes the usual answer: give each release of the shared parts a version number. Product teams then move to a new version when they are ready, by changing the version number they load. In the subscription app, the checkout team moves to version 1.3.5 right away, and the help team stays on 1.3.4 until it has tested the new button. The cost is that two versions of the button are live for a while, which is the kind of difference the method set out to remove. Teams accept it for a short, planned period.

071 min

Atomic design and accessibility

Shared parts also change how accessibility work spreads through a product. In the subscription app, the third search box had no label, so screen-reader users heard no name for the field. Building the search form as one molecule with a proper label fixes it on all three screens at once. This is the strongest accessibility argument for atomic design: a fix at the smallest level reaches every page that uses the part.

Why accessible parts can still make an inaccessible page

Some accessibility rules apply to the whole page, not to any one part. WCAG 2.2 Success Criterion 2.4.3, Focus Order, requires that a keyboard user moves through the page in an order that keeps its meaning and its controls usable. Each organism can pass on its own and the page can still fail.

Suppose the subscription app's checkout template puts the order summary before the payment form in the code, but shows it to the right of the form on screen. A keyboard user tabs into the summary, then back to the form, then across again. No atom is at fault. The order is set by the template. So focus order has to be tested at the template and page levels, with a keyboard, every time organisms are rearranged.

081 min

How atomic design changed since 2013

Frost has kept revising the method, and each change has widened its scope. In 2013 atomic design described how one team could organise one product's interface. By 2019 Frost was telling teams to rename and extend the levels to fit their own organisations.

In January 2024 Frost proposed a Global Design System: a shared library of common UI components that would work with any web technology. His argument was that thousands of organisations build the same basic parts again and again, such as buttons, form fields and dialogs. If such a library existed, a product's atoms and many of its molecules would come from outside the company. A team's own work would start at the organism level, where its product is actually different from others. The proposal is still a proposal. No shared library of that kind has replaced company design systems so far.

092 min

How to apply atomic design to a product

For a team starting today, the method begins with what already exists, not with a blank list of atoms.

1. 1

   Collect every version of each part.

   The team takes a screenshot of every screen and groups the parts that do the same job. The team puts the three search boxes side by side: one from the help page, one from the account page and one from the checkout page. Seeing them together shows how different the copies have become. Frost's book calls this collection an interface inventory.

2. 2

   Name the atoms first.

   Agree on the colours, type sizes, spacing values and basic controls. Many teams store the first three as design tokens: named values that design files and code both read.

3. 3

   Rebuild each molecule for one job.

   Replace the three search boxes with one search form molecule, and list its states: empty, filled, no results and error.

4. 4

   Test on pages with real content.

   Use the longest real product name, an empty result and a translated label. Fix problems in the smallest part that causes them.

5. 5

   Write down what each part is for

   , and when not to use it, in the pattern library.

?4 questions

Questions people ask

§11 sources

Sources