Extending Atomic Design

Atomic design is now over 6 years old (which is nuts!). I’m thrilled that all these years later the methodology continues to help teams think of their user interfaces as a hierarchical, interconnected set of components that build real product screens.

I thought I’d be sick of talking about this by now, but I’m still passionate about atomic design after hearing so many success stories, as well as witnessing firsthand what happens when teams build design systems in isolation (spoiler: it doesn’t work out too well).

Of course over these last 6 years, the language and tactics around design systems has evolved (even the term “design systems” wasn’t really a thing back in 2013!), so I thought I’d share how some of these other concepts interact with atomic design.

Design tokens: the subatomic particles of atomic design

Thanks to Jina and the Lightning Design System team popularizing the concept, design tokens have helped teams share design properties across platforms. This post explains the concept of design tokens well:

design tokens are an agnostic way to store variables such as typography, color, and spacing so that your design system can be shared across platforms like iOS, Android, and regular ol’ websites

So how does this fit into atomic design? In the natural world, atoms are the basic building blocks of matter. Atoms are the smallest functional units of matter, despite being composed of smaller particles such as protons, neutrons, and electrons.

In the world of UI, design tokens are subatomic particles. The design token color-brand-blue is a critical ingredient of a UI, but it’s not exactly functional on its own. It needs to be applied to an “atom” (such as the background color of a button) in order to come to life.

Atomic design diagram showing tokens preceding atoms

Ions, quarks, and other layers

Atomic design is a methodology for creating deliberate, hierarchical user interface design systems. Like Russian nesting dolls, little components are included in bigger components which are included in bigger components which eventually create entire screens. That’s the extent of it.

Because atomic design is limited in its scope, it doesn’t explicitly deal with a whole lot of things. So I get questions: what about motion in atomic design? Flows? Personas? Business requirements? A/B testing? Localization? Testing?

Inevitably, the limited scope of atomic design leads people to extend it further. This recent post Chris Cid is a great example of that, introducing “ions” as an extension of atomic design:

Ions are a repository to manage the variety of properties that any component can have.

It’s a well considered article and helps give a name for managing the various states components can find themselves in.

People have been sending me thoughts like this since the birth of atomic design, and I think it’s great. But perhaps all of these other considerations can live adjacent to atomic design

Naming. Oh god, naming.

I still receive plenty of emails regarding atomic design’s naming conventions. I wrote about this in my book:

“Atomic design” as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

Yet still, folks find it necessary to contact me in order to “correct” the language I chose. If your team decides that atomic design needs to have 9 stages that are named after the members of the band Chicago, then go for it! Extending atomic design to fit the language and mental models of your team is a great idea; design systems are all about establishing a shared language, so make sure that language is easy to learn.

To change or extend?

These past 6 years have been exciting, and it’s been fun watching all of these design system concepts, insights, ingredients, and tools emerge. So does it make sense to go back to the drawing board and formally modify atomic design to consider all these new concepts? I don’t think so.

Design systems are an umbrella that a whole lot of things live under, and I think it’s a mistake to try to shoehorn all the diverse ingredients & considerations into one crowded place. Many teams I work with are looking for a silver bullet — one tool or concept to rule them all — and I frankly don’t think that’s a good idea. Design systems are made from many ingredients that come together to help the organization tell the story of how they design and build digital things. I hope that atomic design continues to be a helpful mental modal for making components in an interconnected, hierarchical manner. But I hope teams acknowledge and embrace the fact there are many (often overlapping) facets to a design system.