Since the dawn of web development, an epic battle has been raging between efficiency and originality.
On the one hand, designers and developers have a finite amount of time and resources. Using a front-end framework like Bootstrap or Foundation, taking inspiration from another UI, or copying a design element are all perfectly legitimate ways to streamline the creation process.
On the other hand, if everyone is borrowing from the same sources, their websites end up looking incredibly similar. (Check out Every Bootstrap Website Ever for a hilarious example.)
But there’s finally a compromise that allows for both speed and innovation: Atomic design.
In creator Brad Frost’s words, this methodology lets you “create systems that promote consistency and scalability while simultaneously showing things in their final context.”
Not only does it boost efficiency without sacrificing originality, it’s also incredibly helpful for showing your clients and team members what the finished product will look like.
In this post, we’ll dive into the fundamentals of atomic design, how to integrate atomic design into your workflow, and several case studies of teams who have successfully implemented it.
The Basic Concepts of Atomic Design
Atomic Design splits an interface into five levels. From smallest to largest, they are: atoms, molecules, organisms, templates, and pages.
An atom refers to any element within your interface that can’t be broken down any further without losing its functionality, such as a button, an input, a form label, a font, a color, an animation, etc. You can visualize an atom as a single Lego piece.
A molecule is a group of atoms, and for obvious reasons, they’re much more useful. For example, a button by itself can’t accomplish anything, but a button next to an input and form label creates a search form. Molecules are equivalent to three or four Lego pieces joined together.
Next up, you have an organism, which is a group of molecules. Frost explains these are distinct parts of the interface—like the header, the footer, a product grid, and so forth—that you can recycle throughout your design. Using the Lego analogy, a molecule is like a Lego table: You took two combined units and put them together to form something recognizable and reusable.
A template organizes your organisms. That is, it specifies where each piece of content goes and how it appears. When you first design a template, it’ll probably look like a low-fidelity wireframe, and as the design process advances, it’ll slowly transform into a full-fledged mock-up. In Lego terms, a template is the rectangular base outlining where all the other Legos will go.
Finally, you have a page: a template that’s been fleshed out into the final interface. Unlike templates, which use placeholder content, pages contain real content. Unsurprisingly, a page equals a complete Lego model.
Pages are really important. Not because you should be designing from the page down—in fact, atomic design advocates doing the opposite. In this model, pages are important because they tell you whether or not your atoms, organisms, and templates work. Furthermore, they allow you to test how your design holds up under different conditions. For instance, usernames might look great if they’re 10 letters or less, but what does a 15-letter username look like? Does it end up spilling over onto the next line?
Pages give you the chance to test your modules “in the wild” and correct any issues you see. Happily, since components are meant to be reused, fixing an error in one molecule, organism, or template means it’s fixed in all iterations.
How to Design With Modules
Now that you’re familiar with the terms, let’s get to the fun part: putting them into action.
If you’re starting a new project from scratch, you can immediately begin coding and combining reusable modules.
But it’s pretty rare to begin a project that doesn’t have existing elements. More likely, you’re improving your company’s current site or working on a redesign for a client.
Whatever the case, if content already exists, you need to run an interface audit. This process is similar to a content inventory—but rather than documenting your images, text, documents, and so on, you’re documenting everything that makes up the user interface—from icons and image types to lists and rich media. The results of the audit will live in an interface inventory, which you can think of as a cross between a pattern library and a style guide.
Systematically go through the interface and document every unique element you can find. Don’t document a single pattern more than once; for instance, if you’ve already screenshotted the breadcrumb pattern on the homepage, you don’t need to screenshot it again on, say, the “Case Studies” page.
Once you’ve finished compiling your content, do some house-keeping. If you’ve found inconsistent modules—which you almost certainly will—standardize them so the patterns are universal across your UI.
You should also name your atoms, molecules, organisms, and templates. While this step is a little less important when you’re working solo, it’s essential when you’re collaborating with designers, developers, project managers, copywriters, and any other team members—having a consistent vocabulary will make miscommunications far less likely.
To give you an idea, check out how CodePen named its forms: .FORM-LIKE-FORM and .TOP-LABEL-FORM.
(For guidance on choosing names, check out Alla Kholmatova’s post on A List Apart) .
Creating a content inventory is definitely time-consuming, whether you’re building it from the ground up or pulling in existing conventions. But in the long run, it’ll save you countless hours. You’ll be able to find specific sections of code almost instantly, you can modify existing elements without wondering how your changes will impact other elements, and you can essentially copy and paste modules from one section of your site to another (and another, and another, ad infinitum.)
Examples of Atomic Design in Action
Since Atomic Design started gaining ground in 2014, several teams have published case studies detailing how they’ve implemented it.
Case study #1: FutureLearn
For roughly a year, the team behind FutureLearn used a simple, list-format style guide to document the elements of its site. But finding specific info within this style guide was difficult; plus, it quickly fell out-of-date with the live site.
So, FutureLearn’s designers and developers decided to create a “living pattern library.” It has four sections: core patterns, atoms, molecules, and organisms. Each element has a name, a short description, a screenshot example, and the underlying CSS and markup.
Case Study #2: Route 93 Pizza Mill
Montana design firm Jtech Communications used Atomic Design principles to create a cohesive, on-brand website for Route 93 Pizza Mill.
First, the agency created a content inventory for Route 93. Since the scope of the restaurant’s site is fairly limited (it’s a one-page site with just four sections), the pattern library’s scope is fairly limited as well. It includes atoms (such as vectors, icons, headings, etc.), molecules (images with text overlays, forms, etc.), and organisms (the fully designed footer).
“By designing an Interface Inventory with the Atomic Design process, we can start with primitive modules and assemble them into completed elements,” explains Mira Brody. “This process improves efficiency, communication among team members, and produces a more beautiful website overall.”
Case Study #3: HBR.org
Front-end developer Daigo Fujiwara and his team members used atomic design to create a responsive site for Harvard Business Review. They used Pattern Lab (also produced by Brad Frost) to create a visual library of building blocks—which Fujiwara says were all created to be “mobile first.” They operated by two main principles: first, to separate the “structure” and the”skin” (in which the structure contains the core of an object and the skin extends its visual representation), and second, to separate the “container” and the “content” (i.e., avoid location-dependent styles.)
You can read Fujiwara’s blog post on the redesign to learn more about his team’s tools and workflow.
Plus, check out Daisy: a vagrant and grunt-powered Pattern Lab that updates automatically.
Want to learn more about this modular methodology, or simply reinforce your understanding? Check out these links:
Designing Atoms and Elements: a short refresher on the concepts we just covered.
Style Guide Driven Development: an exploration of how to build your style guide as you design.
Creating a Killer Style Guide: five tips for building a guide that scales.
Style Guides: a library of style guides from design powerhouses like Mailchimp, Adobe, and Airbnb.
50 Meticulous Style Guides Every Startup Should See Before Launching: another round-up of well-executed style guides.
Pattern Lab: Frost’s custom static site generator that uses atomic design.
Brad Frost’s Blog: a frequently updated thought leadership and advice blog.