Brad Frost – Creating Responsive Interfaces

Sean Carmichael

January 16th, 2014

Play

[ Transcript Available ]

Brad Frost

Brad is joining us to teach one of the daylong workshops in Denver, CO April 7-9 as part of the UX Immersion Mobile Conference. For more information about Brad’s and 5 other workshops, visit uxim.co.

Frameworks and design patterns are no strangers in the world of web design. As responsive web design becomes common practice, making sure these templates work across every imaginable screen and device is trickier. There have been attempts to break down page elements in separate modules, but you often never see it fully assembled.

Brad Frost shares this frustration and introduces Atomic Design as a solution. Borrowing from the metaphor of atoms making up molecules, molecules making up organism and so forth, Brad thinks responsive design needs to be approached deeper than at the page level. Having these individual modules is great, but how do they all fit together?

Designing in this way allows you to be more deliberate and systematic in your approach. Dividing an interface up creates the ability to stitch webpages together but in a way that builds from an atomic level and you can clearly see how you’ve arrived at the end product. This approach to responsive design, as Brad says, serves to solve problems in a very acute way.

Recorded: January, 2014
[ Subscribe to our podcast via Use iTunes to subscribe to UIE's RSS feed. ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.


Jared Spool: Welcome to another episode of the SpoolCast. I’m so glad you’re joining us today, and I’m even happier that we have the amazing Brad Frost with us. Brad is a wonder-dude. He’s been at the forefront of the responsive-design movement lately and has been doing a lot of really cool stuff in terms of resources.

He’s teaching a full-day workshop at the UX Mobile Immersion Conference coming up in Denver on April 7th through 9th. He’s doing a full-day workshop called “Using Atomic Design to Create Responsive Interfaces.”

We have Mr. Frost with us right now. Brad, how the hell are you?

Brad Frost: I am fantastic. Thank you so much for having me. Thanks for the kind words. We talked really, really quickly about Skype and how reliable it is, and sure enough, somewhere in that intro, it cut out. [laughs] I got the tail end of it. [laughs]

Jared: There you go. Well, I talked about your childhood, and I talked a little bit about that whole incident with the sheep. We covered a lot in the time that it cut out.

Brad: [laughs] Was a good seven seconds…

Jared: One of the things about Skype is it actually change the space-time continuum.

Brad: That’s good to know.

[laughter]

Jared: In addition to not hearing what I say in Skype, let’s talk about other things. In particular, everybody I keep running into is talking about something that you did back in 2012. It was a website called “This Is Responsive.” It’s this really cool resource that you put together to help people create responsive Web stuff.

Why don’t you tell people what it is, and more importantly, what made you put all the work — and it’s a lot of work — into this thing?

Brad: It’s an ongoing project. Basically, I contribute to it whenever I can and finally got around to allowing other people to submit resources and stuff. Basically, what “This Is Responsive” is, is just a resource center for responsive design that includes a lot of categorized links but then also boiled-down interface patterns for creating responsive designs.

What caused me to make it is, at the time, I was working at an agency called RGA in New York City, and for whatever reason, I had three different client teams, all in one week. They all called me up and they said, “Brad, how do you do breadcrumbs in a responsive way?”

Jared: [laughs]

Brad: The most random, planets-aligning thing, where all of a sudden, breadcrumbs [laughs] were on the front of everyone’s mind.

Jared: Well, it was national breadcrumb week.

Brad: Apparently. Like, “All right, we got to get this thing out here.”

Jared: [laughs] Seriously. “Oh my God, next week is national breadcrumb week, and our mobile design does not have the proper breadcrumb work!”

Brad: [laughs] National carousel week aligned with the Mayan calendar ending.

Jared: [laughs] I think, in fact, that was the thing, right? What happened with the Mayan calendar is that they implemented carousels. That was when they discovered the world was doomed.

Brad: Yes, pretty much.

[laughter]

Brad: These three teams, they all get in touch with me, all separate clients. I’d float around different projects within the agency, so I was in this position where I was seeing these three teams struggling with the same thing. As the week went on, I met with all the teams and heard them out, and I said, “OK, I’ll go away.”

I could have explained what to do to each of the three teams individually, or I thought a better use of my time would be to actually just create some really vanilla, gray-scale versions of what these different patterns might be.

That’s what I did. I went away and I created these little patterns and then showed them to each of the teams. I said, “Here’s one way you could do it. Here’s another way you could do it. Here’s another way you could do it.” Then they said, “Cool,” and they took the path that their respective projects felt like they needed.

I was like, “Wow, that worked,” and I was like, “Well, maybe I could actually do that with other things in the interface.”

At that time, I was just starting to get into talking about responsive navigation and complex navigation and drop-downs and all that good stuff, but then even just getting into, yeah, different ways to handle layout — at that time, Luke Wroblewski wrote a really great post, boiling down a lot of the responsive sites that are out there into these sort of patterns.

Really, I just rolled up my sleeves and started creating this gray-scale pattern library of different interface patterns. The reason why they’re gray-scale, too, is, again, just so that people don’t get distracted, teams don’t get distracted, by the content that’s inside these patterns and stuff like that.

I’ve seen this a hundred times before. Whenever the “Boston Globe” launched, for example, I was working at an agency, doing a lot of really visually stunning, wowie-zowie brand pieces. Whenever the “Boston Globe” came out, I’m like, “Hey, yeah, we could do something like this,” and they’re like, “Yeah, but we’re not a newspaper.” I think, too often, people — I’m sure you see it all the time, too. [laughs]

Jared: Oh, yeah.

Brad: “That doesn’t apply to me because I am a global Intranet provider.” You sort of have to blur your eyes a little bit to extract the good bits.

That’s what I was trying to do with the pattern library, just to create this very neutral hub for the 100,000 different ways you could slice up an interface and all of the things you could put on an interface, and it’s done pretty well.

As patterns come out, we’ll update the library or somebody will submit a pattern. It’s all open-source on GitHub and all that good stuff. It’s really great because we have the whole community now contributing these abstracted patterns for the benefit of all, which is fantastic.

Jared: I like that at the top of the responsive-patterns page in the “This Is Responsive” GitHub thing, it has this big black button that says, “Submit a pattern,” so you can just go submit one. I know exactly what you mean about baggage being drawn along, that when people see something that’s done by the “Boston Globe,” they go, “We’re not a newspaper.” That happens in so many…

Last week, I was in a meeting where we were discussing personas. The personas all had names, like Bobby and Jean, and then one of the personas had the name Aurora, and we’re like, “Aurora? That’s odd.” It turned out that the person who named all of them had named them after X-Men characters.

Brad: [laughs]

Jared: Then, all of a sudden, we’re dealing with one called Logan. People are wigging out over Logan, because they’re like, “Logan has to have chops, and he’s got big metal things that come out of his fists.”

Brad: [laughs] “He’s got a metal skeleton.”

Jared: Exactly.

Brad: “We have to design around his metal skeleton.”

Jared: [laughs] “Jean doesn’t need to look stuff up on the Web. She can read minds.”

[laughter]

Jared: People bring baggage with them.

What I like about what you’ve done here, particularly this idea that you’ve reduced it down to black and white. That just makes everything really clear as to what that pattern is. It doesn’t clutter it. It’s just a very simple design piece. I think people can come in here and take their team around a machine and say, “Wait, did you mean it this way or did you mean it that way?” How have you seen people using this?

Brad: Unfortunately, I see people take it out of the box, and that’s exactly what not to do.

Jared: What do you mean by that?

Brad: Meaning that people take what are essentially proof-of-concept code and proof-of-concept ideas and just slap it in there without any sort of thought applied to it, and that’s what not to do. I’ve had people say, “This doesn’t work in IE8,” and I’m like, “Well, that’s not what I’m going for.”

The idea — and I’m a firm believer of this with all the stuff that I do, a big, firm believer about, “You need to do this stuff yourself.” I’m not going to prescribe solutions. It’s just about providing hints and best practices and resources and stuff like that so you could do your job better.

The way that I’ve seen people use this. Thankfully, my Twitter feed, seemingly on a daily basis, is, “Oh, I was struggling so much with how to handle this really complex navigation with three or four or five-levels-deep sub-navs and stuff like that, and this collection of patterns really, really helped me out. My team, we’re able to discuss it. We’re able to take one of these things that we thought was the best solution and build on that, and that’s what we ended up using.”

Same thing goes with tabs. How do you deal with horizontal tabs, which are a pretty common interface pattern on a larger screen? Then, whenever you lose so much screen real estate, all of a sudden that tab interface, that pattern doesn’t scale. It doesn’t work anymore.

Everyone struggles with problems. Everyone struggles with these interface patterns. Everyone’s struggling to wrap their heads around, “How do we actually make an effective interface that actually simultaneously scales and works really well on small screens, on medium screens, on large screens, on extra-large screens, and everything in between?”

It becomes this place to scratch itches and to help keep you from beating your head against a desk on how to get from point A to point B.

What I’ve also found — because not everybody is a front-end designer, front-end developer, actually working in code. There are still a lot of people working in static wire-frames, professional PDF makers, and still a lot of Photoshop comps and stuff going on.

What I’ve found, actually, is that having that working example in the “This Is Responsive” pattern library allows teams that are still creating these static visuals to help articulate and understand how they might get from home page_mobile.psd to home page_desktop.psd.

They can show, in the desktop PSD, the tabs, but then, whenever you get down to a small mobile screen, they’ll show it in more an accordion fashion. They’ll be assured that it’s technically feasible, which is great, because historically I’ve been the guy that’s fielding all those questions all the time — “Hey, Brad, can we do this? Hey, Brad, can we do this?”

Jared: You’re the one we’re supposed to be talking to.

Brad: [laughs] Yeah. It ends up being any sort of developer. “Hey, developer, grunt back whether or not we can actually do this, yes or no.”

Jared: [laughs]

Brad: “Don’t give me any more insight. We don’t want your opinion. Just say yes or no, can we do this, and get on with our design work.”

I’ve found that to be a pretty effective ways for teams to still work in the process that works for them, but have more confidence that, yeah, what we’re designing we can actually accomplish realistically, which is really cool.

Jared: Now, you’ve also gone off and done this thing called Pattern Lab. What is that?

Brad: [laughs]

Jared: What the hell is that?

[laughter]

Brad: I’m actually really struggling — still, actually — to figure out what Pattern Lab is. Pattern Lab, in short, is a way, is a tool, to help people create atomic-design systems.

Jared: One of the things you’re talking about at the UX Immersion Mobile Conference is, you’re spending a whole day introducing people to this whole idea of atomic design. I love this concept of atomic design. What you’ve done is you’ve broken things up into a metaphor that’s similar to the way atoms become molecules and molecules become organisms, and organisms become cows and cows then become societies of cows.

Brad: [laughs] Something like that.

[laughter]

Jared: You’ve sort of divided the Web up that way, right?

Brad: I’d say divided interfaces, right, up to these things, because what I’ve found is the basic trend for everybody has been, “Yes, we want to be more systematic in our designs. Yes, we want to break things up into modules. We want to do things like style tiles and element collages. We want to utilize things similar to Bootstrap and Foundation.” This whole, everybody’s been blowing up these whole interfaces.

Again, back to “This Is Responsive.” That’s what I’ve been doing for the last couple of years has basically been exploding interfaces and basically solving the problems in an acute way — again, like “How does this work across all these different screen sizes? Does this all fit together?” Without having to worry about thinking about things at a page level, we’re trying to think of things at a deeper level.

One of my biggest frustrations with all of the techniques that are exploding and breaking things down into modules is that they become just that — this collection of random modules. What I’ve found, and was increasingly frustrated by, is that there’s no real good way to categorize these or really any rhyme or reason to why things are put in certain places.

Some of the modules would be relatively simple, and other things would be these big, self-contained components and stuff, like a carousel or something like that.

I was like, there has to be, I think, a more deliberate way to break down an interface, but also see it all the way through, in its final, put-together place, in its final resting place. The things that we’re actually building are still full Web pages. One of my biggest frustrations with these pattern libraries and UI toolkits and stuff like that is that you never really see it assembled.

I know it’s up to you, but at the same time, that ability to traverse between really abstract and really broken-down and put-together and in-context, they very much rely on each other in order to create not just the final product, your final project, but also the underlying system that goes into that.

That’s what atomic design and what Pattern Lab is, is this way to, basically, stitch an interface together, starting at the very atomic level, and build up that interface into its final pages, and be able to see, very deliberately, how you’ve gotten from point A to point B.

Jared: As I understand this, the atoms are like the various tags and primitives that you have at the lowest level of HTML or CSS or JavaScript, and then the molecules are when you combine those things, like you take an input field and a label and you now have passwords. Then the organisms, that level of things might be a login dialog box that has a user name with a field and a password in a field. You’re combining these things, right? Did I get that right?

Brad: Yeah. I think that, yeah, more or less, that’s it.

Molecules are a couple tags stitched together. You might have just a search form that’s comprised of search label, an input, and a button, and that is a self-contained little assembly of stuff that does something.

Atoms by themselves, the tags are all really abstract and floating around in space. You don’t really see, inherently, just from looking at that level, how these things might be useful. It’s like, “Well, that’s nice.” It’s helpful at an at-a-glance sort of level. Then you start combining them into these little packages, these little molecules, and now they could actually start doing something.

You might have your primary navigation as a molecule, your search form as a molecule, and stuff like that, and then you put those molecules together into a header organism. Now your header organism contains your logo atom and contains your navigation molecule, it contains your search-form molecule, and all those things operate at this standalone, reusable component.

From there, then you start stitching these organisms together and finally start building these sort of page-level things, like templates and then, ultimately, pages, which we don’t have to get into.

The idea is that you have these little clusters of elements, and then you combine those together into more complex clusters of stuff. The whole idea is to basically establish this really sound, really deliberate interface, where everything is being built up with the intention of creating a system that’s built for reuse, built for scalability.

Certainly helps with responsive design because, again, you’re able to treat these problems at the component level rather than at a page level. Also, just from being future-friendly — you’re establishing these nice rules and guidelines and constraints, and this goes inside of this, which means that the new hire you hire four months down the line can understand how things are put together and why things are put together in the way that they are.

I think that in my experience using this and helping create this, what we’re doing now, why we’re doing this, is that it’s no longer feasible to just throw over a handful of page templates to a client and just say, “Here’s your site. Have a nice day. Make sure I get my final paycheck.” It’s not enough to do that anymore. We have to be a lot more deliberate with this.

We have to give them better tools, better resources, so that we don’t come back next year and, all of a sudden, they’ve changed the color of green and they’ve put this thing next to this thing and they’ve created a bunch of new code all on their own, in different patterns and stuff, and it all looks like a big, giant, Frankenstein mess.

In part, that’s your fault if that happens, simply because you didn’t give them the library of components, you didn’t give them the building blocks, the LEGO bricks, so that if they need to add a new section to the site. If they need to add another widget, or an organism or component or whatever you want to call it, they have a language to choose from and make informed decisions. I think that that’s really, really cool.

In fact, one of the clients that we first did this on — actually, the very first client that I introduced this whole atomic-design, Pattern Lab concept — was TechCrunch. I was actually just on their site last night and noticed that they had added a different component to the site. You read the article, and then there was an extra little “You might also like” sort of thing.

Now, we had our own version of that, and that’s still there, but then they added a separate “You might also like these stories.” What I found is that they used the interface patterns that we provided them to construct an entirely new module.

Jared: It’s a mutation.

Brad: Meaning, yeah, exactly. [laughs] Keeping with the theme.

Jared: When will they get metal skeletons on their pages and mind-reading templates?

Brad: [laughs] Exactly.

Jared: [laughs]

Brad: I was so thrilled with that, because we provided them the language, the system, and they were able to take that system and extend it even after we were gone, so it didn’t look like garbage. It’s happened so many times in my career, where we hand them over these gorgeous working templates, and here’s your pixel-perfect PSDs, and here’s your totally marked-up Web-standards template.

Then they take it and then they butcher it, and then they continue to butcher it to the point where, six months later, you don’t even want to include it in your portfolio anymore.

That’s why it’s not enough to just, again, hand over these pages and hope for the best. We need to actually deliver — even internally. If you work at an organization, you’re not just working on your project. What you’re working on is something that could potentially be used for years in your organization, across different projects.

Maybe that tab interface pattern that you’ve helped devise and build out and design, maybe that can be used across all of your company’s properties. Why not?

I think that that’s the impetus there is that that’s the motivation for creating these really robust design systems, is to just really help give everyone a path. Again, it’s all totally yours. It’s your system. It’s all totally custom-built for you and your needs, which is great, versus something like Bootstrap or something like Foundation, which gives you too many of these answers.

It’s like, “Oh, here’s your buttons and here’s what they look like, and here’s your accordions and here’s what they look like.”

I’m not saying that they’re bad tools, but at the same time, if Nike, Reebok, and Adidas all used Bootstrap, they’d all look pretty similar. In my experience working with really big brands, the last thing they want is to have the same design system as everyone else.

Jared: Pattern Lab is a tool that you can use to interactively build this stuff, right?

Brad: Yeah. What Pattern Lab is, at its core, it’s just a way to stitch together the interface. It’s for more front-end designers, where basically you can include your navigation into the header organism, which will be included in the pages and templates and stuff like that. It’s a tool that basically allows you to stitch it together.

It’s in code, but again, I work in cross-disciplinary teams, so while I’m typically the one working the most in Pattern Lab, I’m working with visual designers working in Photoshop, I’m working with IAs and stuff creating the initial patterns in the first place, and we’re all working together on this.

That’s what Pattern Lab is, sort of a front-end development tool to actually create these design systems. The idea is that once you actually create these things and you have everything stitched together, ultimately that becomes a deliverable. It’s like, “Here’s your final product, and oh, by the way, here’s the underlying system that’s gone into that.”

That helps with things like integration into a CMS, just because they’re able to cherry-pick all the patterns that they need and stuff like that. It helps for their management to understand everything that went in there. It helps everyone involved in the team have a better idea of what all went into this and why things are arranged the way that they’re arranged.

Jared: Inevitably, what you’ve done here is you’ve created this whole collection of resources that people can use to create great responsive websites. It’s really exciting. Folks are using this stuff, and they’re getting a lot out of it.

Brad: It’s pretty insane, actually. I’m not a hardcore programmer guy. I’m just getting my feet wet with the whole GitHub, open-source stuff in general, but yeah, the activity on both Pattern Lab and “This Is Responsive” has just been really wild. There’s hundreds of people that are all writing comments and stuff on this or saying, “We have these issues,” or “We fixed this” and stuff.

It’s just been fantastic, because the great thing about it, especially with atomic design, is I’ve not had one person say, “That’s a stupid, stupid idea. We shouldn’t be thinking of our interfaces in this way.” It’s been really, really promising. As I do more client work — I’m doing a project now. I’m doing, actually, several projects now — it’s becoming a really natural way to do things.

I think that we’re being more deliberate in our thinking. We’re being more thoughtful, and we’re trying to be more future-friendly in our actual process. As we go through this, what we’re trying to do is not just make a website that looks great and solves the needs of our clients today, but we’re really trying to help them out long-term and make sure that the best practices that we’ve established don’t go south as time goes by.

It’s been really fantastic seeing everybody use these resources. That’s why I love doing this stuff so much and talking about it is because I work on my own projects, I’m an all-right designer, but it’s really fascinating watching actual, real, good designers [laughs] take these concepts and really make just really amazing things with them.

I couldn’t be happier. It’s not really about the work that I’m doing but rather about what that’s facilitating others to do. It’s really cool.

Jared: That’s awesome. I want to thank you for introducing us to these cool resources. I’m really excited that you’re going to be talking about all this at the UX Immersion Conference in Denver. Thanks.

Brad: Yeah, thank you. I’m really looking forward to it, for sure. A whole day of this.

Jared: A whole day, an entire day. For those of you who are loving this stuff, you can get more of this loving from Brad Frost at the UX Mobile Immersion Conference in Denver. He’s going to be speaking a full-day workshop on Monday, April 7th. It’s called “Using Atomic Design to Create Responsive Interfaces.” You can find out all about it at uxim.co.

Brad, I’m excited to see you there. It’s going to be a lot of fun.

Brad: It’s going to be fantastic. Looking forward to it.

Jared: Thank you again, and I want to thank our audience for listening, and, as always, thank you for encouraging our behavior. We’ll talk to you soon. Take care.

Add a Comment