Building Responsive Interfaces From Atomic Elements

Jared Spool: Hello, everyone welcome to another episode of the “The SpoolCast”. You know there are some guest that I could talk to forever, but I promise you we’re going to keep this not that long, but it’ll be just as fun.

We’re going to talk today to Mr. Brad Frost.

Ladies and Gentlemen, Mr. Brad Frost. Brad, how are you?

Brad Frost: I am fantastic. How are you doing?

Jared: I am doing wonderfully, and really excited to be able to talk to you today.

Brad: Excellent, as am I.

Jared: Let’s talk about this atomic design thing. This is not designing the Big Bang of the universe.

Brad: [laughs] Yes. First step, dig out a Large Hadron Collider, in your back yard.

Jared: Yeah, so the joke I heard the other day was that scientists have a tradition. Every 16 million years, they get together and build a Large Hadron Collider.

Brad: That’s awesome.

[laughter]

Brad: That’s great.

Jared: Yeah. The other quote I heard recently was a Carl Sagan quote that said,“That if you really want to make an apple pie from scratch, you have to start with a Big Bang.”

Brad: Yeah. You first have to invent the universe. That’s right.

Jared: [laughs] This is not what we’re talking about here. You’re not talking about inventing the universe, right? The web already exists.

Brad: Right. Yeah.

Jared: We’re just picking up where other people left off.

Brad: Sure. The story, how it landed on the phrase atomic design, is that it started to look at a lot of breaking down in interfaces in a more systematic way. Instead of this loose spray of modules, includes, and stuff. We love that word modules. This is very amorphous concept and blob of stuff.

I was a little frustrated with that, and so I kept looking to other areas for inspiration. I kept coming back to my high school chemistry class. How we had to do a bunch of chemical equations, balancing chemical equations.

Learning all about atomic elements, and how those things combine to form molecules. They keep combining to form, basically, all matter in the known universe is all comprised of these finite set of atomic elements.

I kept coming back to that as I was thinking about our interfaces. That’s what sort of led to what I’m now calling Atomic Design.

Basically, applying that same process that happens in the natural world, right, atoms become molecules which keep combining to form more complex molecules, eventually sort of simple organisms are created. Then those organisms sort of keep combining until we end up with the richness of the universe.

Applying that to our interfaces, where we as people creating for the web are sort of starting with that same set of finite building blocks, those Lego blocks, our atomic elements are HTML tags. Things like headings and table cells and form inputs and labels and things like that. These sort of basic tags that can’t be broken down any further without losing their meaning.

Then those tags, those basic tags in conjunction with things like color swatches and font stacks and sort of animation defaults, all these very elemental aspects of our interfaces, start combining together in becoming more useful.

That’s basically what Atomic Design is, is sort of starting with these atoms and then sort of thinking about things as this sort of blown apart concept. What are our Lego bricks? What are our raw materials for building an interface? Using that as a starting point, then combining them together.

There’s five distinct steps in Atomic Design. There’s sort of the atoms, which I just described. Then there’s molecules, which are, what I call molecules, which are essentially just relatively simple components, relatively simple clusters of interface.

A quick example of this is like a search form. You have a label for the search form that says, “Search this site,” or something. You have an input, which is where you type. Then you have a button that actually submits the form to trigger the search.

That’s three things, all sort of wrapped in a form tag, and that sort of serves as this relatively simple standalone piece of interface.

Then you could take that relatively simple piece and plug that into context. Say, very often a site search is in the header of a website. Now you could basically plug that relatively simple component into a more complex component, this header, this global header, what I call organism.

An organism is a more complex piece of interface. That header organism might be comprised of a logo atom, a primary navigation molecule, a search form molecule. It’s a sort of relatively complex standalone chunk of interface that sort of becomes its own sort of autonomous piece of the puzzle.

Jared: Yeah, like a login box or something like that.

Brad: Yeah, so that login box might be a relatively simple component, so I call that maybe a molecule that lives inside the sort of broader, bigger component.

Jared: I see, OK, of the header. If we had a place where, in your banner, you might have a user name and password field that has a login button. The three of those are the molecule, and then the organism is the bigger banner.

Brad: Yeah, yeah. Precisely. It’s not hard and fast and I’ve had quite a few conversations with people, and they’re like, “Oh, sometimes, it’s a little bit of a fuzzy line. Should this be a molecule? Should this be an organism?” Really, my basic advice is, don’t rack your brain too hard about it, it’s more about just sort of chucking things out and sort of including smaller things inside of bigger things and stuff.

Sometimes it gets a little gray, so like with a login form, it’s like, yeah, there’s a couple more pieces to the puzzle in there, but it’s still a relatively simple sort of thing.

But that’s basically the progression, is having these sort of, what’s essentially like nested includes, little things included in bigger things included in even bigger things. Then taking that to the next step, which is where we break the atomic design analogy, that sort of chemistry analogy is getting into things that clients understand and your teammates understand. The next two steps are templates and then pages.

If you go all the way with the whole chemistry metaphor, people think you’re nuts. I sort of learned that the hard way. It’s like, eventually, you have to remind your clients and your teammates that, yeah, we’re actually making a website. Maybe going all the way with this sort of chemistry thing, it just doesn’t make sense.

But yeah, so we’re being deliberate, we’re creating these components and including them in a thoughtful, meaningful way. Then you eventually take these relatively complex components, these organisms, and start stitching those together to form what ultimately becomes the final page.

But at this template level, it’s not the final step of the process. This template level, what we’re doing here is, one, sort of establishing the layout and all of that stuff. But the big thing at the template level is concentrating on the content structure of the interface rather than the actual living, breathing sort of content.

I see this happen a lot, especially in the traditional Photoshop waterfall design process, where basically, every visual designer, they create a design and it looks beautiful and everybody’s name is Sara Smith without an H. You know what I mean?

It just fits so nicely onto, like, one line. Of course, their profile picture looks like it was cut out of a magazine. All of that stuff, and everything is perfectly filled out and all of that stuff.

It’s like, in the real world, obviously, that just doesn’t happen, those best case scenarios don’t happen. What this template level is here for is to sort of prevent what has historically happened, where once the PSD gets cut out and integrated into the backend system, only to find that everything just breaks and falls apart really quickly, because, again, it’s not a perfect world where everybody’s name is eight characters long.

That’s what this sort of template level is meant to do.

What are the character lengths, right, for someone’s name? What are the character lengths for our headlines? What are our image dimensions that we’re working with? How many distinct sections and stuff do we have and what patterns are we using to sort of create this template?

That’s the main reason why this template level is so important, because it just, it keeps people focused on the underlying structure of the content rather than getting distracted with whatever stock photo you happen to end up dropping into your design.

That’s the template level. Then really, it’s at that page level where that template sort of comes to life and you actually pour in, you sort of replace that FPO content, those placeholder images and stuff, with real representative content.

This is obviously what your end users are going to see, right, this is what the end users are going to interact with. Then this is also, of course, what your clients and your bosses and stuff are going to sign off on.

Why this page level is so important. Basically, what we’re doing is we’re taking these templates and then we’re pouring in this real representative content to, yes, show the final sort of visual design and all of that stuff. But more importantly, to sort of prove and kick the tires and basically demonstrate how resilient the system is.

You’re creating these simple components, you’re creating these complex components, you’re creating these templates. But does this system hold up, right? The idea of sort of modular design, it’s like, how do all of those modules come together? Does it look good? Does it function well whenever all the pieces are stitched together and real content is actually poured in inside them?

It’s at that level, that you’re able to sort of test the resiliency of this system. If things fall apart, then you can go through and change things, at a more atomic level.

Jared: Now, when you started this, this was really just how you were working. You started to tell people about it, and it really took off. I mean, the last year or so, dude, you’re everywhere. This has been big. The North Koreans are afraid of you.

Brad: [laughs] I hope so.

[laughter]

Brad: Yeah, it’s been really rewarding to go to a bunch of different places. I have been everywhere. I’ve been sort of living in airplanes, pretty much, for the last year. Going over to different countries and seeing people using Atomic Design for some of Europe’s biggest airlines.

Seeing, even places like Twitter and stuff, while they’re not using the exact same sort of language, they’re definitely sort of using that methodology. Sort of breaking things out a bit further than just like, here’s a bunch of modules and we put them together to sort of form this thing.

That’s sort of why I like this methodology so much is that, you don’t need the atoms, molecules, organism sort of language so much. It’s more about the thought process and using what works for your organization.

I’ve heard people call them elements, blocks and modules, or elements and components and then blocks. Names are sort of arbitrary. I happen to like the chemistry analogy, just because it has an implicit hierarchy within it.

Because I’ve had people come up to me and say, “Oh, well, why didn’t you just call them atoms, modules and then components?” Then the next person comes up to me and says, “Well, why didn’t you call them atoms, components and then modules?” It’s like, exactly. Those sort of names are a little arbitrary and that’s why I like this sort of nomenclature for it.

But yeah, it’s been super encouraging to see people really take it on and use it to craft an effective interface system for their organization. Just yesterday, actually, this education startup, FutureLearn, they just sort of released theirs and sort of are showing their atoms, molecules and organisms.

They wrote a blog post about how they made it happen, how just thinking about things in a different way, in this sort of atomic way, in this very sort of deliberate way, really helped them establish a common language that they could all sort of get behind and rally behind and stuff. That’s just, it makes me super happy to read stuff like that. It’s great.

Jared: In the year since you last did the workshop for us at last year’s UX Immersion Conference, which was this huge hit, has your thinking shifted? Are there things you learned? Is there something that is new? Or has this basically codified the way you imagined it would be, and it’s working out the way that you thought Atomic Design was going to be is actually how it should be?

Brad: Yeah, I think, the first year of thinking this way was definitely sort of buttoning up the methodology and seeing if it actually worked. It actually began its life as sort of four distinct steps, as basically atoms, molecules, organisms and then pages. Then, very quickly, that all fell apart, and so the template level was added.

Basically, I’ve been working this way now ever since last year at your event. It’s basically proved its worth and has held up really well and I’ve applied it to all the projects that I’ve been working on.

But again, sort of traveling around and talking to all sorts of different organizations that have sort of taken this stuff to heart, and it really seems to be working out really well for lots of people.

That’s awesome, the big thing that’s been happening for this last year has been, again, sort of, validating the methodology by working on real projects with it. When we launched timeink.com, sort of doing a bigger redesign of that site, which really was the first time I sort of used Atomic Design and Pattern Lab, the tool that we created with Dave Olsen, to actually really make this stuff happen, in a big way.

It’s also applying it with a product I was working on more of like sort of an app type thing, and a few other projects, as well. It’s just been wonderful.

All the while, we’ve been sort of collecting case studies and resources and sort of seeing more and more people release their pattern libraries, and style guides out in the open. One of the big projects that came from that, I’ve sort of been silently collecting a lot of that stuff in the background.

As it turns out, a few other people, including Anna Debenham, over, based in the UK, she was doing the same. She wrote a really phenomenal book on front end style guides, of that name, “Frontend Style Guides” is the name of the book.

We got together, I said, it’d be great if we can sort of make a website that sort of was an aggregate of all these, sort of articles, examples, and tools around creating crafting style guides and pattern libraries and all of that.

Sure enough, Anna, being the amazing person she is, sort of like the next day, it was like, “Oh, and here’s the website.” Then we basically just started seeding it with a bunch of different content, so now that’s a resource, and it’s called styleguides.io, is the name of it.

Jared: This idea of style guides, I mean, this is something that people have talked about for a long time. But I’m not sure they’re always using the phrase the same way. What do you mean when you’re talking about a frontend style guide?

Brad: Yeah, so, I just wrote a post about this, basically, running down the various flavors of style guides. Historically, style guides have been sort of brand identity guidelines.

Jared: Right, I remember seeing a Pepsi style guide, a few years back that was, how do you use the logo and what colors can you use. When you have the name Pepsi but it’s not in the logo, what do you do that? What’s the proportional sizes of things? All of those types of things, to make sure the brand is always protected.

Brad: Yeah, yeah, exactly. Those things are incredibly valuable, but often times, they’re sort of locked up in a brand book or like a physical book. Back whenever I used to work at agencies, I would have these books on my desk, which are sort of funny in retrospect. Yeah, increasingly, more of those things are moving online, which is great.

That’s one type of style guide, these sort of brand identity style guides. Then there’s these sort of emerging ones, these sort of design language style guides. Things like Google’s Material design. But also, IBM just released sort of their design language and stuff as well.

This is a bit murkier than brand identity guidelines, like, “Here’s the logo and here’s how you use it.” It’s more describing a design language and philosophy, almost. But then, also, sort of how to apply that stuff.

Jared: When Apple first came out with the Mac, one of the first things they did was they published this thing called the Apple Human Interface Guidelines. That was a book that said, “OK, this is how menus work and every application should have file, edit, and view as their first three.

It shouldn’t be view, edit, file, or edit, file, view. It should always be file, edit, view, and opening and closing files is in the file menu. And this is the language and you should use the Command+O key to open and the Command+Q key to quit. Don’t assign them to other things.”

It was basically this guide that set down these guidelines, in essence, that told you what a proper application was and how it would work. Lots of folks have produced those since then, it’s been a popular thing to do, but that’s a little different than what you were talking about. That’s not really what material is.

Material has some of that, but material also has a huge component library that let’s you, basically, build things quickly.

Brad: Yeah, and that’s what these things are. Again, they’re murky things, because they’re not totally prescriptive about always do this, never do this. There’s a bit of that. It’s part philosophy, part strategy, part brand. But then also, part tool kit. It’s like, “OK, here’s the stuff, go nuts with it, and here’s some guidelines for making that happen.”

It’s been fascinating seeing these things emerge. Granted, they’re still coming from the Apples, the Googles, the IBMs of the world, but increasingly, even at relatively small organizations or less tech savvy, like they’re not making operating systems. But they do have a brand. They’re trying to put out a consistent mission and consistent tone, consistent philosophy.

This stuff is starting to make sense just for everyone, rather than people that are creating these platforms.

Jared: Now, part of the goal with style guides, I think, is to shorten design and development time.

Brad: That’s a huge aspect of it. I can’t count the amount of times I’ve seen wheels get recreated and recreated and reinvented and reinvented, just over and over and over again, for no other reason than just Tony sits in the other room than Sara. That’s really the reason why that stuff happened.

The whole point of creating these style guides is, absolutely, to save time and effort and whenever the boss comes back and says, “We need this new section of a website,” it’s not an, “Oh crap, that’s going to take five months and blah, blah, blah.”

It’s like, “No, we already have all of our pieces in order, all we need to do is arrange them on the page in the right, logical order, put in the new content,” and there you go, you have a new section of the site that looks consistent, that stays on brand and all of that stuff, without having to totally reinvent the wheel.

This is so massive on a lot of different levels. Especially as somebody that comes from an area where working at agencies, very often, we were so quick to just ignore or bulldoze those existing standards, those existing interface patterns, those existing looks and feels.

We’re just like, “No, this is our little piece of the puzzle and we’re going to do something crazy and parallax, and blah, blah, blah,” or whatever. Just because we can. We didn’t honor the organization’s overall structure.

I think that these style guides are becoming just massively important for organizations, especially those that work with contractors and third parties and stuff, to just make sure that everyone is honoring the system that’s been created.

Jared: Another thing that style guides, I think, does, is it allows folks who, because of the structure of the organization, may not be working and collaborating together at the same time and place, come up with something that feels like they actually talk to each other.

Brad: Yes, and in my experience working with organizations, it is absolutely essential for the actual creation of the style guide, absolutely essential to have, I call it the A team, you need a cross disciplinary, you need all people represented sitting equally at the table to actually create this thing.

But once you actually establish your design language, once you establish your style guide and stuff, yeah, then you could delegate. You could have people in other countries or cities or whatever all making use of this style guide, and not have to worry about whether a developer that’s in Romania is going to go rogue and write their markup in a totally different way, or design their own buttons or whatever.

They’re still able to follow the guidelines that have been put in place by this core group. Typically, higher level leadership, smart people, putting this resource together and then basically all the foot soldiers are able to make use of that.

I think that that’s really smart to do, just because those people in those leadership positions can’t be everywhere.

Jared: Folks who are implementing these things using an enforcement mechanism, is there a, “You will not be allowed to ship if you do not follow the style guide” stuff? Or is it more of a, “This is the guideline and we’re going to make it really easy for you to implement to this guideline, but if you’ve got a good reason to not implement to this guideline, go ahead and do that?”

Brad: Yeah. How effective these things are matters entirely up to how the process workflow and organization is structured.

Jared: You mean success is based on people actually working together and talking to each other, is that what you’re saying?

Brad: What? I know, it’s crazy. Right?

Jared: Wow, that’s crazy talk. Can’t we just create a flow chart, and then be done with this?

Brad: Yeah. There are, actually, some great tools that do help enforce a lot of the stuff. Actually, there was just a great post this morning about SaaS linting and stuff for your CSS. Basically, if you go rogue, if you write things in your own way, your tools will yell at you.

That’s sort of cool. You can actually have some technology assist and keep people on track and keep things consistent. That obviously works well for code, but for lots of other things, it matters entirely on the people.

But that being said, one of the things I do find, a common complaint for style guide driven design, is a lot of the visual folks and stuff are like, “Yeah, but I can’t be creative. I can’t explore. I can’t do my own thing.” It would be blue sky. In the back of mind, I’m like, “Good,” whenever those people say things.

That being said, I do think it’s important whenever you’re crafting these systems to build that flexibility in mind. Where it’s like, “OK, well here’s this hero area and this hero area might have a bunch of editorial content or might have some promotional stuff.” That stuff is going to change wildly.

It’s not like you always need to use these three colors and it always needs to be in this layout for this section. It’s important to build that flexibility into the system, where it’s like, “Here are the areas where you can go crazy. Here are the areas where that flexibility is OK.”

But other areas of the site, doing business parts of the site, like filling out a form, and all of that stuff is like that stuff needs to more closely follow the default style guide.

I think it is possible to create a system that simultaneously encourages and enforces consistency and cohesion, but still gives people the tools they need, the patterns they need, in order to be a little more flexible and be a little bit more, I don’t want to say the word creative, but, wild or deviant.

Jared: That’s one of the big arguments that I often hear about style guides is that it squashes innovation.

Brad: Yeah, and that can be true. If you’re a dictator with it. If you want to rule with an iron fist and be like anybody that so much of puts one line of text in a non-sanctioned font, you’re going to get your hands chopped off or something, that’s not good.

But again, it doesn’t have to be that way. I think that it makes a ton of sense to establish these languages as a solid guideline into nine times out of 10, just lean on what’s already been created to do your work.

But if there are valid reasons to deviate from those things, it’s like, use those opportunities as a conversation starter to be like, “Hey, we need to do something differently, what could we do about that?”

Very often what you’ll find, working with a big, large retailer right now, there are certain areas that need that extra bit of flexibility or wiggle room within the constraints of the system. OK, just account for that stuff up front and that helps keep everybody happy, people putting out these very rich, very image heavy or lettering heavy areas, are still able to do their thing while the rest of the system remains intact.

Jared: Yeah, what I’m hearing you say is that a team needs to make sure that in addition to putting together this style guide, which has all the mechanics of what a great experience is going to be about, they need to talk about when do we allow deviation from the style guide.

Because it’s actually going to make the experience even better. And when do we put up a block to that deviation because it’s creativity for the sake of creativity and not because it’s going to make the experience better.

Brad: Yep. That’s why I think it’s so important for organizations to have people who own and shepherd and enforce these things, people that can be those people that are responsible for those decisions and can make the final call. Like, “No, fall back in line. Use the buttons we’ve already created.”

Or, “OK, this is actually a pretty interesting thing, maybe we’re going to make a new pattern, and roll that into the style guide as well.” That’s, I think, the idea, is those deviations might begin their life as deviations, but if it’s something that works well, then that should ultimately be rolled into the system.

The idea is to build things for reuse and build things for the long run, because maybe you’re doing a similar campaign next year. Maybe you want to make use of those same patterns that you established.

It’s not about deviating from the system in this big series of one-offs. It’s about, “OK, well, the system doesn’t do this currently, here’s what we want to do. Let’s make it happen.” Then really, at the end of it, let’s roll that stuff in so that new stuff is a part of the system now too.

Jared: Absolutely. This is really exciting. In your workshop that you’re going to do at the UX Immersion Conference, you’re going to talk about building up Atomic Designs, putting that into responsive web designs.

Will you hit on some of the style guide stuff?

Brad: Oh yeah, absolutely. I’ll talk about atomic design and talk about some tools to actually make this stuff happen. And also some techniques to get started. Most places I go to, a lot of the challenges around style guides is that they’re oftentimes treated as a separate project.

It’s like, “Oh, we don’t have the time or the budget.” “Oh, it would be nice to be able to do this, but we have a site to get out the door, we have an app to get out the door.”

I think that that’s unfortunate, sort of myopic thinking. I think that what I’m going to cover in my workshop will really help teams create their own style guides through the duration of their project.

It doesn’t have to be a one or the other kind of thing, or, oh, we need to free up some more budget for this. It’s, no, you could actually just sort of build this into your process and end up creating a new, shiny site, but then also creating the underlying system, behind that site.

We’re going to talk a lot about that. Then also, talk about a lot of those molecules and organisms, those things that you could put onto a web experience, put it into an interface. How do data tables work across different screen sizes and environments? How do carousels work in modal windows? What happens with those things on the small screen?

I think that’s a lot of what the workshop is going to cover is, how to think more systematically with respect to design, how to sort of establish patterns and make that sort of a cornerstone of your process and methodology. Then also, take a look at basically anything you could put onto a screen and how to make that work on all of these different screen sizes and environments.

Jared: You’ve created this really cool resource that I heard about, called styleguides.io.

Brad: Yeah, yeah. That’s what Anna Debenham created the front end for it and we’ve just been sort of seeding it with all sorts of different examples of style guides and articles about style guides, podcasts and talks and tools and books and all sorts of stuff. It’s basically like a one stop shop for all things style guide related.

Yeah, definitely have been having a lot of fun feeding that with a bunch of content and more and more people are sort of adding resources to it, as well. It’s a totally open source project, so if anybody has any resources that they want to share, we’d love to have them, for sure.

Jared: That’s amazing. Brad, thank you so much for talking to us about all this, today.

Brad: Yeah, well, thanks for having me. I’m looking forward to April.

Jared: Yeah, it’s going to be great. If you’re listening to this and you, of course, if you’re not listening to this, then, I’m just not going to talk to you. That’s just the way it’s going to work.

But for those of you I am talking to at this very moment, if you want to attend Brad’s workshop, you are going to be in for an amazing treat, because this was just the hit from last year’s User Experience Immersion Conference. You just spend this entire day building things up from atoms.

We start with an atom maker and you just build them all up. It’s really a fun, informative day. Everybody loved it last year. It’s very much a hands on thing. Just be prepared to do great stuff and Brad’s a genius about this.

Come do that. You can find out more information at the conference website, that’s the UX Immersion Conference, uxim.co. It’ll be in Salt Lake City, beautiful Salt Lake City, April 13th through 15th, and we’re just really excited that Brad’s going to be joining us. It’s going to be a ton of fun.

Brad: Yeah, I’m excited.

Jared: Brad, thank you. Thank you, thank you, thank you, thank you, thank you.

Brad: Thanks, Jared.

Jared: I want to thank our audience. You guys are awesome. If you have a moment and you really enjoyed this, go to the iTunes and give us a review, and that would be great. Of course, thank you for encouraging our behavior. We’ll talk to you again. Take care.