Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Brad Frost
Atomic Design
Brad Frost
Table of Contents
1. Designing Systems
Create design systems, not pages 8
Resources 184
Brad’s screen looked like a webpage had exploded. Bits and pieces of UI
floated free of each other, untethered by a unified design or hierarchy.
It looked like a pile of spare parts from a web garage.
Brad flashed his crazy grin and nodded, “Great, right?” The three of
us stared back blankly. Somebody coughed.
And then Brad Frost the front-end developer started talking like Brad
Frost the chemist. He talked about atoms and molecules and organisms
– about how large pieces of design can be broken down into smaller
ones and even recombined into different large pieces. Instead
of visualizing the finished recipe for the design, in other words, he
was showing us the ingredients. And we lit up: this was a shift in
perspective, a way to move away from conceiving a website design as
a collection of static page templates, and instead as a dynamic system
of adaptable components. It was an inspired way to approach this
responsive website – and all responsive projects for that matter.
Brad’s new idea was atomic design, and it changed the way we work
in this astonishingly multi-device world. By thinking about interfaces
simultaneously at both the large (page) level as well as the small
(atomic) level, we streamlined our process: we introduced more rigorous
thought into the role of every element; we fell into habits that improved
the consistency of our UX; and crucially, we started working much faster
and more collaboratively. Atomic design was our superpower.
In the early stages of the TechCrunch redesign, there was this moment
where we talked about what we wanted the article page to be. Within
an hour, Brad had a fully responsive version wired up from his kit of
parts. That was the moment we realized just how quickly we were going
to be able to move, a powerful case for investing in this clever, modular
approach.
6 ATOMIC DESIGN
including blockbuster sites for Entertainment Weekly and Time, Inc.
We’ve used these lessons to help in-house product teams make
sites faster and with higher quality, build massive design systems
for organizations looking to centralize their design and development
work across international offices, and much more.
Brad’s energy and big-hearted enthusiasm for the web and its
makers are boundless. For years, Brad has worked at the forefront
of responsive design technique – and he’s shared everything along
the way. His This Is Responsive site is the go-to resource for finding
responsive solutions to any UX problem. His blog and Twitter feeds
share his roadblocks and his solutions. When designers and developers
follow Brad Frost, they get a fast and dense stream of practical,
passionate insight for building beautiful and resilient websites.
This book doubles down on all of that.
Given the chance, Brad would knock on the door of every designer
and developer to personally deliver his message. We’ve watched
with astonishment (and mild envy) as this whirling dervish has
barnstormed around the globe to share his advice with hundreds of
teams and organizations across six continents. (Atomic design, coming
soon to Antarctica!) But even Brad Frost can’t be everywhere at once,
and we’re delighted that he’s detailed his ideas with such depth and
good humor in this book.
- Josh Clark and Dan Mall, Brad’s frequent collaborators and his
biggest fans
FOREWARD 7
Chapter 1
Designing
Systems
Create design systems, not pages
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
8 ATOMIC DESIGN
A long, long time ago, there were these things called books.
Remember them? These contraptions were heavy and bulky and
made from the pulp of dead trees. Inside these books were things
called pages. You turned them, and they cut your fingers.
Awful things. I’m so glad these book things with their razor-sharp
pages aren’t around anymore.
Oh, wait…
The page metaphor has been baked into the lexicon of the web since
the very beginning. Tim Berners-Lee invented the World Wide Web
so that he, his colleagues at CERN, and other academics could easily
share and link together their world of documents. This document-
based, academic genesis of the web is why the concept of the page is
so deeply ingrained in the vocabulary of the internet.
So what?
As we’ll discuss throughout this book, the way things are named
very much impacts how they’re perceived and utilized. Thinking
of the web as pages has real ramifications on how people interact
with web experiences, and influences how we go about creating web
interfaces.
In the early days of the web, companies looking to get online simply
translated their printed materials onto their websites. But even
though these brochure websites offered a very one-dimensional
perspective of what the web could offer, viewing websites as digital
representations of the printed page was easy for creators to wrap
their heads around.
But we’re now 25 years into this new medium, and this
once necessary figure of speech has overstayed its welcome.
Unfortunately, the page metaphor continues to run deep with
respect to how we scope and execute our web projects. Here are
just a few examples I hear on a regular basis:
10 ATOMIC DESIGN
All of the statements above make the fundamental mistake of
assuming a page is a uniform, isolated, quantifiable thing. The
reality is that the web is a fluid, interactive, interdependent
medium. As soon as we come to terms with this fact, the notion
of the page quickly erodes as a useful means to scope and create
web experiences.
How long will a homepage take to build? Well, that sort of depends
on what’s on it, right? Maybe the homepage simply consists of a
tagline and a background image, which means it could be done by
lunch. Or maybe it’s chock-full of carousels, dynamic forms, and
third-party integrations. In that case, maybe the homepage will
take several months to complete.
The page metaphor has served its purpose helping users familiarize
themselves with the web, and provided creators with the necessary
transitional language with which to create for a brand new medium.
But to build thoughtful interfaces meant to be served to a multitude
of connected devices, the time has come for us to evolve beyond
the page.
Slowly, but surely, these concepts found their way into web designers’
workflows. In the early 2000s we saw the introduction of libraries
like YUI and jQuery UI that provided developers with a toolkit of
widgets and patterns to create more consistent user interfaces.
If modularity has been around for such a long time, why are we
talking about it now?
The short answer is that modularity matters more than ever. Right
now, our entire industry is drowning in a sea of devices, viewport
sizes, and online environments. And things aren’t slowing down
anytime soon.
12 ATOMIC DESIGN
These are just some of the connected devices we need to worry about.
And that’s exactly what folks are doing. The spirit of modularity
is weaving its way into every aspect of the web creation process
and having profound effects on organizations’ strategy, process,
content, design, and development.
A manageable strategy
Every organization is finally realizing that bulldozing their entire
website and replacing it with a New-And-Shiny™ website every
three to eight years isn’t (and never was) an optimal solution.
An iterative process
If I had a quarter for every time I heard some stakeholder declare
“We’re trying to be more agile,” I’d be orbiting the earth in my
private spacecraft instead of writing this book.
14 ATOMIC DESIGN
Lowercase-a agile is more of an informal desire to create an
efficient process. This desire may certainly involve adopting general
principles from capital-A Agile, but it may not involve adopting the
Agile process in its entirety. Project manager Brett Harned explains:
- Brett Harned
- Karen McGrane
Classy code
Modularity has long been a staple principle in the world of
computer science, as we discussed earlier. While this principle
existed long before the web was invented, it has taken some time
for modularity to become engrained in the minds and hearts of
web developers.
16 ATOMIC DESIGN
Visually repaired
Not only is modularity infiltrating the code side of style on the
web, it’s revolutionizing how visual designers approach modern
web design.
That’s not to say static design tools like Photoshop and Sketch
aren’t important. Far from it. But it’s the way we use these
tools that has changed dramatically. While creating hundreds
of full-on comps isn’t realistic, these static tools excel at
providing a playground to establish what Andy Clarke calls
“design atmosphere”:
- Andy Clarke
Systematic UI design
- Stephen Hay
What is an interface made of? What are our Lego bricks? What
are our Subway sandwich pieces that we combine into millions of
delicious combinations? It’s these questions that we’ve been asking
ourselves more and more now that we’re sending our interfaces to
more and more places.
18 ATOMIC DESIGN
that smartly adapt to any screen size. Perhaps more importantly,
responsive design helped get designers excited about creating
thoughtful, adaptable, multi-device web experiences.
And boy are these things popular. As I’m writing this, Bootstrap is
the most popular repository on the code-sharing site GitHub, with
over 77,000 stars and 30,000 forks. These frameworks’ popularity
is a testament to the fact that designers and developers are seeking
solid ground to stand on in this ever-complex web landscape.
For freelancers, this increase in speed might mean they can take
on an extra project or three, yielding more financial stability for
the year. And in the startup world – a place where Bootstrap is
20 ATOMIC DESIGN
omnipresent – minimum viable products can launch sooner,
leading to faster answers regarding the products’ viability.
In the future, everyone dresses the same. Illustration credit: Melissa Frost.
I could only guess that given enough time, we solve fashion. “Say,
these jumpsuits are pretty snazzy, and comfortable too! Let’s just
all wear these from now on.” “Sounds good to me!”
Of course, that’s not how human beings work. We all have different
tastes, goals, and desires. Variety, as they say, is the spice of life,
and fashion, music, and design reflect our diverse nature. Yet on
the web we tend to fall into the trap of wanting everyone to do
things the same way. “Why don’t all browsers just standardize
on WebKit?” “Why can’t device manufacturers just use the same
screen sizes?” “Always use jQuery!” “Never use jQuery!” “Just use
frameworks!” “Never use frameworks!”
22 ATOMIC DESIGN
Now that we’ve put frameworks through the wringer, it’s
important to take a step back and recognize that conceptually these
frameworks are very much on point. It’s an excellent idea to work
with a design tool kit that promotes consistency and speeds up
development time. While discussing the redesign of Microsoft’s
homepage by Austin-based web shop Paravel, developer Dave
Rupert stressed the importance of creating and delivering a design
system to their client. Dave wonderfully articulated that it’s not
necessarily about using Bootstrap for every client, but rather
creating “tiny Bootstraps for every client.”
- Dave Rupert
It’s not just about using a design system, it’s about creating
your system.
24 ATOMIC DESIGN
Design language
While brand identity guidelines are fairly tactile, design language
guidelines are a bit harder to pin down. Design language style guides
articulate a general design direction, philosophy, and approach to
specific projects or products.
Design language guidelines aren’t set in stone the way brand guidelines
are. For example, one day Google will likely develop a new design
language to replace material design, so while Google’s overall brand will
remain intact, the design vocabulary around its products will change.
A brand’s voice stays the same from day to day, but its tone has
to change all the time, depending on both the situation and the
reader’s feelings.
Voice and tone guidelines get into the weeds by articulating how
the company’s voice and tone should shift across a variety of
scenarios. MailChimp’s brilliant voice and tone guidelines define
26 ATOMIC DESIGN
how the brand’s tone changes across content types, so that when a
user’s credit card is declined, writers know to shift away from their
generally cheeky and playful tone of voice and adopt a more serious
tone instead.
Writing
The rise of the web and content-managed websites makes it
easier than ever for many people within an organization to
publish content. This, of course, can be a double-edged sword, as
maintaining a consistent writing style for an organization with
many voices can be challenging. Writing style guides provide every
author some guidelines and guardrails for contributing content.
GitHub’s code style guide provides best practices for writing HTML, CSS, JavaScript, and Ruby
within their organization.
28 ATOMIC DESIGN
Pattern Libraries
And now for the main event. Pattern libraries, also known as front-
end style guides, UI libraries, or component libraries, are quickly
becoming a cornerstone of modern interface design.
Style guides are important tools that help prevent chaos, both
from a design and development standpoint and also from an
organizational perspective. Here’s why style guides are now
essential tools for modern web design and development.
Even third parties responsible for matching their UIs with the
look and feel of a company’s internal UIs can make great use of a
style guide. Externally hosted experiences like payment portals or
localized sites can better match the look and feel of the primary
experience by applying the styles defined in the guide.
A shared vocabulary
What does “utility toolbar” mean? Does everyone understand what
a “touch slider hero” is?
30 ATOMIC DESIGN
Giving names to patterns like ‘Blocks Three-Up’ in Starbucks’ style guide helps team members
speak the same language.
Education
In her book Front-End Style Guides, Anna Debenham deftly explains
the many advantages of creating style guides, including one of the
most crucial benefits: education.
- Anna Debenham
Style guides can help alleviate what I call special snowflake syndrome,
where certain departments in an organization think that they
have unique problems and therefore demand unique solutions.
By exposing the design system in the form of a style guide,
these special snowflakes can better appreciate consistency and
understand why their requests for custom designs receive pushback.
Speed
Earlier in the chapter we discussed how faster design and development
is one of the main reasons why UI frameworks like Bootstrap are so
popular. We’re under pressure to get projects out the door as soon as
humanly possible. By developing your own design system, you can
reap those same speed rewards as the out-of-the-box UI tool kits.
32 ATOMIC DESIGN
effort. But once the pattern library is established, subsequent
design and development becomes much faster, which tends to make
everybody happy.
- Federico Holgado
A matter of time
The hard part is building the machine that builds the product.
- Dennis Crowley
34 ATOMIC DESIGN
Auxiliary Projects
Pattern libraries are often treated as auxiliary projects, rather than
as the component parts of the final product. By treating pattern
libraries as something separate from the core project, they tend to
fall into the nice to have category and become first on the chopping
block when the going gets tough.
Audience confusion
Style guides can be misunderstood as tools useful only to
designers or developers, which leads to a lack of visibility that
immediately limits their effectiveness. Instead of serving as a
watering hole for everyone in the organization, a style guide can
become a best-kept secret guarded by one discipline. Color me
naive, but I don’t think this helps foster a culture of collaboration.
Yelp’s style guide homepage sports a handsome design and important intro text explaining the
purpose and audience for the guide.
Lack of context
Context is key to understanding a design system. Unfortunately,
most pattern libraries out in the wild don’t provide any hints as
to when, how, and where their components get used. Without
providing context, designers and developers don’t know how global
a particular pattern is, and as a result wouldn’t know which pages
of their app would need to be revisited, QA’d, and tested if changes
were made.
36 ATOMIC DESIGN
‘Highlight Block’ looks useful, but where is this pattern being used?
Atomic Design
Methodology
Atoms, molecules, organisms,
templates, and pages
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
38 ATOMIC DESIGN
My search for a methodology to craft interface design systems led
me to look for inspiration in other fields and industries. Given this
amazingly complex world we’ve created, it seemed only natural that
other fields would have tackled similar problems we could learn from
and appropriate. As it turns out, loads of other fields such as industrial
design and architecture have developed smart modular systems for
manufacturing immensely complex objects like airplanes, ships, and
skyscrapers.
If you’re like me, you may need a bit of a refresher to recall what a
chemical equation looks like, so here you go:
An example of a chemical equation showing hydrogen and oxygen atoms combining together to
form a water molecule.
ɕ Atoms are the basic building blocks of all matter. Each chemical
element has distinct properties, and they can’t be broken down
further without losing their meaning. (Yes, it’s true atoms
are composed of even smaller bits like protons, electrons, and
neutrons, but atoms are the smallest functional unit.)
ɕ Molecules are groups of two or more atoms held together by
chemical bonds. These combinations of atoms take on their own
unique properties, and become more tangible and operational
than atoms.
ɕ Organisms are assemblies of molecules functioning together
as a unit. These relatively complex structures can range
from single-celled organisms all the way up to incredibly
sophisticated organisms like human beings.
Of course, I’m simplifying the incredibly rich composition of the
universe, but the basic gist remains: atoms combine together to
form molecules, which further combine to form organisms. This
atomic theory means that all matter in the known universe can be
broken down into a finite set of atomic elements:
40 ATOMIC DESIGN
Apparently Mr. Rae’s strategy of having students mind-numbingly
balance tons of chemical equations worked, because I’m coming
back to it all these years later for inspiration on how to approach
interface design.
1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages
Atomic design is atoms, molecules, organisms, templates, and pages concurrently working together
to create effective interface design systems.
42 ATOMIC DESIGN
Atoms
If atoms are the basic building blocks of matter, then the atoms
of our interfaces serve as the foundational building blocks that
comprise all our user interfaces. These atoms include basic HTML
elements like form labels, inputs, buttons, and others that can’t be
broken down any further without ceasing to be functional.
Each atom in the natural world has its own unique properties.
A hydrogen atom contains one electron, while a helium atom
contains two. These intrinsic chemical properties have profound
effects on their application (for example, the Hindenburg explosion
was so catastrophic because the airship was filled with extremely
flammable hydrogen gas versus inert helium gas). In the same
42 https://developer.mozilla.org/en-US/docs/Web/HTML/Element
Molecules
44 ATOMIC DESIGN
A search form molecule is composed of a label atom, input
atom, and button atom.
Let’s revisit our search form molecule. A search form can often
be found in the header of many web experiences, so let’s put that
search form molecule into the context of a header organism.
This header organism is composed of a search form molecule, logo atom, and primary
navigation molecule.
46 ATOMIC DESIGN
Organisms like website headers consist of smaller molecules like primary navigation, search forms,
utility navigation, and logos.
Templates
48 ATOMIC DESIGN
Now, friends, it’s time to say goodbye to our chemistry analogy.
The language of atoms, molecules, and organisms carries with it a
helpful hierarchy for us to deliberately construct the components
of our design systems. But ultimately we must step into language
that is more appropriate for our final output and makes more sense
to our clients, bosses, and colleagues. Trying to carry the chemistry
analogy too far might confuse your stakeholders and cause them to
think you’re a bit crazy. Trust me.
- Mark Boulton
50 ATOMIC DESIGN
Time Inc.’s homepage template demonstrates the content’s underlying structure.
Now that we’ve established our pages’ skeletal system, let’s put
some meat on them bones!
The page stage is the most concrete stage of atomic design, and it’s
important for some rather obvious reasons. After all, this is what
users will see and interact with when they visit your experience.
This is what your stakeholders will sign off. And this is where you
see all those components coming together to form a beautiful and
functional user interface. Exciting!
52 ATOMIC DESIGN
The page stage replaces placeholder content with real representative content to bring the design
system to life.
54 ATOMIC DESIGN
Pages also provide a place to articulate variations in templates,
which is crucial for establishing robust and reliant design systems.
Here are just a few examples of template variations:
ɕ A user has one item in their shopping cart and another user has
ten items in their cart.
ɕ A web app’s dashboard typically shows recent activity, but that
section is suppressed for first-time users.
ɕ One article headline might be 40 characters long, while another
article headline might be 340 characters long.
ɕ Users with administrative privileges might see additional
buttons and options on their dashboard compared to users who
aren’t admins.
The painter, when at a distance from the easel, can assess and
analyze the whole of the work from this vantage. He scrutinizes
and listens, chooses the next stroke to make, then approaches the
canvas to do it. Then, he steps back again to see what he’s done
in relation to the whole. It is a dance of switching contexts, a
pitter-patter pacing across the studio floor that produces a tight
feedback loop between mark-making and mark-assessing.
- Frank Chimero
56 ATOMIC DESIGN
Atomic design lets us dance between contexts like the painter Frank
so eloquently describes. The atoms, molecules, and organisms that
comprise our interfaces do not live in a vacuum. And our interfaces’
templates and pages are indeed composed of smaller parts. The
parts of our designs influence the whole, and the whole influences
the parts. The two are intertwined, and atomic design embraces
this fact.
- Mark Boulton
On the left we see the UI’s content skeleton, which consists of the
same person block molecule repeated again and again. On the right
we see what happens when we populate each instance of the person
block molecule with representative content. Visualizing the content
skeleton and the representative final content allows us to create
patterns that accurately reflect the content that lives inside them. If
a person’s name were to wrap onto five lines within the pattern, we
would need to address that broken behavior at a more atomic level.
58 ATOMIC DESIGN
The content we pour into our UIs at the page stage will influence the
characteristics and parameters of the underlying design patterns.
What’s in a name?
Throughout this book I’ve mentioned that modular design and
development is nothing new. So why are we introducing terms like
atoms, molecules, and organisms when we can just stick with established
terms like modules, components, elements, sections, and regions?
For as long as I’ve been talking about atomic design, I’ve had people
proffer alternate names for the stages of the methodology. Person
One would suggest, “Why not just name them elements, modules,
and components?” while Person Two would suggest, “Why not just
name them base, components, and modules?” The issue with terms
like components and modules is that a sense of hierarchy can’t be
deduced from the names alone. Atoms, molecules, and organisms
imply a hierarchy that anyone with a basic knowledge of chemistry
can hopefully wrap their head around.
That being said, naming things is hard and imperfect. The names I’ve
chosen for the stages of atomic design have worked really well for me
and the teams I’ve worked with as we create UI design systems. But
maybe they don’t work for you and your organization. That’s more
than OK. Here’s one perspective from the design team at GE:
You can apply the atomic design methodology to the user interface
of any software: Microsoft Word, Keynote, Photoshop, your bank’s
ATM, whatever. To demonstrate, let’s apply atomic design to the
native mobile app Instagram.
60 ATOMIC DESIGN
Let’s walk through this atomized Instagram interface:
62 ATOMIC DESIGN
Chapter 3
Tools of
the Trade
Pattern Lab and the qualities of
effective style guides
In the previous chapter, I introduced the atomic design
methodology for constructing user interfaces. I hope you’ll find
atomic design to be a helpful mental model for constructing UI
design systems, but now it’s time to climb down from the ivory
tower and actually put atomic design into practice in the real world.
That all sounds wonderful, right? I can almost hear you saying,
“I need this whole pattern library thing in my life.” But how do
we make pattern libraries happen? Well, you’ve come to the right
place, friend, because the rest of this book is dedicated to exactly
that. This chapter will introduce helpful tools for creating pattern
libraries, the next chapter will discuss how to make patterns a
cornerstone of your design and development workflow, and the fifth
chapter will cover how to make your design system stand the test
of time.
Let’s walk through these points, starting with the term static site
generator. Static site generator tools take in some source code
and assets, compile them, and spit out plain ol’ HTML, CSS, and
JavaScript at the other end. Pattern Lab takes source code –
namely patterns – and compiles those patterns into a functional
front-end UI inside a pattern library shell.
So what does Pattern Lab look like out of the box? Drumroll, please.
66 ATOMIC DESIGN
One default Pattern Lab dashboard. What it lacks in good looks, it makes up for in utility.
If that all sounded like gibberish to you, don’t worry. This chapter
focuses on the overarching features of Pattern Lab and principles
of effective pattern libraries rather than going too far down the
technical rabbit hole. If interested, you can check out Pattern Lab’s
documentation to dive into the nitty-gritty.
68 ATOMIC DESIGN
Constructing UIs in this manner keeps things DRY, which is a
long-standing computer science principle that stands for “don’t
repeat yourself.” What this means is that you can make a change
to a pattern, and anywhere that pattern is employed will magically
update with those changes. This Russian nesting doll approach
considerably speeds up your workflow, and certainly beats the pants
off sifting through hundreds of Photoshop documents for every
instance of a pattern in order to make a simple change.
{{> atom-thumbnail }}
This is Mustache code, in case the double curly braces ({{}}) that
look like little mustaches didn’t give it away. The greater-than
symbol (>) is Mustache’s way of telling Pattern Lab to include an
atom pattern called “thumbnail”. Pattern Lab will go searching
through its folders of patterns to find an atom named “thumbnail”.
This is what Pattern Lab’s patterns folder structure can look like. You can
name and categorize these folders however you’d like, including changing
the labels “atoms”, “molecules”, and “organisms”, “templates”, and
”pages”. The most important consideration is to establish naming and
categorization that is most effective for your team.
For Time Inc.’s website, we created a basic block molecule consisting of a thumbnail image,
headline, and excerpt.
70 ATOMIC DESIGN
<div class="block-post">
<a href="{{ url }}">
{{> atoms-thumb }}
<h3>{{ headline }}</h3>
<p>{{ excerpt }}</p>
</a>
</div>
{{> molecules-block-post }}
The website header consists of fairly common conventions like a logo atom, primary navigation
molecule, and a search form molecule.
<header role="banner">
{{> atoms-logo }}
{{> molecules-primary-nav }}
{{> molecules-search }}
</header>
{{> organisms-header }}
I hope by now you can see the Russian nesting dolls in action.
The smallest atoms are included in bigger molecules, and those
molecules get included in even bigger organisms. Now let’s take
these components and plug them into a layout. Take the homepage
template, for instance:
72 ATOMIC DESIGN
The Time Inc. homepage template consists of a few repeatable patterns: a global
header, a hero area, a few sections (containing an image, headline, excerpt, and
call to action), an area featuring four items, a factoid area, and a global footer.
{{> organisms-header }}
<main role="main">
{{# hero }}
{{> molecules-hero }}
{{/ hero }}
<section>
{{# experience-block }}
{{> molecules-block-main }}
{{/ experience-block }}
{{# experience-feature }}
{{> organisms-story-feature }}
{{/ experience-feature }}
</section>
<section>
{{# factoid-advertising }}
{{> organisms-factoid }}
{{/ factoid-advertising }}
</section>
<section>
{{# advertising }}
{{> molecules-block-main }}
{{/ advertising }}
</section>
...
</main>
{{> organisms-footer }}
74 ATOMIC DESIGN
Taking a closer look at the code, notice that certain patterns like
{{> organisms-header }} and {{> organisms-footer }} are
included the same way as the earlier examples. But there are also a
few other includes patterns that are supplemented by some additional
information, like the following:
{{# factoid-advertising }}
{{> organisms-factoid }}
{{/ factoid-advertising }}
76 ATOMIC DESIGN
On the left we have the template level, which articulates the content
structure of the patterns making up the web page. And on the right
we have the page level, where we’re pouring in real representative
content to demonstrate what the final UI might look like and test
the effectiveness of the design system.
"hero" : {
"headline": "Lorem Ipsum",
"img": {
"src": "/images/sample/fpo_hero.png",
"alt": "Hero Image"
}
}
"hero" : {
"headline": "Moving People",
"img": {
"src": "/images/hero_beyonce.jpg",
"alt": "Beyonce"
}
}
78 ATOMIC DESIGN
This process of establishing defaults for dynamic data then
replacing them with page-specific content continues for each
section of the website. In addition to replacing simple strings like
headings, we can also dynamically set variables to true or false,
loop through an array of items, and more. We can even dramatically
alter the UI with just a few changes to a JSON file, which we’ll talk
about next.
"collaborators": [
{
"img": "/images/sample/avatar1.jpg",
"name": "Steve Boomshakalaka",
"title": "CIA"
},
{
"img": "/images/sample/avatar2.jpg",
"name": "Gingersnap Jujubees-Daniels",
"title": "President of the Longest Company
Name in the World Corporation, Global Division"
},
{
"img": "/images/sample/avatar3.jpg",
"name": "Sarunus Marciulionis",
"title": "Golden State Warriors"
},
{
"img": "/images/sample/avatar4.jpg",
80 ATOMIC DESIGN
"name" : "Sara Smith",
"title" : "Short Title"
}
]
By default, our design assumes the user is a regular user and not
an administrator, but what if we wanted to give administrators the
ability to manage project collaborators from the dashboard? That UI
might look something like this:
dashboard~admin.json
"isAdmin" : true
The first few lines are pulling in the img, name, and title we
defined in dashboard.json. But pay close attention to what’s wrapped
in the isAdmin Mustache section. What we’re saying here is: if
isAdmin is set to true, include a molecule pattern called block-
actions. The block-actions pattern contains the edit and delete
buttons, and will only display if isAdmin is set to true (or anything
besides false). In our default dashboard.json, isAdmin isn’t set,
so the extra actions won’t display. In dashboard~admin.json, we’re
setting isAdmin to true so the extra actions will display. You
can extend this technique to dramatically alter the entire UI (like
altering the primary navigation, showing additional panels on the
dashboard, adding extra controls, and so on) just by changing a
single variable. Powerful stuff, indeed.
82 ATOMIC DESIGN
As mentioned earlier, static design tools aren’t well equipped to
handle dynamic data, but it’s also overkill to install WordPress,
Drupal, or some other CMS just to demonstrate UI variations.
Pattern Lab strikes a balance as it allows teams to work
with dynamic data but doesn’t require setting up any crazy
MySQL databases.
ɕ Serves as a blueprint for back-end developers responsible for
integrating the front-end UI into a real content management
system. Back-end developers can look at the UI created in
Pattern Lab, understand which bits are static and dynamic, then
translate that into the back-end system.
ɕ Allows writers, content people, designers, and other non-
developers to contribute to the living, breathing design
system. As a front-end developer, I can’t count the number of
times I’ve had to fix typos, swap in new images, translate copy
decks, and make other content-related edits to front-end code.
It’s death by a million paper cuts, and I’m sure most developers
would agree that making minor copy changes isn’t an effective
use of their time. By separating structure and data, Pattern Lab
enables non-developer team members to safely manage the
content-related aspects of the design, freeing up developers to
focus on building the design system’s structure.
We’ve now covered Pattern Lab’s core functionality, but we’re not
done yet! Next we’ll cover a few additional features that should
be considered, irrespective of the tool you use to create your
pattern library.
The tool is called ish. because selecting the small button results in
a small-ish viewport. Selecting it again provides a different small-
ish viewport. Selecting the medium button gives you a medium-ish
viewport. And the large button results in a – wait for it – large-ish
viewport. These randomized values help designers and developers
better consider the entire resolution spectrum rather than a handful
of popular device dimensions.
Ish. is baked into Pattern Lab, which means we can view our UIs and
their underlying patterns across the entire resolution spectrum.
While ish. helps designers and developers uncover bugs along the
viewport continuum, I’ve found it to be more helpful as a client and
colleague education tool. By building a device-agnostic viewport
resizing tool directly into the pattern library, clients and colleagues
84 ATOMIC DESIGN
can come to appreciate the fact that their design system should look
and function well no matter the viewport size.
86 ATOMIC DESIGN
Salesforce’s Lightning design system showcases the UI components’ HTML and SCSS code.
Lonely Planet’s Rizzo design system pattern library showcases the template usage.
Pattern Lab’s code view demonstrates both a pattern’s template code and the compiled HTML.
88 ATOMIC DESIGN
Living documentation and annotations
In a traditional siloed design process, it’s typical to see lengthy
wireframe and spec documents created, debated, and approved.
These documents usually take the form of gigantic PDFs, which
is unfortunate considering they often contain all sorts of valuable
insights, instructions, and documentation about the design system.
Sadly, these bulky artifacts are often thrown into a (virtual) trash
can by the time the project makes its way into production.
Pattern Lab displays important pattern documentation right alongside the living pattern examples,
which helps teams communicate definitions, usage, examples, outside resources, and more.
Pattern Lab’s annotation feature is interactive and baked into the living UI.
90 ATOMIC DESIGN
Thanks to the Russian nesting doll include approach described
earlier, Pattern Lab can display what patterns make up any given
component, and also show where those patterns are employed in
the design system.
Pattern Lab’s lineage feature displays what patterns make up any component, and also shows all
the places that component is employed.
When choosing tools to create your pattern library, you should keep
your eyes open for these qualities and features of effective pattern
libraries:
At the end of the day, it’s not about the tools we use to create
pattern libraries, but rather how we use them. Creating and
maintaining an effective design system means dramatically
changing your organization’s culture, processes, and workflows. If
that sounds hard to you, it’s because it is. But fear not! The rest of
the book will detail the entire process of creating and maintaining
a successful design system to set your organization up for long-
term success.
92 ATOMIC DESIGN
Chapter 4
The Atomic
Workflow
People, process, and making design
systems happen
Talk is cheap. And up until now, we’ve been doing a whole lotta
talkin’. That’s not to say it hasn’t been productive talk! After all,
we’ve discussed the importance of modular thinking, we’ve learned
a methodology for crafting deliberate UI design systems, and we’ve
showcased tools for creating effective pattern libraries.
But here’s where the rubber meets the road. Where we roll up our
sleeves and put all of this theory into practice. Where we get stuff
done. This chapter will tackle all that goes into selling, creating, and
maintaining effective design systems. You ready? Let’s go.
It’s people!
The not-so-secret secret about creating effective design systems
(or doing any great work, really): it all comes down to people truly
collaborating and communicating with one another.
- Mark Boulton
You can have all the right technologies in place, use the latest and
greatest tools, and even have extraordinarily talented individuals
on board, but if everyone involved isn’t actually cooperating and
communicating with one another then you’re not going to create
great work. It’s as simple as that. That’s not to say you can’t create
good work, but more often than not you’re going to create one of the
many disappointing shades of bad work.
Pitching patterns
Introducing a new way of doing things is no easy task, as it requires
changing people’s existing mentalities and behaviors. Getting
stakeholders and clients on board with establishing a design system
involves constant education, in addition to a bit of marketing savvy.
Alas, I’ve found that I can hype design systems until I’m blue in the
face, but the suits don’t always see things through the same lens as
the people on the ground. A simple reframing of the question helps
96 ATOMIC DESIGN
immensely. It’s much more effective to simply ask, “Do you like
saving time and money? Yes or no?” If the answer to that question
is no, I’m afraid you have way bigger problems than selling a design
system. If the answer is yes, then you can pitch the benefits through
the lens of time and money. Let’s try this out, shall we?
Here’s a collection of all the unique button styles found on the homepage of United.com. An
interface inventory rounds up and categorizes all the unique patterns that make up an interface.
98 ATOMIC DESIGN
Conducting an interface audit
How do you go about conducting an interface audit? How do you
round up all the components that make up your UI? The simple
answer is screenshots. Lots of them! Creating an interface inventory
requires screenshotting and loosely categorizing all the unique
components that make up your user interfaces. While that’s a
relatively straightforward endeavor, there are some important
considerations to keep in mind to make the inventory as useful
as possible. Let’s go through the process for creating a successful
interface inventory.
ɕ PowerPoint or Keynote
ɕ Photoshop or Sketch
ɕ Evernote Web Clipper
ɕ Google Docs or Microsoft Word
Ultimately, it doesn’t really matter what tool you use, but everyone
should agree on a single tool to make it easier to combine at the end
of the exercise. I’ve found online slide-building software like Google
Slides to be very effective as it provides a canvas for free-form image
positioning, they’re chunked out into slides for easier categorization,
and they’re web-based so can be shared with ease.
An example of unique button patterns captured in an interface inventory for a major bank’s website.
Again, these categories aren’t set in stone and will vary based on
the nature of the user interface you’re dealing with. Of course, it’s
important to add, subtract, or modify these categories to best fit
your organizational needs.
Timing is everything
It’s important to set time limits on the screenshotting exercise to
avoid going down a rabbit hole that ends up lasting all day. The
amount of time you allocate will vary depending on how many
people are participating, but I find between 30 and 90 minutes to be
sufficient for a first pass of an interface inventory. Set a timer, throw
on some Jeopardy! music (well, maybe not Jeopardy! music, but some
other music that sets an upbeat mood for the exercise), and have the
participants concentrate on screenshotting the unique UI patterns
they encounter.
Dig deep
Which parts of the site should participants capture in the interface
inventory? Short answer: everything. Any piece of UI that is or could
be managed by your organization should be documented.
Once every category has been presented and discussed, all the
participants should send their slides to the exercise leader. The
leader will then combine everything into one giant über-document,
which will soon become a wrecking ball of truth and justice.
Have you ever wanted to see a CEO cry? Laying bare all your UI’s
inconsistencies is a great way to make that happen! 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.
You don’t need to be a designer to recognize that having 37 unique
button styles probably isn’t a good idea. Here’s your opportunity
to make it crystal clear to stakeholders that approaching your UI in
a more systematic way makes great sense for both your users and
your organization.
It’s very likely the initial exercise didn’t capture every unique
UI pattern, so you may need to conduct another interface audit
exercise to capture a more complete picture of your UI patterns.
This may involve a large group again, but in reality a smaller,
cross-disciplinary team will be going through the über-document
and establishing next steps for the design system.
Once the gaps in the interface inventory have been filled, the
working group can have some important conversations about next
steps for the design system project. Some key questions for this
group to cover include:
ɕ Which patterns should stay, which should go, and which can be
merged together?
ɕ What pattern names should we settle on?
ɕ What are the next steps to translate the interface inventory into
a living pattern library?
Do it anyways.
In fact, to create the whole, you need to create the parts of that
whole. Our interfaces consist of smaller pieces, whether you pay
those smaller pieces any mind or not.
One way to approach a Lego project is to simply dump the pieces out onto a table, and rummage
through the pile to find the pieces you need. Image adapted from "Multiscreen UX Design" by
Wolfram Nagel.
Taking the time to organize the pieces that make up your final creations allows you to approach the
work in a more deliberate and efficient manner. Image adapted from "Multiscreen UX Design" by
Wolfram Nagel.
By taking the time to organize the parts, you can now create
the whole in a more realistic, deliberate, and efficient manner.
Creating a library of your available materials allows you to approach
the project in a more methodical way, and saves immense amounts
of time in the process. Rather than rummaging through a haphazard
Taking the time to organize the pieces that make up your final creations allows you to work in
a more deliberate and efficient manner. Rather than sifting through a haphazard pile of bricks,
an organized inventory of components can produce better, faster work. Image adapted from
"Multiscreen UX Design" by Wolfram Nagel.
(Re)setting expectations
You’ve put in a lot of hard work to sell the concept of a design
system, but you still need to set stakeholder and team expectations
before you roll up your sleeves and get to work.
It’s ludicrous for anyone to utter the phrase, “This is how we’ve
always done things” in an industry that’s only 25 years old.
Unfortunately, we humans are creatures of habit, and stepping
outside familiarity’s warm embrace is uncomfortable. We don’t like
being uncomfortable. We must overcome our existing predispositions
if we’re going to embrace our ever-shifting industry’s best practices
and create successful digital work.
Redefining design
We’ve come a long way from simply transplanting print PDFs to the
World Wide Web, but print design still casts a long shadow and
continues to influence how things get done online.
- Dan Mall
How did we get to the point where we sell and design websites
like they’re static images? During the formative years of the web
we created experiences meant to be consumed solely by desktop
computers, which is understandable since desktops were really the
only game in town. The real estate provided by desktop screens
made the idea of simply translating a PDF onto the web feasible and
enticing. So that’s what we did – and for a while it actually worked!
Once upon a time, the web was primarily consumed on desktop screens, hence this crusty-looking,
old machine.
This is the web: a potpourri of devices, screen sizes, capabilities, form factors, network speeds,
input types, and more.
In addition to all the web-capable devices we concern ourselves with today, we must understand
that the device and web landscape is becoming bigger and more diverse all the time.
It’s our job to create great experiences for people using a diversity
of devices, screen sizes, network speeds, device capabilities,
“This looks fantastic, and I think really hits the mark for what we’re
trying to accomplish with this project. But…”
Weeks pass and seasons change. Nerves wear thin, and the deadline
date looms over everyone’s heads. It’s with a sense of urgency that
homepage_v9_final_for-review_FINAL_bradEdits_for-handoff.psd
finally gets approval by the stakeholders.
The visual designer has already disappeared into the night by the
time the front-end developer picks the design off the floor. With one
glance at the composition, a strange feeling – some combination of
bewilderment, rage, and dread – washes over them. What’s wrong
with the design, exactly? Maybe it’s the seven typefaces and nine
unique button styles peppered throughout the comps. Maybe it’s the
desktop-centric, impossible-to-actually-execute layout. Maybe it’s
the perfect-yet-improbable user-generated content.
So the developer tries their best to make lemonade out of the lemony
static comps. They bend over backwards to create responsive layouts
that still retain the integrity of the static comps, normalize some
of the more blatant component inconsistencies, establish pattern
states (like button hover, active, and disabled states) that weren’t
articulated in the designs, and make some on-the-fly decisions
regarding the interactive aspects of the experience. Discussions with
designers are strained, but everyone realizes that they need to work
through these issues to get the project done.
The waterfall process hinges on the premise that work must flow
in a sequential order: the UX designer’s work must be completed
before visual design can start; the visual designer must finish their
job before front-end development can begin. This simply isn’t true.
There is much work that can and should happen in parallel. To
create sound UI design systems, we must reset our stakeholders’
expectations and get them comfortable with a blurrier, more
collaborative process.
That work will happen in parallel doesn’t imply that everyone will
be guns blazing throughout the entire process. Of course, the bulk
of research, information architecture, and other elemental aspects
of UX design will tend to happen earlier in the process, but that
work shouldn’t delay the other disciplines from starting their jobs.
And even when the bulk of a person’s active work is done, they
should never simply fade away from the project. It’s crucial for
A more collaborative workflow involves a cross-disciplinary team working together throughout the
entire process. While active work will wax and wane, each discipline continues to consult with the
other team members to ensure their insights are present in the final work.
Development is design
When a previous employer discovered I wrote HTML, CSS, and
presentational JavaScript, they moved me to sit with the engineers
and back-end developers. Before too long I was being asked, “Hey,
Brad. How long is that middleware going to take to build?” and
“Can you normalize this database real quick?”
ɕ flexibility
ɕ impact of the network
ɕ interaction
ɕ motion
ɕ ergonomics
ɕ color and text rendering
ɕ pixel density
The sculptor starts with a giant slab of rock and starts chipping
away. A crude shape begins to form after the first pass, and the
shape becomes more pronounced with every subsequent pass. After
a few rounds of whacking away at the rock, it becomes clear that the
sculptor’s subject is a human form.
With the general shape of the sculpture roughed out, the artist then
begins homing in on specific sections of the piece. For instance,
they may begin with the face, moving up close to carve the shape
of the eyes, nose, and mouth. After several passes, they then
move on to the arms, and then begin detailing the legs. At regular
intervals the artist steps back to see how their detailed work affects
the overall sculpture. This process continues until the sculpture is
complete and everyone is pleased with the results.
If this all sounds a bit messy, that’s because it is! To the dismay
of some project managers, the design process doesn’t fit neatly
into the rigid borders of Excel spreadsheets and Gantt charts. True
collaboration between disciplines is fuzzy and chaotic, and that’s
not a bad thing. Constant communication, tight feedback loops,
and true collaboration therefore become the glue that holds
Establishing direction
Teams are often eager to jump right into fun high-fidelity design
and development work, and clients are eager to see and react to that
detailed work. However, this leads to distractions, assumptions, and
all the aforementioned misguided expectations. It’s essential to
agree on an overall design direction and paint the broad strokes
first before moving into high-fidelity design and development. This
requires restraint and expectation management, but results in more
focused decision-making and more realistic work.
What does this lo-fi work look like? Let’s take a look at some
techniques UX designers, visual designers, and front-end
developers can use to begin crafting a strong overall direction
for a UI design system.
Basic HTML wireframes for the Greater Pittsburgh Community Food Bank homepage.
No one in their right mind would mistake this blocked out grayscale
page as complete, but it provides more than enough information
to have important conversations about the page structure and
hierarchy.
For the TechCrunch website redesign, Jennifer Brook defined site-wide, gestural display patterns,
which don’t make assumptions about aesthetics or functionality.
From the image above, you can gather that the “featured island”
component will show content in some fashion. Note the gestural
nature of this sketch and how it doesn’t make any specific
assumptions about layout or functionality. The details of how this
pattern will look and function will come later, but at the beginning
of the project it’s useful simply to define it and articulate where it
might get used.
For each site presented, each person votes on a scale from 1 to 10,
where a score of 1 means “If this were our site I would quit my job
and cry myself to sleep,” while a score of 10 means “If this were our
site I would be absolutely ecstatic!” Instruct participants to consider
visual properties they find interesting, such as typography, color,
density, layout, illustration style, and general vibe.
For the Pittsburgh Food Bank website redesign kick-off, we showed stakeholders a variety of
relevant websites for twenty seconds each. The participants voted on how happy they would be if
the particular site was theirs. Then we discussed the results.
Style tiles
Once again, visual designers’ first instinct is often to jump right
into creating full comps to articulate an aesthetic direction for
the project. This high-fidelity work is certainly tangible, but also
wastes a ton of time and effort if the comps don’t resonate with the
stakeholders. Also, creating high-fidelity comps often makes big
assumptions about technical feasibility, which leads to unrealistic
expectations and antagonistic relationships with frontend
developers.
Element collages
While style tiles are great for exploring design atmosphere, they’re
still a bit abstract. To get a sense of how those design ingredients
will be applied to an interface, it’s important to quickly move into
something a bit more tangible than a style tile. But does that mean
visual designers need to jump from style tiles straight into full
comps? Not necessarily.
A prep chef chops vegetables, marinades meat, makes salads, and prepares other ingredients so
that the main kitchen staff can focus on cooking meals and collaboration.
Are you making an e-commerce site? You can set up site search,
a shopping cart table, a placeholder product detail page, the
homepage, and checkout pages. Making an online service? Start
marking up the sign-up and login forms, the forgot password flow,
and dashboard. And, of course, most websites will have a header,
footer, and main content area. Set up shell templates and write basic
markup for patterns you anticipate using. This markup will initially
be crude, but it provides a crucial starting point for collaboration and
iteration.
Dan Mall created an element collage to explore an aesthetic direction for the global header.
Though the client didn’t know it, I had been building out a working
HTML version of the header behind the scenes in Pattern Lab.
Using Dan’s exploration as a reference, I created an HTML version of the global header in Pattern
Lab. This grayscale prototype helped us demonstrate interactivity and how the header would adapt
across the resolution spectrum.
With input from the stakeholders and team, we iterated over the
header pattern to massage the layout, IA, aesthetic details, and
functionality to arrive at the solution we ultimately launched with.
The header we launched with was the culmination of plenty of conversations and decisions around
the pattern’s content, design, and functionality.
{{> organisms-header }}
This allowed us to view the header within the context of the rest of
the pages, sketchy as they initially were. So while we were focusing
on designing one specific pattern, we were simultaneously taking
into account the context of where that pattern would be employed.
But I’ll never forget this client feedback we received on the first
pattern-driven project I worked on: “These element collages look
great, but it’s like you’re asking me to comment on how beautiful a
face is by showing me the nose.”
In-browser iteration
Static comps can be great for shaping the overall aesthetic direction
of a template, but users will ultimately view and interact with the
experience in a browser. That’s why designs should be quickly
translated into the final environment and iterated on there.
- Dan Mall
This illustration by Trent Walton of Paravel perfectly articulates a more iterative design and
development process. By getting designs into the browser sooner, teams can iterate over the design
and address the many considerations that can only be dealt with once the design is in the browser.
Maintaining
Design Systems
Making design systems stand the test
of time
And they made a design system, delivered a style guide, and lived
happily ever after. Right?
Not quite.
There’s a very real risk that a style guide will end up in the trash
can right alongside all the PSDs, PDFs and those other static
artifacts of the design process. Despite everyone’s best intentions,
all the time and effort that went into making a thoughtful design
system and style guide can go straight down the drain.
- Nathan Curtis
The problem with this mindset is that you can almost see that
pattern library snapping off and sliding into the abyss. Once the
pattern library ceases to reflect the current state of the products
This “design system first” mentality inserts a bit of friction into the
maintenance process, and that friction can be friendly. It forces us
to step back and consider how any improvements, client requests,
feature additions, and iterations affect the overall system rather
than only a sliver of the whole ecosystem.
- Nathan Curtis
ɕ Make it official.
ɕ Make it adaptable.
ɕ Make it maintainable.
ɕ Make it cross-disciplinary.
ɕ Make it approachable.
ɕ Make it visible.
ɕ Make it bigger.
ɕ Make it context-agnostic.
ɕ Make it contextual.
ɕ Make it last.
Let’s dive into each one of these points in a bit more detail.
Organic beginnings are all well and good, but in order to establish
a truly impactful design system that creates long-term success
for your organization, the design system needs to evolve into
an officially sanctioned endeavor. That means thinking of it as a
true product rather than a simple side project, and consequently
allocating real time, budget, and people to it.
1. Make a thing.
2. Show that it’s useful.
3. Make it official.
1: Make a thing
You have to start somewhere, and having something started is
better than nothing at all. Pick a project that would be a great
pilot for establishing your design system; follow a process similar
to the one discussed in chapter 4; think about the atomic design
mental model detailed in chapter 2; and you’ll end up with a solid
foundation for a thoughtful design system and pattern library that
helps your team work more effectively.
3: Make it official
You’ve proved the value of your initial design system and presented
a roadmap for how to make it even better. With any luck your
organization will commit to making the design system an Official
Thing.
With approval from the highest levels, you’re now able to put a
plan into action that involves: allocating or hiring people to work
on the design system; developing a plan to make it more robust;
establishing a clear governance strategy; and laying out a product
roadmap.
It’s worth pointing out that things may not shake out the way you
hoped. Despite demonstrating real value and presenting a concrete
plan of action, higher-ups still might shoot your initiative down.
Don’t be discouraged. You may have lost the battle, but you can
certainly win the war. Your team should continue to grow and
extend the design system in whatever capacity you can until its
value becomes undeniable. As more people benefit from the system,
you’ll end up with a grassroots-supported system that can help
push the endeavor through.
The design system makers are the ones who create, maintain,
and govern the system, and they need to work closely together to
ensure that the system is smart, flexible, scalable, and addresses
the needs of the users and business. The design system users are
the teams across the organization who will take the system and
employ its interface patterns to specific applications.
The answers to these questions will very much depend on the size
and setup of your organization.
But on the other hand, external parties can often provide a sense
of perspective that’s hard to see while working inside a company.
This is where outsiders can really shine. In my work as a consultant,
I work with organizations to establish long-term design system
maintenance strategies, and help get the right people and processes
in place. While the long-term success of the system will ultimately
be up to the organization, third parties can teach them to fish and
provide important strategic guidance, feedback, and perspective.
Design system users may be the same team creating the design
system, separate development teams within your organization,
junior-level designers and developers, partner agencies, external
development shops, or other third-party teams.
Other people may not be the ones actively doing the work, but
must be consulted to make sure their perspectives are properly
reflected in the system. Back-end engineers need to make the team
aware of any architectural decisions that would affect the front-end
UI; executives need to make the team aware of important initiatives
that will affect the role and utility of the system; and, of course,
design system users need to coordinate with the makers to ensure
the system serves the needs of individual applications.
Make it adaptable
Change is the only constant, as they say. The living part of a living
design system means that it needs to roll with the punches, adapt to
feedback, be iterated on, and evolve alongside the products it serves.
There are likely many more specific questions to answer, but the
point is your team should have answers and processes in place to
address inevitable changes to the system.
The result is a gorgeous decision tree that maps out exactly what
processes need to happen to add a new pattern to the design system.
The Canonical web team mapped out the decision process used to manage updates and additions to
patterns in the Vanilla front-end framework.
Modifying patterns
UI patterns can and should be modified for a number of reasons:
feature additions, bug fixes, subtle or major visual design tweaks,
performance improvements, accessibility enhancements, code
refactoring, UX best practice updates, and so on.
Adding patterns
As smart as your team surely is, it’s quite possible you won’t think
of every conceivable pattern to include in your design system right
out of the gate. As the system is applied to more products, gaps will
inevitably emerge where the needs of the application aren’t solved
by existing patterns. In such cases, it will become clear that new
patterns will need created to address these needs.
Removing patterns
Patterns can be deprecated for a number of reasons. Perhaps you
discover through use that a particular pattern is a terrible idea.
Hindsight is 20/20, my friend. Maybe the industry has moved away
from a pattern for UX or technical reasons. Perhaps a pattern sat
there unused by any application for ages. Maybe users reported
back with a lot of negative feedback about working with a particular
pattern.
Make it maintainable
With all this talk about modifying, adding, and removing patterns,
you may be wondering, “How the hell are our applications supposed
to actually keep up with all these changes?!” And in asking that
question, you will have stumbled on to one of the biggest challenges
organizations face in successfully maintaining a design system.
- Marcelo Somers
Sharing CSS and JavaScript is all well and good, but where things
get tricky is when you want to share markup between environments.
Why? you ask. Well, markup and back-end logic are often
intertwined in an application’s codebase, which tends to make it
difficult to simply copy and paste markup between your pattern
library and production environments. Thankfully, there are ways
around this problem.
A templating language like Mustache, Handlebars, Underscore, Jade, and others can serve as a bridge
that allows front-end code to be shared between the pattern library and production application.
The Draft U.S. Web Design Standards are the design system for the United States federal government.
The U.S. government’s design system – called the Draft U.S. Web
Digital Standards – is a collection of UI components and visual
styles created to help people making government websites build
more consistent UIs. The design system provides markup and styles
for users to download and weave into their applications. It would
certainly be amazing to see a holy grail design system implemented
at such a gigantic scale, but as you might imagine, that’s a pretty
tall order. The vastness and decentralized nature of the organization
Make it cross-disciplinary
Style guides often jump straight into code snippets and pattern
usage for the benefit of the design system users. Of course, a
pattern library needs to be helpful for the people actually making
use of the patterns, but treating a style guide solely as a developer
resource limits its potential.
A well-crafted style guide can help manage all these moving parts
and ensure the many perspectives that influence each pattern are
properly documented in the style guide. Make the pattern library
accessible to every discipline, and think about how to make it
easy and inviting for different disciplines to contribute to the
documentation.
Make it approachable
It should come as a surprise to no one that people tend to gravitate
towards attractive things. A big part of making a style guide a cross-
disciplinary resource is ensuring the container that houses your
pattern library and other documentation is good-looking, inviting,
and easy to navigate.
Taking the time to craft an attractive home for your style guide and
documentation can lead to more usage, help build awareness, help
create organizational investment, and help get non-developers’
eyeballs on the style guide. All of this contributes to that important
shared vocabulary that leads to better cross-disciplinary
collaboration.
a style guide off the ground. If teams think that making a useful
style guide involves making some Big, Official Thing with custom
branding and a glossy website, they might be deterred from ever
starting the initiative. So remember:
1. Make a thing.
2. Show that it’s useful.
3. Make it official.
Make it visible
Visibility is critically important to the ongoing health of your
design system. Such an important endeavor shouldn’t be tucked
Communicating change
Once the design system is off the ground and is being used in real
applications, it’s imperative to communicate changes, updates, and
an ongoing vision to the entire organization.
The material design team publishes a handy changelog within its style guide so users can easily
learn about the latest updates and improvements to the system.
Training users how to work with the design system can take many
forms, including:
ɕ Issue trackers: Tools like JIRA and GitHub Issues are great
for users and makers to report bugs and have technical
conversations. Users should be aware of the protocol for filing
bugs and feel empowered to contribute.
ɕ Office hours: Schedule regular times when the design system
team is available to field questions, address issues, and talk
about what’s next for the design system.
ɕ Slack and chat tools: The real-time nature of many of our
work collaboration tools presents a huge opportunity to keep
the pattern-laden conversation going. Thanks to tools like
Slack, Yammer, and HipChat, makers and users can engage one
another whenever and wherever.
ɕ Forums: Communities like Stack Overflow and GitHub have
proved to be extremely effective at enabling grassroots,
community-driven support. Rather than design system makers
becoming a support bottleneck, it can be worthwhile to open up
support to the entire user community.
ɕ Outreach: Not everyone has the time or the personality to ask
questions and suggest changes. Design system makers should be
proactive and reach out to developers using the design system
to see if they have any issues or concerns. These kinds of actions
can help build a genuine and positive relationship between
makers and users.
Make it public
Communicating change, evangelizing, and setting up proper
training and support are all great things to increase your system’s
visibility. But there’s another big opportunity to take your
communication strategy to another level: making your style guide
publicly accessible.
Publishing your style guide for the world to see increases its
visibility, increases accountability, and serves as an amazing
recruitment tool.
- Jina Bolton
Make it bigger
A visible, cross-disciplinary, approachable pattern library is one
that your team will come back to again and again. Use that to your
advantage. Since the team’s eyeballs are already fixated on that
one resource, there’s a big opportunity to extend it to include other
helpful documentation like the voice and tone, brand, code, design
principles and writing guidelines we discussed in chapter 1.
Intuit’s Harmony design system includes a pattern library, design principles, voice and tone,
marketing guidelines, and more. Housing this helpful documentation under one roof helps increase
its visibility and effectiveness.
Intuit’s Harmony pattern library includes buttons to switch between web, iOS, and Android for each
pattern. This allows the team to maintain a mostly consistent design system across platforms but
also document pattern divergences when they occur.
Make it context-agnostic
The way your UI patterns are named will undoubtedly shape how
they are used. The more agnostic pattern names are, the more
versatile and reusable they become.
A good exercise when naming patterns is to blur out the content so your names reflect the patterns’
structures rather than the content living inside them.
Make it contextual
Showcasing UI patterns in a pattern library is all well and good,
but you need to demonstrate context for design system users to
understand how and where to properly use them. Most pattern
Material design’s component library doesn’t just contain an example of each component; it
thoroughly documents the component’s usage with plenty of images and videos to support it.
Make it last
Making a design system is an incredibly and important endeavor.
But without proper maintenance, the value of your design system
will depreciate much like a car that’s just been driven off the
dealer’s lot. Instead, your design system should be like a bottle of
fine wine that increases in value over time.
All that effort not only creates a better present for your
organization, but sets you up for long-term success. Establishing a
clear governance plan, communicating change, and implementing
the other advice found in this chapter helps the design system take
root and become an integral part of your organization’s workflow.
Creating the damn thing in the first place is the hard part, but once
established, you have a solid foundation with which to build on
for years to come. Even if you were to burn everything down and
rebuild a new system from the ground up, you’ll find your UIs will
still need buttons, form fields, tabs, and other existing components.
And you’ll need a happy home to display and document the system.
Don’t throw the baby out with the bathwater!
I’d like to give a massive thank you to Dave Olsen, who took my
nascent, poorly programmed Pattern Lab concept and transformed
it into a legit and amazing piece of software. Thanks to the tireless
work of Dave and Brian Muenzenmeyer, Pattern Lab is helping
teams all over the world create atomic design systems. I’m forever
grateful for all of your superb work, and consider myself fortunate
to call you friends.
To Josh Clark and Dan Mall for helping solidify atomic design as a
methodology and for writing the foreword to this book. You trusted
me enough to run with this approach and somehow convinced our
clients it wasn’t totally insane. Without your input and the crazy-
smart brains of early collaborators like Jennifer Brook, Jonathan
Stark, Robert Gorrell, Kelly Shaver, and Melissa Frost, this book
wouldn’t have existed.
To Andy Clarke, who was talking about design systems and atoms
before it was the hip thing to do. Thank you for all your writing and
thinking, but you’re still not getting my dog.
This book would not have been possible if it weren’t for the
amazing work done by some amazing people in the web community.
I’m so incredibly fortunate to work in such an open, sharing, and
collaborative community; every day I look forward to learning new
things from you all.
And last, but certainly not least, thanks so much to my family for all
your love and amazing support over the years.
Chapter 1
• Scope Components, Not Pages
http://bradfrost.com/blog/post/scope-components-not-pages/
• W3C Principles of Design - Modular Design
http://www.w3.org/DesignIssues/Principles.html#Modular
• YUI Library
http://yuilibrary.com/
• jQuery U
http://jqueryui.com/
• Future Friendly Manifesto
http://futurefriendlyweb.com/
• Riding the Magic Escalator of Acquired Knowledge
http://www.uie.com/articles/magic_escalator/
• Agile Manifesto
http://www.agilemanifesto.org/
• Scrum software development
http://en.wikipedia.org/wiki/Scrum_%28software_
development%29
• Lean software development
http://en.wikipedia.org/wiki/Lean_software_development
• Principles behind the Agile Manifesto
http://www.agilemanifesto.org/principles.html
• DIY Process
http://cognition.happycog.com/article/diy-process
• For a Future Friendly Web
http://bradfrost.com/blog/web/for-a-future-friendly-web/
• Adapting Ourselves to Adaptive Content
http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-
adaptive-content-video-slides-and-transcript-oh-my/
• COPE: Create Once, Publish Everywhere
http://www.programmableweb.com/news/cope-create-once-
publish-everywhere/2009/10/13
RESOURCES 185
• Style Guides
http://bradfrost.com/blog/post/style-guides/
• Material Design
http://www.google.com/design/spec/material-design/
introduction.html
• Voice and Tone: Creating content for humans
http://www.slideshare.net/katekiefer/kkl-c-sforum
• Voice & Tone
http://voiceandtone.com/
• Writing for the Web
http://www.dal.ca/webteam/web_style_guide/writing_for_the_
web.html
• Front End Style Guides
http://maban.co.uk/projects/front-end-style-guides/
• Style Guides Podcast with Federico Holgado
http://styleguides.io/podcast/federico-holgado/
• Dennis Crowley: “The Hard Part Is Building The Machine That
Builds The Product”
http://techcrunch.com/2011/03/03/founder-stories-foursquare-
crowley-machine/
• Style Guide Examples on Styleguides.io
http://styleguides.io/examples.html
Chapter 2
• Systemic Design
http://us5.campaign-archive1.
com/?u=7e093c5cf4&id=ead8a72012&e=ecb25a3f93
• Josh Duck’s Periodic Table of HTML Elements
http://smm.zoomquiet.io/data/20110511083224/index.html
• HTML element reference
https://developer.mozilla.org/en-US/docs/Web/HTML/Element
• Single responsibility principle
https://en.wikipedia.org/wiki/Single_responsibility_principle
• Structure First. Content Always.
http://www.markboulton.co.uk/journal/structure-first-content-
always
Chapter 3
• Pattern Lab
http://patternlab.io
• Dave Olsen
http://dmolsen.com
• Brian Muenzenmeyer
http://www.brianmuenzenmeyer.com/
• Pattern Lab’s documentation
http://patternlab.io/docs/
• Don’t repeat yourself
https://en.wikipedia.org/wiki/Don’t_repeat_yourself
• Mustache
https://mustache.github.io/
• Pattern Lab’s pseudo-patterns
http://patternlab.io/docs/pattern-pseudo-patterns.html
• Responsive Web Design
http://alistapart.com/article/responsive-web-design
• Container Queries: Once More Unto the Breach
http://alistapart.com/article/container-queries-once-more-
unto-the-breach
• Ish
http://bradfrost.com/demo/ish/
• Website style guide resources examples
http://styleguides.io/examples.html
• Rizzo style guide
http://rizzo.lonelyplanet.com/
• Website style guide resources tools
http://styleguides.io/tools.html
RESOURCES 187
Chapter 4
• Content inventory
https://en.wikipedia.org/wiki/Content_inventory
• Google Slides interface inventory template
https://docs.google.com/presentation/d/1GqFmiDV_
NqKi36fXAwD3WTJL5-JV-gHL7XVD2fVeL0M/edit?usp=sharing
• The Media Object Saves Hundreds of Lines of Code
http://www.stubbornella.org/content/2010/06/25/the-media-
object-saves-hundreds-of-lines-of-code/
• Surfacing Invisible Elements
http://bradfrost.com/blog/post/surfacing-invisible-elements/
• CSS Stats
http://cssstats.com/
• Stylify Me
http://stylifyme.com/
• Multiscreen UX Design
http://store.elsevier.com/Multiscreen-UX-Design/Wolfram-
Nagel/isbn-9780128027295/
• The Post-PSD Era
http://danielmall.com/articles/the-post-psd-era/
• Consensual hallucination
https://adactio.com/journal/4443
• Waterfall model
https://en.wikipedia.org/wiki/Waterfall_model
• Development Is Design
http://bradfrost.com/blog/post/development-is-design
• Time to stop showing clients static design visuals
https://stuffandnonsense.co.uk/blog/about/time_to_stop_
showing_clients_static_design_visuals
• Mobile First
http://www.lukew.com/ff/entry.asp?933
• Content & Display Patterns
http://danielmall.com/articles/content-display-patterns/
• Jennifer Brook
http://jenniferbrook.co/about
Chapter 5
• Nathan Curtis on Twitter
https://twitter.com/nathanacurtis/status/656829204235972608
• A Design System isn’t a Project. It’s a Product, Serving Products.
https://medium.com/eightshapes-llc/a-design-system-
isn-t-a-project-it-s-a-product-serving-products-
74dcfffef935#.4umtnfxsx
• The Salesforce Team Model for Scaling a Design System
https://medium.com/salesforce-ux/the-salesforce-team-model-
for-scaling-a-design-system-d89c2a2d404b
• Vanilla framework
http://ubuntudesign.github.io/vanilla-framework/
• Getting Vanilla ready for v1: the roadmap
http://design.canonical.com/2016/07/getting-vanilla-ready-for-
v1-the-roadmap/
• Sass Deprecate
https://github.com/salesforce-ux/sass-deprecate
• The Way We Build
http://airbnb.design/the-way-we-build/
RESOURCES 189
• Rizzo style guide
http://rizzo.lonelyplanet.com/
• Chasing the Holy Grail
https://medium.com/@marcelosomers/chasing-the-holy-grail-
bbc0b7cce365#.ay1xeej7d
• Drupal
https://www.drupal.org
• Twig
http://twig.sensiolabs.org
• Introducing Pattern Lab Starter 8
https://www.phase2technology.com/blog/introducing-pattern-
lab-starter-8/
• Draft U.S. Web Digital Standards
https://standards.usa.gov/
• Managing Style Guides at Shyp
https://medium.com/shyp-design/managing-style-guides-at-
shyp-c217116c8126
• Style Guides with Jina Bolton
http://styleguides.io/podcast/jina-bolton
• Website style guide resources podcasts
http://styleguides.io/podcast
Atomic Design details all that goes into creating and maintaining
robust design systems, allowing you to roll out higher quality,
more consistent UIs faster than ever before. This book
introduces a methodology for thinking of our UIs as thoughtful
hierarchies, discusses the qualities of effective pattern libraries,
and showcases techniques to transform your team’s design and
development workflow.