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.
The “page” metaphor is dead
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.
- Pages are not a golden means of organizing information architecture. This is now accomplished in various sections throughout a site or product, each designed, styled, and built appropriately for the content it contains.
- Page count are a poor litmus for complexity of a project. An app or website with just two pages can be complex, requiring different modules and styles on each page; yet one with 30,000 pages can be straightforward, each using the same template over and over.
- Pages are no longer a good or accurate abstraction for the structure of web and mobile content. A world filled with carousels, infinite scrolls, galleries, and more, no longer resembles the static, basic pages of yesteryear.
- The pages metaphor trickles into product design, where often designer approach the product “page by page”. Multi-device experiences (especially for web, where a design is responsive to the device) involve much more than showing your client (or boss) hundreds of static page comps. Each element has it’s own set of challenges and demands deliberate thought.
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?
Design Systems
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?
Why use a pattern library?
Pattern libraries provide:
- Development and design speed. Putting together a design library may be a lot of work upfront, but it makes future work much easier. You can pull elements from existing designs rather than re-creating them each time.
- Consistently good design and cohesion across a user interface.
- Consistent design feels more trustworthy to the end user. Imagine going to a website where different pages look like they were designed ten years apart? (See: a website for any bank, insurance company, or government).
- By having a style guide, designers and developers have to consider how their work fits into the bigger design system.
- Shared vocabulary. Everything has a consistent name, making it easy to reference things, especially as a team grows.
- Education. Anyone can read the style guide and it will communicate the language and product design thought process to the reader.
- Faster QA. Breaking an interface into its components makes it much easier to discern what is breaking during the testing phase.
“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.
How to create a pattern library? Enter Atomic Design
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
- Molecules
- Organisms
- Templates
- Pages
Atoms
“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
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.
Organism
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.)
Templates
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.
Pages
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.
Putting it together
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.”
Example: Instagram
Photo credit: Atomic Design by Brad Frost
Using a design pattern library
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:
When choosing tools to create your pattern library, you should keep your eyes open for these qualities and features of effective pattern libraries: (1) providing pattern descriptions and annotations; (2) showcasing the relevant pattern HTML, templating CSS, and/or JavaScript code; (3) viewing patterns across the entire resolution spectrum; (4) the ability to showcase pattern variations, such as active or disabled tabs; (5) the ability to dynamically add real representative content into the patterns’ structures; (6) providing contextual information, like which patterns make up a particular component, as well as where that component is used.
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.
Building an Interface Inventory
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:
- Global elements (headers, footers)
- Navigation (primary navigation, footer navigation, pagination, breadcrumbs)
- Image types
- Icons
- Forms
- Buttons
- Headings
- Blocks (summaries, call outs, hero units)
- Lists
- Interactive components
- Media
- Third-party components
- Advertising (formats and dimensions)
- Messaging
- Colors
- Animation
“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”
Maintaining a Pattern Library
Pattern Library maintenance boils down into two parts:
- Having a clear person (or team) responsible for the creation, maintenance, and governance of the pattern library. This person/group makes all final decisions, evangelizes the pattern library to the team, makes updates to keep it in sync with the product, deprecates outdated or unused patterns, communicates changes to the team, and more.
- Communication with the team that uses the pattern library. Teach them how to use it. Ask for feedback. Spread the news about updates. Make sure the pattern library remains on the users’ radar
Buy Atomic Design from Brad Frost