The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #257 Brad Frost - Building Design Systems from Atomic Elements Live!

December 18, 2014  ·  82 minutes

Listen Now

Download the MP3

Have you seen style tiles, element collages, or pattern libraries? These are just a few examples of how designers are reacting to the explosion of devices and interface sizes. After all, thinking about the parts of a “page”—not just the sum of those parts—helps us create smart, scalable, maintainable designs for all those newfangled technologies.

Show Notes

And a leading voice behind this elemental thinking is Brad Frost.

In this talk, he’ll introduce Atomic Design, a methodology you can use to create a design system in your organization. You’ll learn how to:

  • Deconstruct your organizations’ interfaces
  • Create systems that includes templates, and pages
  • Create designs that are future-friendly and extensible
  • Establish a repeatable workflow tailored to your team and product

Whenever you read TechCrunch or Entertainment Weekly online, you’re looking at Brad’s Atomic Design work. He follows the methodology so regularly that he created a free tool called Pattern Lab that helps you create your own design systems.

Full Transcript

Brad Frost: Thank you. Thanks for coming. Can you guys hear me OK? On. Off. There we go. Hey. All right. Thanks for coming out. So we're going to talk about Atomic Design and where all that's going. Actually, I'm super excited to talk about it. I've been sort of neck deep in it for the last I guess year and a half now by now, but really getting going with it over the past eight months, which we'll talk about in a bit. So sort of to set things up here, once upon a time there were these things called books. They were heavy and awkward and then you turn the page and it cuts your fingers. They're awful. It's like an awful invention. I'm so glad they're not around anymore. They're miserable things. But this idea of the page I'm just actually reading a book now. They're talking about the history of all this stuff. Books have been around with pages, those long scrolly things for almost 2,000 years, so this idea of the page has been with us for ages, and we carried that into the web. This is the first book I ever read on web design-- just kidding-- but it's pretty awesome looking. But yeah, this idea of the web page has been with us since the birth of the web, and we talk about this on all of our projects.
How many pages is the site? How long is the home page going to take you? How many pages? We're a university. We have 50,000 pages to our site. And really, this has been our mental model of the web for again since its inception.
But now all of a sudden this is our reality. This is a humbling image. You've got 200 people to pile out all their devices and sort of one giant arc, and you can see just different screen sizes, different input types, different form factors, different everything.
This idea this sort of static web page just isn't practical anymore. But now with the rise of all this responsive design stuff, we have to sort of communicate this to our teams and to our clients and so what do we do but we make a large version of a web page. It's always on a MacBook Pro. It's always on a cinema display or something. Who works at a place that does stuff like this, just out of curiosity, morbid curiosity?
And then the iPad that's showing the web page on a medium screen and then an iPhone on a mobile screen and you tilt them slightly to get your point across. So this is how you have to show your clients, right? But this doesn't work anymore. Just sort of scaling this idea of web pages and sort of duplicating your efforts is just totally inefficient. So we quite literally have to blow it up in more ways than one. And so that's what's sort of given rise to this term design systems, and people have been talking about design systems for a while now. Andy Clarke talks about design systems with regards to aesthetics, things like your color, and your typography, and your texture and how sort of all those things work together to form your design system. And while that's certainly a lovely thought, that's not really what I'm interested in. I don't know about you, but I'm a little annoyed now. I'm over the whole flat design verses the morphic thing. Anybody with me on that? I'm like huh. So that's not really what I'm talking about with respect to design systems. I'm more interested in this question, what are interfaces made of? What are the subway sandwich pieces that make up our interfaces that we can combine in all these various ways to make all sorts of these millions of combinations? What are our LEGO bricks? And I've been wrestling with this question for a while now because I've been working on a responsive design pattern lab called this is responsive that sort of collects all the different elements you could put on a page and figure out how those work in a responsive environment. How do bread crumbs work in responsive? How do you carousels work in responsive environment? How do accordions and tabs and all the stuff? And so I've been in a sort of obsessed with this question for a while now and that's what sort of led me down this road to start thinking about things in terms of components rather than these sort of full-on the web pages. So as it turns out, this responsive design stuff is hard, and doing all this stuff is really, really difficult. Solving these problems are hard. And so that's what's given rise to a lot of these sort of UI frameworks. Anybody using Foundation by ZURB? What about Bootstrap? Ooh, look at all those hands. Crazy, right? And these things are great. I like these things. I think that they're great. You're able to sort of again very, very modular system. You're able to sort of drop things in, combine them in certain ways, demonstrate interactivity a lot easier. I like these thanks, again, especially for prototyping and stuff like that. Here's my problem with them. Look at these people. They look ecstatic.
Whenever I watched sci-fi movies and stuff as a kid, I would watch these things and I'm like I guess if it's just given enough time, we'd just solve fashion. We're just like, OK, everybody is just going to wear this unitard from now on. Fashion solved. Check. Moving on, right? And it's just like it's a little ridiculous, but that's just not how human beings work. We all have different tastes in fashion and music and political opinions, whatever. We're a diverse bunch, right? And so why in the world do we do this with the web? Oh, we should always use jQuery, never use jQuery, use WordPress always, oh, never use-- why don't we just standardize on WebKit. Like just use Bootstrap, like everybody just use Bootstrap and we'll all be a lot better off. That's the big problem I have with these things. It's this sort a one-size-fits-all solution for what are ultimately much harder problems, and whenever you sort of subscribe to using Bootstrap to construct, especially like again, I'm fine with it from like a prototyping sort of get some ideas out there sort of more as a sketch pad or just sort of general prototyping pool, but if Nike, Reebok, and Adidas all launch sites using Bootstrap, there would be some substantial similarities, and that's sort of the last thing they want. And if there aren't those substantial similarities, it's because they fought against the framework that they signed up for. So these UI frameworks sort of give us the answers. Here is what your buttons look like. Here's what your job downs look like, and really at the end of the day that might not be what you need. These things provide you a lot of stuff, sometimes too much stuff, and so now all of a sudden the users have to incur all these extra downloads even though you're not actually using the stuff. On the flip side of that, a lot of times they don't go far enough. You're still going to find yourself having to write your own sort of custom components and all that good stuff. How do you work this stuff in with existing sites, and then lastly, and this is a really big one, you're subscribing to someone else's naming, structure, style, whatever conventions.
And for whatever reason web designers care about semantics and words and how we structure things, and for me that's sort of a non-starter. It's like I'm not going to sign up for something that requires me doing grid, grid item, grid hide, small, medium stand, for, like. That to me is obnoxious, but again, that's just me. So I think that these things are powerful, but they sort of have their limitations. So Dave Rupert sort of nailed this. He worked on the responsive redesign of of their home page, and he was talking about the deliverables they're giving their clients. And he sort of boiled it down into this. It's like tiny bootstraps for every client. And he says, that these responsive deliverables should look a lot like fully-functioning Bootstrap-style systems that are custom tailored to fit your client's needs, your organization's needs, and I think that that's exactly what we need to be doing. And that's what's sort of given rise to this notion of sort of a front-end style guide or a pattern library.
Anna Debenham is very, I would say like the world authority on this type of thinking and actually working with Sid for Code for America, they released their style guide open to the world. And so Anna has done a lot of thinking about this. I highly recommend you read her book. It's wonderful, and she talks about the various benefits of creating a front-end style guide or pattern library.
It makes things easier to test. You're able to sort of list everything out and sort of see things sort of chunked out in their own components, establishes a better workflow between you and all the different disciplines working on this project. It helps you create a shared vocabulary so you're all speaking the same language, and of course it becomes this useful reference to keep coming back to as you need to maintain or extend your existing interface.
These are wonderful, and she actually has done a really great job at sort of keeping track of all of the sort of style guys that are out there in the open, which is wonderful. And there have been the rise of actually a bunch of tools for you to create your own pattern library, your own sort of style guide on your own. This is Pears from Dan Cederholm. It's like a custom WordPress theme that you can enter in your HTML and CSS sort of styles. This one's from Brett Jankord called "Style Guide Boilerplate," and that's all on GitHub. And like here's our colors. Here's our types, et cetera, et cetera. Jeremy Keith has Pattern Primer. Andy Clarke has one called Rock Hammer using Hammer for Mac. Paul Robert Lloyd has one called Barebones.
And whenever you crack these things open, it's like here's our H1. Here is our H2. Here's our H3. Here's what a paragraph looks like. Here's what a small text looks like. Here's what a horizontal list looks like. Here's what a vertical sort of tab list looks like. Here is what our form fields look like. Here's what the little asterisk looks like. Here's what the instructions look like. All of this is fantastic. And so I just mentioned Code for America's style guide, which is just absolutely phenomenal work. This was just released in the last what, month or something. It's just a really, really amazing stuff. There's other big samples out in the wild. MailChimp has a really phenomenal style guide and pattern library that they released. Yelp just released theirs, made a nice reference to Atomic Design. But it actually really started with-- has anybody seen the Starbucks style guide? Yeah. Awesome. Right? And so they were sort of the first people to really release this stuff where basically they went responsive about two years ago, and with it, whenever they launched their site, they also sort of released their pattern library.
And so inside their pattern library, they have things like this, blocks three up. Here is this list of sort of three blocks and you're able to see how it responds and reacts in different environments. Here's a featured list with a thumbnail and a title and an excerpt and that's just the sort of repeatable pattern that they're going to use throughout their interface.
Here is, what our the tables look like. Here's a relatively simple one that would be able to be squished nice and easily, but then wow there's one with a bunch more columns, and here's how we're solving that responsibly.
I love these. I think that these are absolutely amazing if you're working on one yourself, I highly encourage you share it with the world. We need more examples of this to sort of move this kind of thinking forward. But hands down, back to what Dave was talking about this sort of tiny Bootstrap, this sort of custom-tailored tool kit that's specific to your organization is I think very much the way we need to be thinking about this. But for all the sort of benefits these things provide, there's a lot of problems with them. One, they're really hard to make. They take time, and I don't know about you, but I'm not going in to work every day and going, ooh, what am I going to do today? We're all under the gun. We're all trying to launch projects. We're all trying to in a do our work. And so to say like, OK, well I'm trying to get this thing out the door. We're already behind schedule. I would love to be able to make one of these, but very often it's sort of treated as this auxiliary project where it's like, oh, yeah. Like in addition to the actual real thing, we'll be making this other thing and so that adds to the time. They're often too abstract. You don't really see how these things get used. You don't see these things in context. You don't see sort of how these basic LEGO blocks like all sort of combine together to form the final interface. Oftentimes, they're only seen as a designer/developer tool or designer or developer tool. Yes, they benefit designers and developers most firsthand, but why shouldn't your clients see this? Why shouldn't the people running your project see this stuff and appreciate the fact that we're actually trying to create a really robust system rather than just this handful of pages. Very often they're just sort of created after the fact. Once a project launches, then you go back through and sort of cherry pick the patterns that you use. They're often only incomplete in serving present use cases. So maybe your organization doesn't do a lot of video content right now, but maybe one day in the future you do and you sort of painted yourself into a corner because you haven't addressed that stuff right out of the gate. And then the last thing and this is the thing that I've spent a lot of time on is that at the end of the day, a lot of these things are just sort of like a spray of modules, just sort of like a loosely-categorized cluster of components, and that's sort of what I set out to solve. And in thinking about this long and hard, I came up with this sort of design methodologies then calling it Atomic Design. So whenever I was thinking about this stuff-- this is weird slide. Sorry. My high school chemistry teacher looked exactly like Wilford Brimley. I could not find a picture of my high school chemistry teacher, so this is him. But I kept coming back to this as I was like well, surely there are parallels in other places. Surely we're not alone in this, this need to sort of have a more sound sort of system in place. And I kept coming back to chemistry.
And in my high school chemistry class, we had to do all these chemical equations and work with atoms and molecules and all that, and I actually really loved that stuff. But really in the natural world, what we're getting at, we have this sort of finite set of atomic elements that make up our universe.
So we have things like hydrogen and oxygen, and they're unique. They have their own properties, and then they combine together to form a water molecule, and that water molecule has its own properties. Those molecules combine together even further to form a more complex molecule. Those molecules keep combining in eventually we get up to sort of simple organisms. Those organisms keep combining for more complex organisms like a person. Fun fact, this was on a Google Image search for people. This guy showed up. I'm like, that's very accurate. This like represents humanity very, very well. Dude in beret and windbreaker and reflective drop shadow. This is perfect.
But all-- I kept him in there-- all the known matter in the universe is comprised of this finite set of atomic elements. We have that too. This is a guy named Josh Duck, and he put together the periodic table of HTML elements, which I thought was a really clever. So here's all of your sort of table elements. Here's all of your sort of text-level elements. Here's all of our form elements and stuff like that. I mean, that's super clever. And so because we're working with the same sort of finite set of elements, we can apply that same sort of process as what happens in the natural world to our interfaces. And so that's what Atomic Design is, is the sort of series of five steps to construct a robust design interface system. So let's start with atoms. So like I mentioned, again, in the natural world, we have these things. They have their own properties. Oxygen is different than hydrogen, and that's sort of how our HTML tags are. We have all these different tags, and we have something like a label, and we have something like an input, and we have something like a button, and those are sort of our three different kinds of atoms. And again, they have their properties, but they're also a bit too abstract to be useful on their own. You sort of click a button that's floating around in space and doesn't do anything. But this is sort of what we see a lot in our different pattern libraries, like here's our headers, and here's our H1 through H6. Here's our image tags and whatever.
Here's our form fields. Even more abstract things like here's our color pallet. Here's our font stack that we're using, even invisible things like here is our fade animations and stuff like that. Again, that's something if you're working on a large-scale project and stuff even those like Invisible elements should be consistent and cohesive throughout the entire interface.
So then we start to combine again, these atoms together to form a molecule, which takes on its own unique properties. So we have our label. We have our input atom. We have our button atom and we combine those together to form a search form molecule. So now you have this little sort of combination, this little cluster of interface that does something.
Now all of a sudden clicking that button does something. It submits the form. All of a sudden, that label now has new meaning. The same way that a molecule takes on new properties. Whenever you combine them together, this is what happens with interface.
So now we have these sort of little clusters, these simple sort of collections of atoms and then we take it a step further. So now we could take your search for molecule and we could put it into the context of a header organism. And that header organism might be comprised of a logo atom, a primary navigation molecule, a search form molecule, whatever.
We see this so all the time. You go to any website and there is this header and it contains some stuff, different kinds of stuff. So sometimes there's images. Sometimes there's lists. Sometimes there's icons. Sometimes there's forms, whatever. But these things serve as the sort of stand alone chunk of interface that's built for reuse and is included in the case of the header globally.
And so sometimes these organisms are comprised of a bunch of different kinds of atoms and molecules and stuff like that like a header, or it might just be comprised of the same molecule repeated over and over and over again. So you might have a tweet list organism and it's comprised of the same tweet molecule repeated over and over and over again. So that's what we're getting at with organisms, but we're still sort of not really a page-level stuff just yet. We sort of have these relatively complex components. And so here is where the fun analogy ends, a little metaphor that we put together because as it turns out, you don't want your clients to think you're bat shit crazy. Trust me, I tried. It doesn't work. You can't carry the analogy through. Because at the end of the day you're building a web interface, so you sort of eventually need to start speaking a language that your clients are going to understand, that your colleagues are going to understand. So that's why we sort of to depart from the atoms, molecules, whatever and get into things like templates and pages, things that our clients can understand.
So at the template level, now we have these organisms, these sort of standalone chunks of interface, and now we take this a step further and we put the header organism into the context of a page. And so the big thing to understand about templates is what the templates are meant to do are to focus on the content structure, not necessarily the actual real content, but the content structure.
Mark Bolton talks about this idea. He was sort of defending the lorem ipsum of FPO sort of images and stuff like that, and I agree with him, whereas like whenever we talk about content-first design, we're not actually saying, client, I am going to sit on my but until you deliver me Word documents with all your copy and here's all of our images and all this stuff. It's only once I have the content that I could start designing the site. That just doesn't happen. So what Mark is talking about is that you need to know not necessarily what the final content is, but rather what the content structure is. How long are these headlines? What are the image dimensions of those things? What video formats are we using? What types of information are we trying to get from this form and so on? And so that's what that template level does is focuses on that sort of content structure.
And then lastly, we get up to page level. And the page level, so now we have these templates focused on the content structure. It's very much like the sort of scaffolding for this. And at the page level, is where we actually pour in the real representative content. Now obviously, this is an important step in the process because this is ultimately what the end user is going to see, and so as a result, this is where a lot of the design process takes place. You're looking at what's going to become the final product.
And so this step is essential because designing these sort of molecules and organisms sort of in isolation is all well and good, but how do you actually know that they all fit together properly? How do you know that this is how these building blocks should be? You really need to see it in its final context in order to appreciate the underlying system. So this page level is where you sort of validate or invalidate your design system. You test out the resiliency of this. You say, oh, does this headline wrap onto seven lines? If so we should probably take care of that, so on. You solve those problems at a more atomic level, but this is sort of where you review the effectiveness of your system. The page level is also a very interesting place because it allows us to do test variations of the same template. So for example, you might have a home page and then you might have another instance of the home page, still the same template, but now you need to add in an extra little alert that says there's a tornado warning or something. It's still the same template but it's a variation of that sort of content structure.
Then again, back to Mark Bolton where he's talking about this relationship between content and design that you really can't just design containers then pour in the content. What content actually goes into these containers very much influences the underlying system and they both sort of depend on each other in order to create an effective design. So that's Atomic Design, these sort of five steps, these sort of five each important steps that go into this. By the way, it's not like a linear sort of process like, oh, we start with our atoms, then our molecules, then our whatever. All of this is sort of happening concurrently. The biggest advantage that I've seen in working this way for the past year and a half now is this ability to sort of traverse between abstract and concrete, to be able to see all of your LEGO bricks spread out on the dining room table but then to be able to sort of step through each stage of the process and see how those things are being combined to ultimately form the final experience.
I've also found that clients don't really give a shit about molecules and atoms and things like that and understandably so, but at the same time, I do think that they need to be exposed to this type of thinking to again appreciate and understand what it is you're doing for them, that we're not just trying to shovel over a handful of page templates but rather we're thinking long and hard about crafting you an interface system that you're going to be able to live with and grow with for years to come, hopefully.
But at the same time, the creators are the ones that have to worry about the sort of underlying guts of all of this. and what I've also found is that, again, atoms are terribly useful on their own, like here's our H1 through H6. Cool. All right. It's a nice sort of reference to come back to from time to time, but it's actually not really where you're building. The real build process comes in sort of stitching these molecules, organisms, and templates together.
And then lastly like the pages, again, are where you review with your team. You sort of say is this system working, yes or no, and if not then go back and sort of solve that problem at the sort of molecular level or whatever.
So that's Atomic Design. I like it because it is a very sort of deliberate methodology. It is not just like a handful of components. It's not just a spray of modules or whatever. It's this very sort of deliberate process that actually holds up pretty well. Again, we're able to traverse between abstract and concrete.
And why we're doing this in the first place, of course, is to establish consistency and cohesion across this entire experience, and sort of the bigger the organization the more need for consistency and cohesion there is. And very often that's the stuff that results in these like sort of 7,000-button styles and stuff like that, and that's what we're trying to avoid. That's why we're creating these systems in the first place. We're assembling things rather than deconstructing them later. Again, so we're starting with the system rather than sort of building a bunch of pages and then just sort of cherry picking patterns after the fact. So this type of thinking isn't new. I mean, as much as I'd love to be like, oh, this was all out of the old noggin, not really. Andy Clarke actually even wrote a chapter of a book called "Designing Atoms in Elements" for Smashing Magazine, but because it was in a book, I didn't read it. But yeah, people have been talking about this general sort of notion for quite some time. There's actually a lot of really sort of related things like CSS things, BIM architecture, object oriented CSS, MAX, all that sort of stuff that's sort of your architecting your CSS in little modules and stuff like that. But even things like YUI and jQuery UI and these things have been around for years, have been thinking this way. Here's your accordion. Here's your light box. Here's your panels. Here's your whatever.
Like this stuff has been around forever. But what I'd say is what Atomic Design does is sort of take it one step further, I think, especially when it comes to sort of making a differentiation between sort of more simple components, what I call molecules, and more complex components, which are what I call organisms. So that's that. So that's the sort of philosophy. That's the methodology. In order to actually make this come to life, we created a tool called Pattern Lab. And I thankfully got this guy on board, Dave Olsen, who runs the web department down West Virginia University to help me out with this, and I've been doing something like this on my own sort of a crude, rudimentary thing with my lousy programming skills, but Dave is a good programmer. I am a bad programmer.
And I was like hey, Dave, how do you think about joining up on this? And so he took my crappy stuff and totally rewrote it in the course of like two days, and he was like, here it is. It's way better now, and so I'm really, really happy that he's on board with it. So what Pattern Lab is ultimately it's a design system builder. It's a way to sort of stitch all of these atoms and molecules and organisms and templates and pages sort of together all under one roof. It uses well, I'll talk about how it works a little bit, but it uses PHP in the background to just sort of like stitch these things together. What it's meant to be ultimately is a comprehensive custom component library, that tiny bootstrap-style system like Dave Rupert was talking about that ultimately in what I've been using it for has been like our final deliverable. It's like here's everything. Here's your deliverable.
And it provides some patterns to get started with, but, again, the ideas were not sort of giving you the answers, so the idea is for you to rip the guts out of all of this and only define the patterns that you're going to use. It provides a viewport resizer, which we'll talk about, and it also provides some annotation tools, which we'll talk about. Now, what Pattern Lab isn't though is it's not Bootstrap. It's not Foundation by ZURB. We don't make any assumptions on sort of how things should look or how things should be structured, how you write your code or anything like that. Again, it's actually sort it intentionally badly designed, at least the guts of it is, just so nobody actually goes out and they're like, oh, here's my new site. I just put these things together.
No, the idea is for you to replace that with your very own style, structure, JavaScript, all that stuff. We make no assumptions. You can include jQuery, don't include jQuery. If you want to use SaaS for your CSS, go for it. If you don't want to use SaaS, go for it, want to write Plain Jane CSS, go for it, want to name things however you want, awesome. Cool. We're not going to judge you. And then lastly, there it's not really incredibly rigid. It's very flexible. If you don't like the whole Atomic Design metaphor, whatever, you can rip all that out and call things however you want. So it's really nice in that respect. And then also this is sort of I struggled defining what this thing is because it's not just a pattern library.
It also is like your final product, your final sort of front-end code, but it's also not like a production-ready static site generator like something like Jekyll or like some other thing that you just FTP it and you have a website. So it's not like a CMS or anything like that. It's just sort of a tool. So here's what it looks like. It is, again, vanilla. I showed this earlier, but again, you have your colors. You have your font stacks. You have your animations and things like that, and the idea is for you to go through and customize and use your own colors and stuff like that. So at its core is the site builder to again, sort of stitch these things together, and so it looks a little something like this. I don't know if you can see. The contrasts isn't all that good, but we have atoms, molecules, organisms, templates, and pages. And you could go in to each one of these, and there's a little menu in so you can look at-- here's our different lists and here's our different whatever. Here's our layout. Here's different blocks and whatever you want to call things. Here's basic forms, stuff like that. So we sort of start with the atoms, and again, we're sort of looking at this, and as you scroll down, you can see here is our headings. Here's paragraphs, block quotes, a bunch of inline text elements like superscript and subscript, different lists, different image types. Here's our logo. Here's a big hero image. Here's a square image. Here's an avatar. Here's our icons. Here's our fab icons. Here's all of our different form fields and form styles and stuff like that, buttons, tables, and so on and so forth. So the idea is to sort of lay all those atoms out on the table, and I'll talk about a project I did with TechCrunch a little later, but this is sort of what we are doing for this, and this is what our final Pattern Lab looked like for TechCrunch, so it's like OK. Here's all of the different input types we're using. Here's what we are using. Primarily, TechCrunch is a site to read on, so we have lots of text-level elements like things like block quotes, and things like pull quotes, and things like lots of text elements. And then whenever you get to the molecule level, this is an example of a molecule, a big hero image, a title, and an excerpt, pretty common interface pattern.
And then here's like a variation of it. I'm calling this like an inset block or whatever. Again, name things however you want. That's just what I called it, where the text is sort of overlaying on top of the image. And so the way we're doing this, the way we're sort of putting these things together is using a tool called mustache.
I'm about to show you code, so I felt like I needed to get a little chuckle out of you because things are going to get a little rough. As I promised you it's not that bad code, but I do always feel bad just because code talk makes me weird. I don't know. But we're using something called mustache that just sort of stitch these atoms and molecules and organisms together. So this is what that inset block looks like. This is the HTML for that, and for that big hero image, I'm including this image in here, so that little highlighted line is like bracket, bracket, that's mustache, and then the little greater than sign that says include. And so what I'm including is atoms and then I gave the atom a name of img-landscape-4x3.
And so what that does whenever Pattern Lab does its thing, it's sort of sucks in that image and puts it in that place. And so now you have this nice little sort of self-contained chunk of interface, which we can now do that same exact thing to include that little block inside a more complex organism or template or whatever.
And so this is what we did for a project for TechCrunch where we had like all these little sort of molecules. Here's a newsletter sign-up form. Here's our global search. We were using a third party for blog comments, so we dropped that in there. We add basic contact forms, so again, sort of relatively simple chunks of interface, relatively simple chunks of functionality.
So at the organism level, and again, back to TechCrunch, this is where we have our masthead, and it has a bunch of stuff in it. And this is sort of what the end product looks like, and we'll talk about that in a bit. But if you look at sort of what this is comprised of, we have a logo. We have a header add. We have this sort of tip thing. We have a primary navigation, some social navigation because you don't want to forget that one, and then we have our search bar. And so if we look at sort of how that's structured inside of Pattern Lab, so here's our header organism, and so there is our header add. There's or logo. There's our primary navigation. There's our search, and there's our social navigation. So all of those things sort of collectively get sucked up and referred to as this header, and now we can include this in all of our templates.
So at the template level, here's like an example. This is on Pattern Lab's site just like, again, very bare bones sort of example of what a full template looks like whenever we get into the guts of that. So here's our header and here's our footer and that sort of forms the outer bond of the hamburger and everything inside of it is all the guts. And so we're including an article body, our social share buttons, our comments, related posts, and recent tweets. So those are all of our little sort of modules that we're including.
So the other project which we'll talk about the process with in a bit, this is what our sort of template look like for Entertainment Weekly's homepage. Again, we're focusing on the content structure. What's the dimensions of that image? What's this sort of headline length, and just sort of having this placeholder stuff in here. And now what we're doing at the page level, again, is sort of replacing that FPO stuff, that content structure with real representative content. And so just another quick example from the Pattern Lab site is just like, OK, so here's our structure and then we pour in real-- we replace it with real representative content. And the way we're doing this and so you could sort of see you're able to sort of wrap things around this little pound sign hero and then slash hero is like start hero, end hero, and what that does is it's a little hook. So now we could target hero, and we could target these things called touts. And what we're doing is the way we're sort of replacing that FPO content, that lorem ipsum, whatever with real actual content is using JSON. And so for those of you that aren't developers, this might look a little scary to you, but I just finished up a project, and I had our information architects, all of our sort of interaction designers and the project leads actually writing this stuff, which is awesome.
Because here's what happens as a developer. It's hey, Brad, you spelled this wrong. Hey, Brad, we got an updated copy deck. Go into markup and change this stuff, like that's not coding. That's content entry. That's data entry. I've got bigger fish to fry, right? And so this happens. It's like death by a million paper cuts. As a developer, it's like please just leave me alone. And so by sort of creating this separation between our structure, our HTML and the actual data that goes inside of it, the content that you're pouring inside of it, I was able to get the other people who are responsible for the content to go in and make all the copy edits and swap out images and stuff like that. So this was really, really cool. So it took like 15 minutes of the designers being uncomfortable to get their head around this, so it's pretty easy. So if we go through, we're saying hero like I had last time, and then we're saying, OK, this is the image we're using, and I want to swap it out with this jpeg of mountains. We're going to give a different Alt text called mountains, and we're going to give the headline a different headline of Top 10 Mountain Ranges. Now, with touts, if you go through, I'm only including this thing once, and what you can do with mustache is sort of loop through. So for however many touts you define, in our case it was three, it will go through and sort of replace, inject that for every little thing it finds. And so I'm able to go through and again, swap out the images, swap out the head lines and call it a day. So back to our sort of our Entertainment Weekly example, so here was our template for that, and then here was the actual real page. This is what they ended up launching with. And so if you put them side by side, you could sort of see what's going on. All right. So we have like our general shell and our general sort of content structure, but then all the dynamic bits are replaced with real actual content.
And again, this page level is where we're saying how long are these headlines? Do they ever wrap onto like four lines and sort of break the design? If so, then we're going to need to either A, have a conversation with their editorial staff, or B, fixed fix the design. So it's been really, really nice to sort of work this way and sort of construct these experiences with these sort of five different steps. So in addition to sort of being able to stitch all these things together, I've also baked in a viewpoint resizer. Because here's what my big issue that I see stuff like this all the time and a lot of web design tutorials and an even organizations sort of best practices or whatever, and they're like, these are our break points, 320 pixels, or an iPhone in Portrait mode, 480 pixels, an iPhone in Landscape mode, 768 pixels, or an iPad in Portrait mode, 824, or an iPad in Landscape mode or in desktop.
The fold. Oh god, the fold. Miserable conversation to have. And the problem is is that I saw a lot of tools that were coming out that it's like, look at what your site looks like on an iPhone and so on and so forth, but that's not what we should be doing. So I created a tool called ish that is a tool that's meant to sort of help people consider the entire resolution spectrum rather than just like the sort of fixed buckets of devices. And so we built that ish tool into Pattern Lab, and why it's called ish is because whenever you click on Small, it will resize it to a small ish viewport.
There's a range. Whenever you click Medium, it's a medium ish range. And the cool thing about this is a TechCrunch client didn't know that you've got a different value every time until about two weeks before we were done with the project. So I don't really see this so much as a developer tool but rather a client education tool and a teammate education tool so that we're not just sort of fixated on today's popular device sizes, but rather really considering the entire resolution spectrum. Because as it turns out, Samsung craps out a new device with a different form factor like every 30 seconds. So it's like really we can't like bet the farm on these sort of popular device dimensions always being what people are using. So in addition to that, there's like a nice little resize handler, and what's really cool about this actually, back to sort of more being a client or a designer tool rather than like sort of a developer tool, is that our clients and my teammates are able to give way more accurate feedback. So we have like little sort of numbers so you can see how big the viewport is. So the designer could be like ah, at exactly 368 pixels, this thing drops beneath this thing. We need to fix that. That's better than, ooh, here's a screen shot. Fix it. They're able to sort of give more detailed descriptions, more helpful feedback for me. That's been really nice. We also have like a pixel, the em converter sort of built right in again, so you can see sort of what the viewport is and sort of get granular with everything. And then there's the crowd favorite Disco mode, which bounces your screen around like crazy. And the clients love it. They're like, oh, look at it go. But again, like this is a very powerful client education tool where basically what we're doing is helping them appreciate like, yes, we're trying to construct a system, we're trying to construct an interface that's going to look and function great no matter what device size your pour it into, and that goes a long way. And so notice we're doing like small, medium, and large and we're doing things like in Disco mode to really sort of drive those point home, get them thinking about being more device agnostic.
So in addition to viewport resizer, we have annotation tools. Now, this is really, really cool. So what ends up happening and a lot of you people are probably responsible for this, you're not making some giant ass PDF that gets crumpled up and thrown away. And there's a lot of good thinking that goes in there, lots of really robust annotations and sort of usage and all this stuff. But because it remains locked up in this sort of abstraction, it becomes less useful. So what we're doing with Pattern Lab is we're actually giving the ability to sort of bake the annotations right into the thing itself. So here's what that looks like. So you come up in Menu, you switch on annotations, and a little number pops up by all the elements that have annotations. And you're able to tap on each of the elements, and I'll jump you down through to each annotation. But what's awesome about this is you're able to be like our logo is an SBG file which then provides a ping fallback, blah, blah, blah. At its max, it's this large, and here's how much it weighs or whatever annotations you want to provide.
Here's how the navigation collapses, here's like the method to that madness, all that stuff. And by sort of baking it right into the final product especially at like hand off so I've worked on now four projects where we've handed off this stuff to our clients, and by sort of providing them all the annotations, they're able to have this stuff yes for integration into a CMS now, but hopefully, for years to come. So here's our thinking. Here's what went into that. Here's why this is the way it is. And then we also have sort of like a list mode where ever you could sort of view all the patterns in a list. So this is for a project I just delivered, and we're like here's our fonts. They're being served up by Typekit. We're using these weights. Be careful about adding too many weights. Here's our fades. We're using a 0.3-second animation, blah, blah, blah, all that stuff. So it's, again, really helpful. It's this nice sort of reference to keep coming back to. And again, this is something that the designers who I was working with were able to do. It's just another JSON file, and you just say, OK, here's what element I want to target, here's what title I want to give it, and here's the annotation I want to put on it. So it's been really, really nice. And then the last feature that I'd say s like really, really important for Pattern Lab and something that I don't see any other sort of pattern library solution or whatever doing is this concept of lineage. So again, I was mentioning earlier about how frustrating it is because you sort of see in a lot of pattern libraries just sort of things floating around in space. You don't really get a sense of like here's how these things are actually being used. Here is where these things are being actually used. And so that's what Pattern Lab is doing. So if you crack open the code view on this, so this is the home page template, and I can sort of drill into a little bit more. It says the template's home page contains the following patterns, organisms, header, molecules, alert, the block hero, inset, media block, recent tweets, footer, and you could click on those and sort of drill into each of those patterns.
And then it also says here's where this pattern is being used. Here's where this template is being used. It's being used in the home page page, and it's used in sort of a variation of that home page during like a tornado warning or whatever. So you're able to sort of step through and see here's where tabs are being used, and if we were to make a change to tabs, here's what pages we're going to have to test. Here's where we're going to have to QA. So you're able to sort of see how global or focused any particular pattern is, and that for me has just been amazing so far as a relatively new feature, but something I'm really excited about. And then the last thing is this idea of sort of pattern status, which is something that Jason Grigsby's colleague actually was asking for where you could basically say, yeah, the header is done or this is still work in progress or whatever, and that will sort of propagate throughout. So then you're able to sort of look at the home page. So your boss says, how is the homepage coming, and we're like it's pretty good, but here's the things that still need done for it, which is pretty interesting. And so you could see it's like the state of this is in review, which is cool. Then it provides a bunch of other stuff. You can sort of see the code and see the mustache views and stuff like that. Auto-refresh, if you wanted to every time you save it or reload the browser. Page follow, you could connect different devices to it and have them all update at the same time. And in the future, what we're trying to do is build sort of the ability for people to build plug-ins into it and sort of extend it a bit further. Tim [? Cablic ?] who does a lot of stuff with performance, he actually hacked this thing. He hacked Pattern Lab so that in the toolbar if the page takes too long to load so you could set a performance budget, you're like, OK, our page can never be more than like 500K. And if it's more than 500K, it will show up bright red. And so, again, like what that does is sort of helps everyone on the project prioritize performance, which I think is super, super clever. So that's what we're trying to do is like build this opportunity to sort of extend it. So I like Pattern Lab because what it serves as is this sort of watering hole for the entire project. We spend all of our time in this thing, and why I like it because it's the living, breathing product. It's the living, breathing interface. It is in a Photoshop document. It isn't some PDF. It isn't some Excel spreadsheet.
And what we're able to do in sort of creating this experience is we're able to sort of involved more disciplines in the creation of the final product, which I love. Again, we can easily traverse between abstract and concrete. You can name things however you want. We're starting with this system. We're thinking systematically right out of the gate versus sort of deconstructing things afterwards.
With the viewport resizer, we're encouraging flexibility. It's extensible and scalable. You're able to document your interface. You're able to sort of see that pattern lineage, which I think is super, super helpful.
So if you want to check it out, it's in I should have mentioned that this isn't like some thing for sale, like I'm not a salesman. It's just an open source project, and don't even feel like you need to use it or anything like that. Like a lot of people I work with, they have their own custom things going and that's cool too. I think that just sort of walking you through these things, hopefully, some of the principles or ideas or whatever even you sort of adopt some of those, that's a win in my book. So don't feel like it's not required. I'm not saying everybody got out use this or I'll find you. And if anything goes wrong, if you do play around with it, it's not my fault. Blame Dave. So that's that. So I through this question out here a while ago with Luke [? Sapuller. ?] I said what's the hardest aspect of responsive web design? Is it the actual design and the development part, or is it the process and the people and the workflow and dealing with all that? And overwhelmingly and perhaps unsurprisingly, it's the people. One of my favorite quotes of all time this is Mark Bolton. He says the web design process is weird and complicated because it involves people who are weird and complicated. I'm like that's a true statement there. So yeah, we've been thinking about sort of how to evolve the modern web design process for quite some time, and I got the opportunity to work with some other people who have been also sort of wrestling internally with this issue of how do we update our process. What does the responsive design workflow look like? And all these people have been doing this great work, and we had an opportunity to come together. So I was able to work with Jennifer Brook who used to do all the mobile design stuff at The New York Times, Jonathan Stark who's doing the JavaScript for our projects and he's written a couple books, Josh Clark who sort of ran the show and he's written Tapworthy and designing for touch, and all this other stuff, this really, really great stuff, and then Dan Mall who has his own design studio based out of Philadelphia.
And so we were able to sort of come together, and we had these opportunities to work on this project to really focus on sort of the process in our workflow. And so one of the projects we worked on as I sort of mentioned earlier was a mobile-responsive site for Entertainment Weekly and a redesign of the technology blog TechCrunch.
So what I'm going to do is just sort of walk through how our process worked, sort of some of the things that we did to help our clients understand and move things along. One of the biggest things we had to do is really reset people's expectations. Does this look familiar to you? Let's review our website. Bill is going to go to the printer and print out a copy and come back and pass it around the table, and we're all going to take a look at the website.
This is a lie. This is wrong. Dan who I was working with, he says, "As an industry, we sell websites like paintings. Instead we should be selling beautiful and easy access to content, agnostic of device, screen size, or context." I couldn't agree anymore with that. It's so spot on. We have to sort of get away from this idea sort of coming out. Oh, we just finished our kick off meeting and oh, here is a bunch of comps like how about you choose them. It's like that's just not a good process.
And the other thing we have to get away from is this idea of the waterfall. I don't know if you could tell, but this dude's wearing business casual to fall down a waterfall, so he at least dressed up for his demise. But yes, so historically, this is the way we've been used to doing things. We do our information architecture, all of our interaction design, or UX design, whatever you want to call it, whatever you people do. I'm just kidding. I'm just joking. And then we make a 90-page annotated PDF with all these really long text passages, call me Ishmael, and like a chapter of a book as an annotation. And then we throw that over the fence to the visual designers who color in the lines and make it look pretty, add in all sorts of visual flourishes. And then the visual designer walks down into the cave, slips the comps underneath the cave door, and says code this up. Make it work. And that just can't be the way we work anymore. I wrote a post called "Development is Design," and really talking about the challenges of sort of front-end developers. There's very much sort of an identity crisis with front-end developers, and I'm in that camp. Because I'm not a developer. But because I work in code, HTML and CSS, they're like, oh, you're a code person. Go there and sit with the Ruby people. Whip us up some Ruby gems, and I'm like write a submittal ware. I'm like yes, sort of not what I do. I like making things pretty and working.
My mom's an art teacher. Leave me alone. But there's the sort of fundamental-- like I'm a designer. I actually call myself a front-end designer because I don't like the word developer because people assume you're a programmer, or computer scientist, or something, like I don't have a CS background or anything like that. What the problem is though I see is that we have these sort of even entire design agencies with not a front-end person on staff. We sort of ship that out to some IT team that does all the coding. So just for fun, raise your hand if you work in a place where the designers and developers sit next to each other. That's a good number. Good for you. Raise your hand if they sit on the same floor as you. OK. Raise your hand if they sit on different floors, designers and developers or IT in marketing, like whatever the hell you want to call it. The bigger the organization, the weirder it gets. How about in different buildings? Different States? Different countries?
This is a big problem because what development is, what front-end development is, is constructing an interface, is designing an interface. It is a part of the design process. I am no less a designer than the person sort of sketching out these ideas in the first place, so we need to be integrated into the process. So instead of this, we need something more like this, which can be very challenging, especially if the developers are in India or in a different country or whatever.
But it's not all like this. This is a bit skewed. It's not that everybody's doing everything all the time. In our experience, working this way, it's been a little bit more like this where some people are burning hot initially. So Jennifer was creating a bunch of sketches and content strategies and all sorts of stuff like right out once our kickoff meeting was done, but that didn't mean that we couldn't get started or that Dan couldn't get started on doing some visual design explorations or that I can get started to setting up Pattern Lab and setting up some initial stuff. So that's what we'll talk about now is all that stuff that we sort of did like to write after he kicked off, we are able to sort of take this stuff and run with it. One of the best things you can do is to just start very low phi. Start with a sketch. I love showing his photo. My friend is a preschool teacher in the Washington DC area, and she had one of her students ask, how do you make a website? And she goes, well, as it turns out, I have a friend that makes websites for a living, so they did a FaceTime call and this four-year-old girl asked, how you make a website? I said, well, one of the best things you could do is just sort of draw a picture of what you might want that website to look like and what you want to go on it. And so a couple hours later, I get this picture message. And I'm like this four-year-old girl is better than 90% of the designers I've ever worked with. Look at this nice coloration indicating the active states and where you're at in the slide show, clear labeling. Here's the homepage, again, more active states, button styles that are more consistent than my banks. It's incredible, right? And I just love this because just in looking at this four-year-old girl sketch, you have a very good idea of what this site is, what it's supposed to do, and all that, and not too much time to generate something like this. And so again, its getting away from the sort of Hi-Fi wire frames Hi-Fi comps and stuff like that, at least right out of the gate, and getting more into something that's just a lot more sort of Lo-Fi. So this is Jennifer's IA stuff for TechCrunch where she is basically just blocking out little patterns. So she's like, OK, here's what our featured island is going to look like. Here's a place where we're going to feature some stuff. Here is our river list. Here is like a list of posts, and that's just what she was calling it. And here's a river grid island. It will be a grid of stuff. And so that's the sort of blocky-level sketching and all the while I was showing you these things earlier, I was able to start sketching and start sort of structuring these things, just these basic atoms and molecules, just sort of getting things going, things like ads. We knew we were going to have ads on our site, and it's a big sort of thorn in our side because we're creating this nice sort of squishy responsive experience and all these ads are fixed width. And so right out of the gate, I can sort of get going and start to sort of plunk in these placeholder ads. And then all the while Dan was able to start get going with style tiles, and thankfully for the Entertainment Weekly project, because we are doing the mobile site, the desktop team had already done a lot of style tile exploration. So we are able to get this from them, and work that into our own design process.
And one of the other things that we did that I thought was really interesting, Dan uses-- anybody know a tool called Typecast, and you're able to sort of stitch things together like web fonts and sort of pair them together and demo them? And so Dan started with typography and would show this to clients where he just sort of picked some combinations and they would-- that's funny. Usually there's more. Dark fade. But yeah, so you're able to sort of picked these things, a bunch of different types combinations and then we would facilitate a conversation with the client and say, oh, this is a little too blocky here. This is a bit too formal for our liking. We're a little irreverent, so this one speaks out to us and blah, blah, blah. So it's about sort of having those conversations without having to do a whole ton of work up front. And then once we had that initial direction sort of set, we were able to roll up our sleeves. So this was sort of the IA for Entertainment Weekly. We just very quickly blocking these things out. And that's one of the beauties of doing mobile-first design is that you're able to sort of just stack these things in a linear list, like here's what needs to go on the page, but because this is on top of this, this is more important than this. Whenever we sort of sketch with a bigger screen, we have the opportunity to try to put everything above the fold, and let's make like seven sidebars and stuff like that. Like this forces us to prioritize our content. And so here is some of Jennifer's sketches for the homepage. Again, it's a little featured area. Here's our list of posts. Here's some ads. Here's some whatever.
Here's our video player. The video player is up at the top with information about the show. Here's a list of episodes. Here's our editor's picks. And this is wonderful because I was able to go in and start piecing these things together.
So this is what my first pass of the home page looked like. Looks like crap, right? But that's fine because at this stage in the game all I was trying to do was just put that general infrastructure in place and that we knew that we were going to iterate and bring in, role in a lot of the aesthetics and stuff a bit later. And so once we got past this sort of style tile phase with respect to the aesthetic design, Dan went into what he calls element collages, and what element collages are are more tangible than a style tile. Style tiles are like, here might be some colors, here might be some typography treatments, and stuff like that. With element collages, it's not quite still full comp, but he's definitely starting to play with different interface elements.
And again, this comes in tandem with a conversation with a client wherever Dan is able to sort of walk them through here's why we're sort of putting these things together, here's what colors were using, and so on and so forth. And so we would sort of pick these elements and sort of riff on them for a while. Dan would do a couple of different header treatments and stuff, and then we'd show them to the client. And then we would have conversations about them and iterate on them. And all the while I'm able to start pulling that stuff into Pattern Lab. And again, here's what that sort of organism looks like. And so here's what we ended up for a header and then once we ended up in these weird states wherever we'd have the header all sort of styled and done up right, but then the rest of the page still looks like crap. It's nice and sort of gray scale and blocky. So that's how our process worked where we'd sort of go through and element by element, brick by brick, piece by piece, we would go through and remove that gray scale stuff and start replacing it with like the fully-styled stuff. And yes, there were some full comps along the way. They wanted to see what the homepage would look like and wanted to see what an article page would look like and featured article.
And that's all well and good because by the time that we started doing full comps, we had already established our system. We had already sort of gotten everybody on board with it. And so those comps we're actually more a reflection of our existing system than they were like sort of something totally new and unrealistic.
So that's sort of how we operated. This is a picture from Trent Walton who worked with Dave Rupert on the Microsoft redesign, and I just love this little image here, but that's exactly what we were doing. We would build, and would we design, and we would reflect, and then we'd sort of go back and forth and sometimes I'd be like OK, Dan, I have enough to go on, and I'd start playing around with the styles and all that. And then I'd say, ooh, like I'm really stuck at this area, and so Dan would take it, screen shot it, manipulate it in Photoshop and all that good stuff and then we'd say how about this? I'd be like, ah, that's a good solution. Then we'd just sort of go back and forth. Again, so then we'd have these like templates and pages, so here's what our pages ended up being for Entertainment Weekly. They wanted to see a home page, and they also wanted to see what a homepage would look like when they're featuring only five articles instead of 10. So again, it's just that variation in the same template.
TechCrunch on the other hand, was much more massive project, and they wanted to see what an article looked like with an embedded YouTube video in it, with a press release in it, with a slide show gallery in it, with all sorts of stuff, and so we had to do a bunch of variations of the same template. So it was a bit more complex, but it scaled very well. And so again, it's just sort of showing these things side by side. So I like in this process a lot to sort of like subtractive sculpture where you start off with this big slab a rock and then you start chipping away at it, and you do a first pass and you start extracting the shape of the human. And then you take a second pass at it and you start getting a little more closer. And then you do a third pass at it and you can definitely tell it's a human there, and eventually you get to a level where you're like, OK, now I've reached a level of detail where I could start going in and starting to detail off the face. And now I can move onto the hands, and I can move on to the feet, and you repeat that process until the sculpture is done. Only unlike subtractive sculpture, we have Control-Z. Wonderful.
So this is our process. This is our reality. I think that we have to again, challenge the status quo, challenge our current processes our workflows our tools and really evolve with them. I love this quote from Benjamin Franklin. "When you're finished changing, you're finished," and I think that that's just so especially true with respect to our industry. This is really, really hard stuff, and we have to be willing to sort of move forward.
Now, trying to be stagnant in an industry that's only 25 years old, and a medium that's only 25 years old is ridiculous. And for as hard as this is, let's face it, this is really fun. I don't know about you, but I played with a lot of LEGOs as a kid, and I don't see this as being all that much different. So there's so many things that we could be doing that are so much worse than this, and I think it's at least for pointing that out that this is really fun. These are great problems to have. And I also like saying this because right now there are 2.4 billion people with access to the web, 6 billion mobile subscriptions on the face of the Earth, and here's the trend. There are sort of two of humanity's greatest technological achievements, and we're right there smack dab in the middle trying to make it all work together. Again, I can't think of better problems to have than what the web is, where it can go, how it gets used and why it matters so much. Thanks everybody.
I think we have like 15 minutes for questions. So if you want to raise your hand and they'll sort of bounce around with some microphones if you want.
Audience Member: Hi.
Brad: Hello.
Audience Member: OK. Let me formulate this as I'm thinking, saying. I get what you're saying about like starting from scratch. So what if you're deconstructing?
Brad: So what if you have an existing product or service and site and you needed to sort of go through and make a system after the fact. Yeah. So I wrote a post if you want to Google it. It's called "Interface Inventories," but it's a technique sort of similar to content inventory for those that are familiar with that where you go through and make this giant-ass spreadsheet. It's sort of like that only instead of your content that you're documenting, you're documenting your interface elements.
So you go through and you screen shot all of your buttons and put them in a pile altogether, go through and screen shot all of your form fields and put them in a pile together, all of your different image types, all of your different whatever. Here's our carousels. Here's our accordions. Here's our tabs. Here's our whatever. Start classifying them. And what it does, one, is sort of shows you your current state of affairs, and I've done one with my bank who I hate, and they have like 75 unique button styles. And it's like that's pretty absurd. Really. So if you're starting with an existing experience, sort of take it day and do an interface inventory, screen shot everything, combine them, classify them and stuff, and what that does is that, one, documents your interface, but, two, lays the foundation for establishing your vocabulary and laying the sort of groundwork for your future style guide. So yup. Good. We covered? Oh.
Audience Member: You mentioned TechCrunch was a larger project. I'm just curious. Can you give like an estimation on the timeline from when you kicked off to when you delivered considering all of the patterns and things you had to give to give them a warm fuzzy about publishing.
Brad: Sure. TechCrunch is a bit of an anomaly because we'll say that the reason why the project took as long as it did had very little to do with our design process and more to do with sort of personalities and politics and stuff. But all in all, our TechCrunch project was about eight months. So we started working on it in January, and it launched in October.
But the Entertainment Weekly project, which granted was a little less in scope, took only like two and a half months or something like that. And I'm working on several things right now, and we just wrapped up another project, and that one took about three months, and that was actually a lot more complex than Entertainment Weekly. So at the end of the day, it's not about like the Gantt chart and here's the process that we're following and here's why it's taking as long as it is. It has everything to do with the collaboration and communication between the client and the rest of the team. Like that makes more of a difference on how long something takes than how you're actually going about it. Anybody want to call bullshit on all this? I've yet to have somebody do that, so I'd love to hear that, actually. Any other questions? Anybody struggling with design process, responsive design process, and convincing people? Yeah.
Audience Member: I'm interested to know when to involve QA team with your design, because becoming agile is like the quick, short sprint, and like they want to start kind of writing their test scenario too.
Brad: Sure.
Audience Member: And so when do you do that? When is the good time to work together?
Brad: Yeah. So when to involve QA, and one of the great things about this process from a couple of different points. One, in doing things and breaking things down into smaller components, we'd be like, OK, we're pretty done and dusted with the header, start breaking it, start writing your tests, and start doing all that stuff. They don't have to wait for the whole home page to be done in order to start testing the header functionality, if that makes sense. And so that's one of the biggest benefits of breaking things down into smaller bits. And the other sort of part to it is that this process that we're doing, we're getting into the browser as soon as humanly possible, which means you can engage them as early as you can. So as soon as you finish a molecule or organism or something that has some moving parts or whatever that needs tested, you can send that over to them to kick the tires. So this process is really conducive to involving QA a lot earlier. That's certainly been the traditional waterfall process. Yeah.
Audience Member: I had a quick question. So I work for a large organization.
Brad: Where are you?
Audience Member: I'm right here.
Brad: Sorry. You're like different. Sorry.
Audience Member: We use team site CMS, and we're starting to design responsive components and responsive pages and eventually the whole site is going to be responsive by using team sites, so I'm just wondering how we could do something like what you do with Pattern Lab. But I'm wondering because that seems like it's kind of outside of a CMS what you did.
Brad: So yes. And this comes down to a very interesting workflow question, which is, do you bake the thing into Drupal or whatever tool you're using or whatever CMS you have and design your front end in that system right out of the gate? I advise against that, and the reason being is, one, you're able to pivot a lot faster, like a lot of these things in Pattern Lab, but then other just other static prototyping tools, it's like you could do it all sort of without having to set up the databases and send all that stuff down. Two, CMS's are notoriously shitty for just screwing up your markup. And so what's great and I usually work in like in a client relationship, what we're able to do is we're able to have this sort of reference code, this production-ready, front-end code that's done in dust and QA'd and all of that stuff and we're confident in that. And then whenever they go to implement it into the CMS, they have this sort of gold standard reference.
What ends up becoming hard whenever you sort of muddy the waters and sort of putting the CMS in the front end code together, it becomes harder to pinpoint like where a problem is coming from. So we could be like, look our site is loading in like 2.1 seconds, which is great and then we put it in a CMS and now all of a sudden it's like 8 and 1/2 seconds. Something's wrong, and maybe you want to choose a different CMS. But I think as time goes on, this hypothesis I've had in my head for a while now about really decoupling the front end design with the CMS design is becoming increasingly important. And what tools like Pattern Lab do is we're able to create, yes, it's all the front end code, but with all that mustache stuff, we're able to sort of rip out all the dynamic bits. And that serves as a blueprint for the integration team where we're like here's which bits are dynamic. Here's where headlines are. Here's which classes are switched or can be switched on and off or whatever, and here's all this stuff. And we're actually writing stuff now. It's a little challenging to do, but you could actually like write basically a build step in between Pattern Lab and all the mustache stuff and the final CMS environment. So you basically would convert mustache into whatever language your CMS uses, and that's a bit of a manual process and a bit hard just because some people might have PHP-based things. Other people might be using .NET or Ruby or whatever.
But the end of the day, what we're doing is we're making sure that the front end is working great and also sort of hinting at here's which areas need to be dynamic. Here's where a loop is. Here's where all that stuff is. So yeah, I would decouple them if you can.
Audience Member: So I work on an application rather than on content, and we have Bootstrap on the back end, and our developers use Visual Studio. We have a style guide, which the existence of it was driven by UX but because it was also viewed as being a code repository, it's kind of looking to serve two masters. And there's been a lot of politics around not allowing UX to be in the dev stack. They won't give us Visual Studio, and I was wondering if you had any good ammo for trying to let us get in there. Both of us do write HTML, We know a little JavaScript, but they're like oh, you don't know our coding standards. You're going to mess stuff up.
Brad: Well, yeah. So there's a few things within that. One is designers doing sort of prototype code, flushing out ideas, doing proof of concept stuff, writing code that is ultimately discarded and will be rewritten using coding standards and stuff like that. There's actually just a great article not that long ago from the people that work at The Guardian. They were doing their mobile responsive site sort of talking about how all their designers were working in HTML and CSS and JavaScript and stuff. And they were able to-- real developers, ooh, that sounds really nasty to say that. But the people who are responsible for launching the thing will go in and sort of rewrite them or modify it to sort of fit the standard.
That's perfectly acceptable. That is what's called a good working relationship because the alternative is you working in a bunch of static mediums, and that just isn't accurate. That's just not realistic. So it's good that the UX team knows how to do that stuff and can do that stuff. But just understand yes, this is a collaboration between us too, and we're giving you the sort of stuff to get started with, and then you're going to rule that in. As far as like decoupling a code repository, coding best standards and style guides and UX and component and sort of more interface style guides, I've worked with several large organizations and they have different areas for those things. And one of my big pieces of feedback for them is I'm like get those all under one roof. Again, the idea is for you all to be speaking the same language, for you to be calling the things the same things, And you could just have like an accordion or something where this is like UX standards, and visual considerations, and dev considerations, and you can have all of that stuff under one roof. So let's say it's tabs. Tab from a UX standpoint, you can just have a bullet point that ensure that these tabs don't wrap underneath each other whenever you lose the screen real estate or whatever. From a dev standpoint, it's here's what jQuery triggers or what we're using for this and stuff that, but like having that all under one roof designing that pattern library style guide standards, whatever you want to call it, hub. Keeping all that in one roof, one, helps everyone know that it's there and in one place, and two, that you're all speaking the same language. Yep. Yes.
Audience Member: So I work for a large university, and it seems like with every new project that comes up either the marketing team or that department wants a completely new thing that's never been done before, new set of patterns. They want to reinvent everything every time. You have any recommendations for communicating how to use reusable content?
Brad: Yeah. So this is where having an established design system becomes your hammer because every university department wants to be different. Well, we're different. We're purple. We're different. We want to be orange and use Comic Sans, whatever. And by having your system in place and sort of making that available from internally or hopefully public facing, everyone can at least understand that we have a process here, and here's why that ideas is bullshit.
Because here is what building blocks we have, and we're serving these things to all these different departments. There's a reason why we need to establish this consistency and cohesion, and this is why this matters. That being said, maybe there's the opportunity for you to design some patterns that have a little flexibility to them. So for example, maybe you have your hero area pattern that's sort of a bit of a blank slate. And so they can go nuts in that hero area, but that can't bleed out into like the more utilitarian like our sidebar nav and our stuff like that. So there's that opportunity, I think, to sort of give a little bit of a blue sky, but like contain it to a singular area or a couple of areas. OK. One last question before we're done, or one, two, three. All right. Thanks everybody.