pixely

I'm a big fan of Brad Frost's Atomic design as a powerful tool for shaping a design system and forming a common language when discussing components. However, I find it can also be something that is often misunderstood.

Atomic design is usually mentioned in the same breathe as component driven development and component libraries to the extent where the distinction between them starts to feel very blurred. Component driven development is the practice of building a page out of modular user-interface blocks  – components – that can be easily reused across different pages.  A component library exists to document these components, usually as one part of an overall design system. Atomic design focuses specifically on how we categorise and group these components.

"Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner."

Brad Frost (The atomic design methodology)

Atomic design provides a hierarchical way of describing UI components. The hierarchy is made up of five stages – atoms, molecules, organisms, templates and pages. This hierarchy often feels like it gets overlooked or oversimplifed by teams using atomic design but having different stages each with a distinct purpose whilst being interconnected is crucial to atomic design – without it you've just got components.

Benefits of atomic design

There are three main benefits of using atomic design to organise and name interface components, especially when working on larger projects across multiple people, teams and disciplines.

1. Maintainability
   Having a library of components which are clearly organised with a defined relationship makes it easier to start constucting new pages by composing together pre-existing components, or to make a change across multiple pages by changing lower-level components
2. Consistency
   Reusing the same atoms, molecules and organisms across all templates and pages helps ensure we deliver a coherent and consistent user experience for customers
3. Communication
   By categorising components into a hierarchy it helps set the scene for any conversations – if you start discussing something as being an atom you are also signalling that this component is a smaller, lower-level part of the interface. Bringing a unified language to components is crucial to having a successful component library

Constraint breeds creativity

By focusing on re-use first, you're also introducing a degree of healthy constraint. For each new component that is getting designed or built we should be first be aiming to reuse any other components which fulfil our requirements before we go about introducing anything new.

1. Reuse an existing component
2. Iterate an existing component
3. Introduce a new component

It's an unwritten rule that any writing on component library must reference Lego due to the modular nature shared by both UI components and Lego bricks. I'm not going to be an exception to that rule!

Imagine you're a Lego designer working on a new set. You've got a huge range of existing brick types to choose from which will always be your starting point. If you find yourself in a situation where you can't use an existing brick type your next option would be trying to pick an existing brick but maybe adding a sticker to it or getting it moulded in a different colour. If there still isn't a suitable brick available, you could design a bespoke new brick type for this specific set but this should be an option of last resort.

Each step away from the existing brick types adds complexity, cost and time in designing, producing moulds and manufacturing new parts which, for now, aren't being used anywhere else. This complexity encourages you try and make the most with the pieces you've already got available. It can be surprising how much is possible without having to start creating something entirely new – having an element of constraint breeds more creative solutions.

Why do we need a framework to help us categorise components?

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

Melvin E. Conway (Wikipedia)

Conway's law states that any organisation which designs a system will end up with a structure mimicking their own organisations structure. Sometimes, that might be desirable but I typically find that component libraries, and design systems as a whole, need to push against existing structures to operate across different teams and ways of working. Atomic design can provide that alternative structure.

If there are multiple teams each responsible for a particular vertical slice of a website – for example a product page and a checkout page then it's easy for each team to view any component requirements with a tunnel-vision around their particular feature and lose sight of the potential reuse opportunities across different features. Over-time, you end up with a component library which mirrors your teams with a large library of single-use components that are very tied to particular use-cases and you end up losing all the benefits of maintainability, consistency and communication.

This is especially true when a design system isn't fully embedded into a culture and product teams are insular, focusing on their short-term problems without considering the longer term implications of maintaining the components they are building.

Refining the hierarchy

As atomic design is a hierarchical framework it's key that each stage serves a purpose with a relationship between them. Three of the five standard stages of atomic design – atoms, molecules, organisms take their names from chemistry with a relationship based on combining elements together to form something bigger.

I find this hierarchy encourages a useful mindset where I start to consider how far to break down an interface into a series of atomic components. What we want to ensure is that each component is completely reusable in it's own right. It's entirely possible to take this too far and end up with a huge number of components which become hard to maintain. Our aim should always to turn your design into the smallest genuinely reusable components possible based on known use cases rather than theoretical. Don't forget that a component library is a living and evolving entity – it's perfectly okay if it changes over time as you work out what does and doesn't work for you.

To help with placing things into the atomic stages we can think of it as a pyramid with each side being a scale to guide us.

Simple versus complex

In Brad Frost's Atomic Design he uses the atomic terminolgy to describe this framework which fundamentally involves the smallest, simplist components existing at the lowest stage of "Atoms" which join together to form increasingly large and complex components.

"In the natural world, atomic elements combine together to form molecules. These molecules can combine further to form relatively complex organisms."

Brad Frost (Taking cues from chemistry)

This composition of components out of smaller components is a really powerful technique. Where possible we should favour composition over configuration. If you get new requirements for a component and do this through additional configuration it's very easy for components to suddenly get really complex.

Instead, consider if we can go from this being one complex component with configuration to instead being two components which are composed of the smaller atomic parts to make the same end result. This can often result in simpler components being combined up into more complex components but without the burden of a "god-like" component having to control multiple layouts.

Quantities

The hierarchy of atomic design works great when using composition to help build up to your larger, more complex components. One of the clearest signs that atomic design isn't being followed is if you've focused on a single stage without considering how they impact each other.

I've seen design systems with a huge number of atoms, which often end up including things like colours which are better described as design tokens rather than components – they aren't really usable on their own. When this happens, there seems to only be two stages – atoms and an "everything else bucket". There isn't much composition or hierarchy at play here as it's only the most basic of components which are getting reused.

With the atomic design pyramid we are emphasising the multiple stages and the relationships between them. Rather than jumping directly from atoms up to pages there should be multiple stages in-between with ever-decreasing stages as you head up to the top of the pyramid. The more components you have at the lower levels, the more you've got that could be easily reused at the higher levels.

Pages are a bit of an exception when it comes to quantity. Pages typically take one of two forms – either a special kind of template which is specifically designed and only used once or a single instance of a template usually generated via a content management system.

Generic versus specific

As a page has been built with a particular need in mind it can be thought of as the most specific component available. When you start going down the pyramid you should find each stage gets increasingly generic, and therefore increasingly reusable.

For example, a login page is a complete entity in it's own right but can only ever be a login page. Thinking about components as being generic is useful when breaking designs down as it helps when finding for any existing components that might be useful, or how to ensure your new components are easily reusable in the future.

For the login page, this page component might be an instance of a two-column template, which itself contains a form organism. The form likely contains a couple of form input molecules and a button atom. The form input molecule might then contain a couple of atoms – form input and validation error.

Lego example

Going back to Lego we can see how this hierarchy is applied by looking at some Lego instructions.

The Lego bricks in the top left in this instruction step can be considered atoms as they are each made up of a single simple element, are just four of hundreds of different brick types and are very generic so could potentially be used in lots of different styles of model.

In the yellow boxes we can see two example molecules in the form of a lamp and tree. These are composed by combining some atoms together into a slightly more complex and specific form. Whilst these are more specific, they are still generic enough to have a fairly large range of reuse opportunities.

Finally, we can see these molecules are applied to a far larger, more complex, organism component. This component is entirely made up of other simple atoms and molecules but when combined is quite a complex model with fewer opportunities for reusing this in other situations.

Summary

Using the hierarchy of atomic design to break our designs down into components of varying sizes, complexities and specificities gives us a framework for ensuring we can easily compose new components and pages up out of existing parts.

Keeping these scales in mind and avoiding too much focus on any single part of the hierarchy helps us achive a component library which encourages maintainability, consistency and good communication.