Atomic design is a framework for thinking about interfaces, making teams efficient, UIs consistent, and big products manageable. It describes in detail how to successfully introduce modular (atomic!) design systems to your company and make them a permanent fixture in your product design process.
We think of websites and products as composed of units called “pages”.
While appropriate for the early days of the internet, the page metaphor now fails product teams and cripples products.
Designers should instead adopt a modular approach similar to that used in engineering. Each module in a UI has its own set of challenges and constraints. Each element requires deliberate thought and design decisions.
Front-end frameworks are getting closer to the right idea. The upside is speed and cross-browser functionality. But the downside is big for individual companies: lack of flexibility, customization, and ability to grow the system once you’re past the early MVP stage. Eventually you end up fighting the framework.
Instead, what you need is a design system for each company. A unique design system that captures the identity and voice of the company, with elements you can create, customize, update, and fully control.
“For us to create experiences for this eclectic web landscape, we must evolve beyond the page metaphor that’s been with us since the birth of the web. Thankfully, organizations are embracing modularity across every aspect of the web creation process, which is leading to smarter work and more sustainable systems.”
So what does a robust design system look like?
A company’s design system should capture the product design philosophy and direction. It can include: brand identity document, code style guides, component pattern libraries, and more.
The remainder of the book approaches the pattern libraries (also called front-end style guides, UI libraries, or component libraries). How can you create and maintain a pattern library?
Pattern libraries provide:
“There’s no doubt style guides help teams effectively get things done in the here and now. But much like a fine wine, style guides increase in value over time. The beautiful thing about interface design systems is that they can and should be modified, extended, and refined for years to come”
It’s important to treat style guides as a primary project for your company – to treat it like the final product, even – as opposed to a designer’s pet project, relegated to the end of the design process, only updated “if there’s time” (there never is).
Think of the style guide as where your other projects start and end. Someone commits to governing, updating, and evangelizing it. They collect feedback from design system users throughout the company. And design system users refer to the library for UI components, design patterns, and best practices.
The atomic design metaphor takes inspiration from chemistry. The smallest unit is the atom. Atoms combine to form molecules. Molecules continue to build complex organisms.
Our interfaces can be broken down into similar sets of elements, much like the periodic table of elements.
The periodic table of HTML elements by Josh Duck.
The five levels of atomic design are:
“Atoms of our interfaces serve as the foundational building blocks that comprise all our user interfaces”
Atoms are the smallest components. A title. A label. A test input area. A button. Each of these is a crucial building block. But currently, they lack context. That’s where molecules come in…
Molecules are a combination of atoms. For instance: a title, a label, button, and text input form are atoms that combine to create a form molecule. They now have context. The label labels the text input area. The button submits the text entered in the input.
This third layer of abstraction (also the final part of the chemistry analogy) are relatively complex UI components composed of atoms and molecules. They form distinct sections of an interface, like a header, footer, etc.
Some organisms are composed of a variety of different atoms and molecules (like a header). Other organisms are repetitive (like the product listing or search results, where each element returned is structurally identical the others.)
A template is a page-level object. The main contribution of a template is that it defines the content structure.
You don’t need the final content in a template—a template is just the content structure.
Templates are particularly useful for something like a news app or website. You don’t want to redesign each page every day or for article, so you need templates that you can fill-in with the latest news.
A page is a template with the real content in place.
This is the real deal. What your users will see, what your stakeholders will sign off on.
Pages are also where you create multiple versions of a design to showcase the various possible permutations of the page content. These may include: shopping carts with different number of items; tweets of different lengths; a post with comments, or without comments; and so on.
Atomic design is not a linear process. You don’t start with atoms and then work your way to pages.
Rather, atomic design is a mental model for approaching your designs.
“Atomic design as a mental model that allows us to concurrently create final UIs and their underlying design systems… Atomic design gives us a language for discussing the structure of our UI patterns and also the content that goes inside those patterns. While there is a clean separation between the content structure skeleton (templates) and the final content (pages), atomic design recognizes the two very much influence each other.”
Photo credit: Atomic Design by Brad Frost
It doesn’t matter what tool you use (although, author Brad Frost seems to really want you to use Pattern Lab), but here’s a short list of things you should be sure your pattern library tool can do.
From the book:
You should be able to view all of your atoms, molecules, etc. You should be able to see where they are used, to make testing easier after a change. You should be able to see what other elements they contain, if any. You should be able to dig in and see the code for each. You should be able to make variations of each and track those. And you should have a tool that allows you to test your elements in a variety of browser sizes.
Sometimes, your team isn’t vested in building a design patterns library. To increase buy-in, try an exercise to inconsistency of your UI. Get all stakeholders into a room and work on an Interface Inventory. Use a tool like Google Slides a record one in stance of every Interface component.
Components to include:
“One of the most powerful benefits of interface inventories is that you can show them to anyone, including non-designers and developers, and they’ll understand why inconsistent UIs are problematic”
Pattern Library maintenance boils down into two parts: