Atomic design is about more than naming

Photo by Harpal Singh on Unsplash

In 2013 Brad Frost published posts about atomic design on his website. His idea of a nested design system like a Russian nesting doll or atoms and molecules wasn’t completely new. What made his idea interesting is how he systematised it and provided a simple explanation of how the system worked — even examples.

A few years later, it is now becoming a household name in the design and development industries. As with all ideas when they start becoming popular, they end up getting distorted. It happened with Agile and SCRUM methodologies before it, as they become popular buzzwords people seemed to care more about saying them and adding them to their CVs rather than use them properly.

The dilution of popular frameworks

Not to say that systems shouldn’t be adapted to the context and circumstances, after all, they were designed to be flexible. Things start falling apart when people end up implementing only the parts of the systems they like, or when they don’t understand the purpose of the system.

I’ve come across multiple instances of broken SCRUM where tasks were sized according to convenience so people could game the system. This resulted in very neat velocity graphs and backlogs, but the end result in practice wasn’t going anywhere. This tends to happen when PMs and SCRUM Masters focus too much on the system and forget its original purpose of helping the product development.

Unfortunately, Atomic design seems to be going through a similar process.

Buzzwords can be harmful

To see what I mean, take a look at this quote:

To lower combinatorial impairment try thinking in an enterprise Atomic Design.

Though it might seem like something you hear in a talk or read in a book, it was actually randomly generated on uxbullshit.com. The way I see it when you hear people saying things that might as well have been generated by a script, there is something wrong with how your idea is perceived. This leads to the ideas being poorly or partially implemented.

As an example, let’s have a look at the Aviva Design Framework.

Aviva Design Framework — date range

If you go through the components you see they are labelled as Atom, Molecule, Organism and Template, just like Atomic Design components are meant to be.

This makes it more “atomic” than most other frameworks you can find now, such as the BBC’s, the British Government’s, or MailChimp’s to name a few.

These other frameworks, which never claimed to be “atomic”, simply list the elements and patterns they use in libraries of components, using a flat structure.

Pattern Lab

Now, compare it to Pattern Lab, which was created by Brad Frost to exemplify his Atomic Design ideas. Here the components are all related to each other. Each Molecule is built with Atoms, each Molecule can be strung together with others to form Organisms and they can be grouped to make Templates and Pages.

This is where Aviva’s framework falls short. Despite labelling the components correctly, they are organised as a linear library. All the complex relations in Atomic Design are lost. Therefore, there must be more to it than simply the naming.

What Atomic means for a library structure

So, if that’s the case, what exactly is missing, or what should be done differently?

As an example, let’s take BBC’s cards which stand alone within the library, as it’s not atomic, and see how would look like within an atomic library.

This is a common pattern, found on many sites and apps today. In BBC’s case, they divide it up into an image or video, body content and a footer with buttons.

Card — BBC framework

So let’s try to divide it into the smallest components. There are several ways to do this, so here is an example:

BBC’s card deconstructed

These should be the smallest components we can divide the card into, atoms. According to Atomic Design, these indivisible components should be able to be used in other larger components - molecules.

BBC’s Content Utility Atom in use

This is indeed what we end up seeing with, for example, the Content Utility atom.

The atom’s page in the library describes its behaviour in different contexts and within different molecules.

Likewise, we can expect to see the Card component used in larger patterns.

BBC’s cards in a carousel

Carousels are one of these patterns, using a variation of the cards described above and, in turn, the atoms contained therein.

So with all this in mind, we can start structuring the components according to the relationships between them, in an atomic fashion.

Starting with the simplest components we identified above as atoms, they come together to form the Card we started with, so we can label it as a molecule. The Card, in turn, is used in more complex patterns such as the Carousel, which then becomes an organism.

So we end up with a structure like so:

BBC’s card atomic architecture diagram

This is the structure of the Card alone. Each of the atoms in this diagram would have diagrams of their own, connecting to other molecules, and the Carousel would also connect to other molecules, atoms, and templates.

In this sense, an Atomic Design library won’t have such a linear structure but a more organic one, where components connect to each other in a web or graph.

Using Atomic structure

Atomic structure is beneficial not only to Ux and Visual designers but also to Developers. For the latter, it allows the creation of standalone components in code which can be nested. So instead of coding all the buttons in a taskbar, for example, you can write your taskbar and say it contains so many of these button components. The same can be done when designing in most professional software using tools like Symbols in Sketch and Illustrator.

This allows for faster and more consistent iterations, but also if you need to make a change to, for example, a button it would propagate to all its instances since they are just references to it and not duplications.


Originally published at goncaloandrade.com on March 26, 2018.