I first heard Brad Frost give a talk on Atomic Design back in 2014 at An Event Apart: Chicago. I didn’t understand everything he was saying, but it looked like a glimpse into the future of development. Up until that time, I had never heard of Atomic Design, modular design, or pattern libraries. When it came time for me to build a site, I just sat down and built it. Top to bottom. You know the drill; header, navigation, main content, side content, footer. Copy. Paste. Repeat. Changes sucked, but whatever.
What he was explaining though — making the most basic components of the site (atoms) and assembling them into larger (molecules) and larger (organisms) pieces — seemed simple enough, and sounded like a much better way to work. I was excited to give it a go, but by the time I was home from An Event Apart, my mind had blanked (as it does) on all but the highest level points of Atomic Design. After setting up Pattern Lab and looking at the provided code, I was lost.
Was all of this coding necessary for the smaller websites I typically build? When does a molecule become an organism? How was I supposed to keep Pattern Lab in sync’ with my live code? If I’m still re-writing all of this for the next site, how is this saving time?
I remember sitting at home at my desk, in the dark, kicking myself for chatting with Brad about Bob’s Burgers at the AEA After Party. There I was dribbled on like a star struck fan boy instead of asking him questions about, oh, I don’t know, this incredible method of working he was there to talk to us about!
I may have let out a Belcher-esque heavy sigh and, “Oh my God.”
At any rate, if this mirrors (in any way) your first experiences with Atomic Design and Pattern Lab, take heart. Brad Frost has now written a book that will give beginners the confidence to build their first pattern library, and give more experienced developers insights about how to sell what they know to clients or bosses.
Atomic Design neatly organizes everything you’ve heard him explain at conferences, heard on Podcasts, or read on his website about Atomic Design into one easy-to-understand resource. The rest of this article will look at my personal “Ah ha!” moments.
One final thing before that though, check out the size of this book. Brad knows his audience.
Ah Ha! #1: The efficiency lyes with building the starter kit.
Almost all of the early pattern library examples I saw were specific to a given company. Since I build sites for lots of different companies, I wondered how it was more efficient to build essentially the same pattern library over and over for each client. What I failed to see, and what Brad has been saying all along (and reiterated in his book), is that the client specific pattern library is the product of a very basic “starter” pattern library. Ah ha!
The “starter kit,” if you will, allows you to more quickly develop projects and not reinvent the wheel each time you build a new site. It contains only the elements you always need and nothing more (e.g., general CSS for core HTML elements and your grid). Then, for each client, you build on a copy of your standard pattern library and make THAT specific to your clients needs. Brilliant.
Ah Ha! #2: Few have achieved the “Holy Grail”.
The biggest hang up I had with pattern libraries and Pattern Lab, by a country mile, was that nowhere was there any mention of how to seamlessly move code out of development and into production. The only way I could envision doing it was to copy and paste it, and then manually keep the library in sync with the site. I’m not the sharpest tool in the shed when it comes to this sort of stuff though. I figured there had to be a way to Grunt or Git, or Gulp or Fart that task.
Well, according to Atomic Design there is no Holy Grail method to move code from production to live site and keep everything in sync. Ah ha!
The reality is much more nuanced and manual than that. Brad spends an entire chapter (Chapter 5, in fact) on the subject of organizing your team, choosing a method to move code around, and how best to maintain your pattern library and live code. In the end, its up to us to determine the best way to proceed based on our unique variables. Which brings me neatly to my next, “Ah ha!”
Ah Ha! #3: There is no “right way” to design atomically.
I don’t know about you, but I tend to get wrapped up in the “right” way something should be done. Primarily because my hand-to-mouth web development education has taught me that there are consequences for doing things the wrong way. At first, Atomic Design can feel like it is very rigid and prescriptive. the more you work with it though, the more you see it as a set of guidelines within which you work. Ah ha!
I had to hear and read this at least a half dozen times before it really sank in. You decide how best to utilize Pattern Lab. You decide the scope of your pattern library. You decide what your patterns are.
Once I realized this, I was so excited I immediately got to work on my own starter kit pattern library. Since then, I’ve finished enough of it to begin using it on a client’s site. It’s still evolving, but even in this basic state it’s already making my life easier. As I move forward with it, my plan is to make it dovetail with WordPress even better and get it on Github.
Ah Ha! #4: Build only what you need…
Many of the pattern libraries I looked at early on were done by large teams inside big companies. This lead me to believe that pattern libraries were, by nature, vast complex systems constructed by brainiacs who could foresee all of the hundreds of components they would need right from the get go.
Atomic Design demystified this by (re)introducing me to the concept of a content audit. A content audit is a quick way to discover everything you need to put in your pattern library and nothing else. If you need something new later… add it then. The massive pattern libraries I was looking at had in truth started small and grew as needed. Ah— you get the idea…
In the book, Brad explains how critical content audits are to a successful pattern library and how to conduct them with your team on projects. They not only show you design inconsistencies, but also ensure that you only design exactly what you need for your site.
Ah Ha! #5: …and build modularly.
Atomic Design’s core concept is that you build large things out of small things. That’s not hard to understand, but what can be tricky is building all of the components of your site in isolation. As someone who has traditionally built “web pages” it was difficult to see the value in building the logo block, navigation, and tagline separately and then assembling them into the page header later. After all, if you don’t build everything together, how will you know if it will look right.
Once I forced myself to build the parts of a site individually I learned that not only would they still all work together, but I could change and re-arrange them much easier.
With your site broken down into small pieces you are also free to build new pages out of existing parts rather than developing an entirely new template. Also, it’s easy to rearrange the smaller bits of a larger piece (i.e., the placement of the logo and navigation in a header) without having to completely rip apart a layout. Again, Atomic Design saves time and speeds up your development process.
Ah Ha! #6: Pattern libraries bring tremendous value.
“Style guides demonstrate to clients, stakeholders and other disciplines that there’s a lot of really thoughtful work going into a websites design and development beyond just ‘Hey, let’s make a new website.’”
I love this quote by Brad, because it speaks so perfectly to the daily struggle of getting your boss(es) to buy into not just building websites, but building them properly.
I’m fortunate to work for a company that not only understands the value of things like pattern libraries, but encourages me to implement them and educate our clients about why they need one. If you’re not as lucky as me, Atomic Design gives you the tools to explain why pattern libraries are so important and why your company needs to start using them.
From better brand consistency to making it easier for you or your clients to update their site in the future pattern libraries just make sense. However, Brad cautions that you have to be careful to plan ahead. Do the people you are handing it off to understand pattern libraries? Do they know how to maintain Them? Do they understand their value? All questions to find answers to before starting the job, and all potential opportunities for you to lighten the clients load by taking on these responsibilities yourself.
Oh my God Josh, wrap it up!
If you have been curious about getting started with pattern libraries, Atomic Design, and/or Pattern Lab then definitely get Atomic Design. Brad is masterful at making, what can at times be a difficult to understand subject, easy to grasp. That being said, Atomic Design is a complex subject, so don’t feel like you’re not an idiot for not getting it right out of the gate. Eventually, it makes sense, and with the help of this book, you will see not only how revolutionary Atomic Design is, but also how to use it proficiently, and sell it to your boss or client.
I was hoping this book would be a deep dive into the underlying principles and mechanics of atomic design—the sort of thing Brad can’t do in a talk, or even an all day worship. Happily, Atomic Design delivers on that front. Having read it, I feel I have an even greater understanding of Atomic Design and I’m excited to not only continue the evolution of my starter kit pattern library, but to also build more pattern libraries in the future.