Atomic Design

What is Atomic Design?

The main idea behind Atomic Design is to think about components in their smallest, simplest elements (such as a menu item or a search button) first and building up from there. In other words, it's a pattern language concerned with building a design from element upwards rather than starting with page level wireframes.

These elements are categorised into these levels:

We start off on quite abstract levels:

  • Atoms - an element that can't be broken down any further, e.g. a menu item
  • Molecules - a group of atoms, e.g. a menu (made up of menu item atoms)
  • Organisms - made up of various molecules, e.g. a page header (made up of a menu molecule and a site search molecule)

Then we move onto more concrete levels:

  • Templates - molecules are grouped together, along with wireframe elements, these will be types of pages, e.g. an article or blog listing
  • Pages - these are templates that are filled with actual instances of the content, e.g. the actual images and copy to be used

Why would we use Atomic Design?


Atomic Design gives us a library of reusable components, meaning that once we have made this library the process of creating new sections of a site will be straightforward. Rather than having to make new designs, we just reassemble the components from our library in different ways. In the backend of this we will have a library of reusable code.


We can be confident that our designs which use the same library will be consistent since each instance of a particular component will be using the same code. No longer will there be multiple buttons that are meant to be identical but use slightly different amounts of padding or a slightly different background colour.

How can we implement Atomic Design into our work?

Changes to our workflow and design processes

Using Atomic Design can mean components being designed in HTML using a programme such as Pattern Lab rather than a drawing programme such as Photoshop. Designing like this will mean a closer working relationship and even a crossover of roles between front-end developers and designers.

One of the biggest challenges is getting the client onboard and guiding them how to think in an atomic way. The process is very different to what they are used to, and to be fair it's different to what most designers are used to!

How do we go about evolving our designs?

It's almost certain that somewhere down the line the client will request to have a new type of page or component. How do we go about accommodating or pushing back against these requests? How do we know which of these is the correct response for the design?

When we initially design our components we have to make sure that they have meaning, that we're building a design language, that there's a rationale running through the decisions we make rather than just an eclectic mixture of components.

When we evolve our patterns we always ask ourselves - does this add in a new pattern or change an existing one? We also check how this will affect our other design patterns. For example, if we add in extra padding around an element will this change how we deal with spacing around other elements?

We are building design ecosystems, changes to one part will affect other parts and everything needs to work in harmony for the design to be effective.

Putting our designs to the test

We do this through metrics, making sure that our decisions are tested (such as through A/B testing). This makes our design language robust, and since it is proven to work it makes it easier to persuade stakeholders to stick with the process.

Next steps

Style Guide

Atomic design works really well as a basis for building a style guide. One of the tools worth looking into for this is Pattern Lab. The PHP instance of Pattern Lab can now use Twig.

Style Inventory

If your website is already built, a quick exercise to see how consistent you've been with your page elements is to create a style inventory.

Take screenshots of your elements, starting with atomic level ones such as buttons and headings. Group these together by type and see if you have lots of different styles.

Do the separate styles have meaning, was there a design decision behind making them different? If not, can you reduce the number of different styles you are using?

The Results

We end up with a platform and a shared design language made from a reusable library of components that have been proven to work. When adding extra sections to a site we just use our library like a set of building blocks, without having to come up with new unproven designs that may not offer consistency with existing pages.

To learn more about how Atomic Design can be applied to your next web design project get in touch!