Style Guides with Dan Mall

Dan Hi guys! Thanks for having me. I'm very excited about this.

Dan Yeah, sure. So, my name is Dan Mall. I run a design collaborative called SuperFriendly out of Philadelphia, and I work for all sorts of businesses that need stuff figured out for them. That sometimes is design, that sometimes is strategy, sometimes they just need somebody… they just need a shoulder to cry on, so I'm available for that if anyone wants to hire me! And yeah, my background is in design; I was trained in design and development and now I just do design work and some advising for other agencies.

Dan Yeah, sure! So, Element Collage was a thing that I made up because I was working with a client called Reading Is Fundamental and they're an awesome company; I won't spend too much time talking about them but they have a mission to give books to kids who've never had books, which I think is just great. And when we were working on the project together, they had worked with a few agencies before, they'd gone through the design process before, the web design process before and we just sort of got to the point together where we decided that full comps are probably not the thing that they wanted to see or be useful for them, because they were really interested in how their site looked across different devices and different screen sizes and just different ways to access it, so I just thought it was going to be a waste of time to do a bunch of comps and they agreed, but we didn't really agree on what the correct solution was for them.

So, as I was just tooling around and, from the kick-off meeting they were mentioning these really, really great things, these great phrases; they kept saying like, "electric" when they talked about their brand. They kept saying, they kept mentioning some of their brand elements like shapes and hearts and books and bubbles and things like that; stuff that they use a lot in their print publication, and so I wrote this all down in my sketch book and when I went home, I opened Photoshop and I just wanted to see what those things looked like and on canvas; I didn't intend to send that to them, but I just really liked how they look and I thought, hey, I think these guys would appreciate some of this stuff and I think we could have a good conversation about it, so in the spirit of openness, so we did the whole project in the open and blogged about it and all that stuff, in the spirit of openness I was just like, I'm not going to send them the best stuff of all of this; I'm going to send them all of it, and that's how the Element Collage was born.

It was just quite literally a collage of elements that some of those pieces I think captured their brand really well, and I was wrong about that; and some of them I thought didn't capture them very well and I was wrong about that too, and we were able to have a good conversation about things like that over looking at this Element Collage thing. So that's how they came to be.

Dan Yeah, exactly. I find that it works really well for clients and also works really well for me, so it's partly self-serving in that it works for clients because if I were to give them a comp of anything, a full comp, whether it's a mobile comp or a desktop comp or whatever word you want to use, it's a moment in time, it's a snapshot.

Some people will see your site like this, but if I was going to try to illustrate every moment in time, it would just take too long and it would be wasteful work; here's it on a desktop, here's it on an Android phone, here's it on an iPad. It would just take too long because there are hundreds and hundreds of different devices and different moments in time, so what I want to show them is, here are all the pieces that we're going to be configuring in different ways for those different moments; can you imagine them put together in different configurations? And if they can, then I've done good work and if they can't, then maybe I need to help them in a different way.

And so I find that it's good for them to be able to think in that way and if I can lead them in that direction, I think that's great. And then for me it's totally self-serving because it lets me design only the pieces that I'm excited about. The stuff that… I think designers have the hardest time with things that they don't know what to do with. Sometimes you just don't know what to do with the footer, but if you're doing a comp, you've got to design the footer; you can't just leave the footer out.

With Element Collages, you can because you can be like, well I don't know what the footer's going to be like, I'll design that later, but I do know what the search box is going to look like and I do know what the… and I had this great idea for how the map should work, and you get to show them those things and I find that designers tend to, at least for me, the pieces that I'm most excited to design are the ones that I can design super-fast. And the ones that I have no idea for, I can defer those because I don't want to spend all of my excitement, all of my momentum on the boring stuff, honestly. So I find that they're self-serving, they certainly let me just design the pieces that I'm excited about, and they lead to a good conversation with clients.

Dan Yep, exactly. And that's how we build websites; it's piecemeal, but we sort of have fooled our clients into thinking that we don't do that and so I like this process because it's more transparent; it's like, this is the way that we work. If you want to see how the sausage is made, you can get a peek in; if you don't, that's OK too, I'm happy to work the other way, so I think it's really great for that too.

Dan Absolutely; I don't think I know of any deliverable that is the one deliverable to rule them all that works on every single project and I think a lot of people are looking for that. I haven't found that yet; I don't know that it exists, and if it exists, I just don't know; somebody please tell me what it is.

But there are some clients that just don't get Element Collages and they're like…cool…what is this? And part of that is that designers don't know how to talk about them and I think there's some education needed there, and the second part is sometimes they're just really hard to come up with. One of the tricks that I do on sites where I just can't design elements only is I will design a full comp and then I'll deconstruct it and show the client the deconstructed version; I'll just break it apart, so you don't have to go… I think a lot of us make the mistake that the thing that we design has to be the thing that we show. And that's not true; you show the thing that's going to lead to the best conversation.

How you get there is on you. If you get there by sitting on the toilet, that's what you do! If you get there by sitting in front of your computer for six hours; that's what you do too. So I think one way to go about it is if you're having trouble adopting it, deconstruct it; build the comp, build what's comfortable to you. Design the comp and then take screen-shots of the parts or build it in the browser and then take screen-shots of it.

There's so many ways to get to that result without having to take the journey to get directly there in the shortest way possible.

Dan Yeah, exactly! The full comp thing, it's really thrown us for a loop. It's really set us up for a bad thing because we've gotten used to the idea that, oh, this stands on its own; I don't need to talk about it, I don't need to sell it, I don't need to tell them what's in here, I can just send it over and it's enabled us to not have to have that conversation with the client.

And one of the things that I've been trying to pursue lately is, I've just adopted the goal that every deliverable that I make has to come with a conversation; so anything that I deliver, I'm not going to post on Basecamp and be like, OK, cool: post feedback here; talk to you in a few days. Everything that I deliver comes with a phone call or a Skype call or a Google Hang-out. And that has really freed me from trying to come up with a deliverable that stands on its own.

It's OK if it doesn't; it's OK if it's totally cryptic and it needs me to be able to translate for it. I feel like that's what clients are hiring. If they want comps, they can go to whatever, 99 Designs or they can get Fiverr or something and get a comp; that's not why they're hiring me. They're hiring me for my thoughts, for my expertise, not just for the deliverable, so I find that if I just assume that everything I make is going to come with a conversation, it frees me from having to make that thing so self-sustaining that I don't have to talk through it. I think Mike Monteiro says this a lot; in his new book, in his previous book and in his talks, he says there's two steps to design: one is that you have to design something good and then you have to convince the client that it's good. You can't do one or the other; it doesn't work without both of those pieces.

Dan Yeah. I think the first part of it is that the majority of times, that's true, that's what clients need a lot. But sometimes it's not true, so I don't like to go in with the assumption that every time I can sell a style guide and that's going to be the right thing. Because sometimes it's not. Most times it is, especially with clients and teams and organisations that are hiring me as a kick-start, but then they're going to have to take over this thing and if they can't take it over in a meaningful way, then whatever I deliver is useless; they just threw their money in the trash.

So I think the first thing that I like to do is I like to go in and try to listen for the thing that the want; why are they actually hiring me? Are they hiring me for the style guide? Are they hiring me because they couldn’t do it? Or are they hiring me because they could do it and they just don't have time? And that really lets me focus on what is the thing that I'm actually delivering to them that's going to help their organisation. They have to feel some type of profit from whatever they're spending money on for me, so I think that's one thing.

But assuming that a style guide is the thing that they need, then I think all roads point to style guide. Every conversation along the way needs to inform the fact that this is what we're going to make on the end, so if you hand off a full comp, well, how's that comp going to point to a style guide? How's that comp ultimately going to help them to continue to build the site and grow the site without you? Or if it's a style tile or an element collage or whatever the design deliverable is, how is that thing, that prototype, how is it going to point to the style guide and let them maintain it later on?

And I find that's the thing that comes out in those conversations that almost never comes up in the Basecamp posts of feedback; we like blue, the logo's too big, move it over… that has nothing to do with how they're going to take over the site in the future, right?

And so I find that we spend very little time talking about the graphic design of a thing and we spend a lot more time talking about, OK, well if we do this, if we put this here, what field in the CMS do we need in order to publish to that on every page of the site? I think that leads to more meaningful conversations, so if the style guide is the thing or the maintainable thing is what is really the value of what they're hiring you for, for that project, then I think all conversations need to really point to that and that gives me a better way to talk about design.

I keep talking about Mike Monteiro here, but I think his book is fantastic in the way that he talks to designers about presenting their work. One of the biggest sins in talking about work that designers do is they do that real estate tour: here's the logo on top left; he's the nav in the top right, then there's the carousel… like yeah, they have eyes!

They can see what's there, but if you talk about it in the context of the goal; with a logo we put it over here because we could mark it up this way because you can manage it in the CMS this way and because it's more modular for you if you ever need to change it. Great! That's a really objective way to talk about design, not "do you like the size of this, yes/no; check this box". So I find all the conversations that I try to have are really about pointing to how maintainable is this for them and is this actually going to be valuable for them?

Dan Yeah, let's be honest, I've done that a million times before; that's easy, it's the easier way out: you drop up, you drop the final deliverable on them and you pat them on the back and you say, good luck, let's get a drink some time, and then six months later you look at the site you're like, "oh I can't believe what they did with that site!" Well, you gave them the tools!

Dan Yeah, exactly, it's because you didn't empower them to do that. I read a great post recently by Sara Wachter-Boettcher that she wrote called something like, Less Training, More Practice, and she makes a great point: the farthest that we go, often in our industry, is we train our clients. "We're going to train you how to use a CMS; we're going to do a one hour Skype call to show you how to use a CMS: good luck maintaining your site".

But what's she's saying is, we should create more time for people to practise using style guides and content management systems and let them fail in a way that we can coach them some more. Let them practise on it as opposed to just relying on training and I think that's a lot of the reason why people are hiring in-house and acquiring and doing all this stuff because then you don't risk the "drop off the deliverable, good luck to you".

Dan Yeah, exactly.

Dan Yeah, totally. I'm getting tired of working on projects that never launch. That sucks! You spend a lot of time on stuff and then they just never launch, for whatever reason. Sometimes it is that they didn't know what to do with it: you didn't give them the tools to do it. Other times it's other things out of your control, but as much as I can now, I'm more and more in every proposal I write and Anna, you might know this because we've pitched a couple of things before together, in every proposal I write, I'm leaning more and more towards just baking in a time where it's like we're going to spend whatever, six months on the site; you guys are going to live with it for a month or two and then we're going to come back and we're going to assess what worked and what didn't and help you fix it.

Anna, I think I got that idea from you because you mentioned that you had done that a couple of times with clients, that that worked really well, because there's a bunch of things that you don't anticipate; after a month, you come back and you go, OK, how did it go? And they're like, "oh, we did this and this and this" and you're like, "why did you do that? That's super-weird! Like I never would have thought you would have done that". And then it gives you the opportunity to fix it. So I've been just trying to bake that into every project anyway; this is just par for the course, this is how we do it. We give you a thing, you work with it, we let you practise and then we come back and that's part of the deal.

Dan Oh, interesting.

Dan Yeah, I'm all for that. I'm all for throwing theory out the window if it makes people be able to use a site better and maintain it better. I'm happy to discard that stuff. All right, so what if your CSS is not going to win any awards any more? At least they can use the site, you know?

Dan Yeah, that's right

Dan Yeah, totally. One of the projects I worked on last year with Tim Kadlec was a site called Radio Free Europe, it's for an organisation in Europe, it's a news site in areas where free press is usually banned, and one of the reasons that they hired us, when they hired us and we did a kick-off and I met their team, they have some of the smartest developers that I've ever met working there, and I asked them point blank, twenty minutes into the kick-off, I was like, OK, I've got to pause this. We flew to Prague for this. I live in Philadelphia! We went to Prague and twenty minutes in I'm like… so I have to ask you, why did you guys hire us? Obviously you have the talent here to do the thing that you need to do, and I think this is the difference between why people bring people in-house and what the value of actual client service still is, and this is why I don't believe that it's dead or anything like that, is because their answer to me was: well, because we needed an outside perspective, so we needed people that were experts, that's one thing, and people that will push our team, no matter how talented our team is, we wanted people that will push our team to do even better work and the second thing is, we just need an outside perspective; that's the value of hiring you. Somebody who's not mired in our politics, in our timeframes, in our schedules, just drowned with work, the internal stuff that we have going on. We want that. That's what we value.

So that's the thing, well OK, we can focus on doing that, we can focus on doing the things that you guys might not be able to do in-house because of time or maybe because of your particular backgrounds or the things that we've worked on that you might not have seen, or our experience working with multiple clients as opposed to working with one client in-house. And so that was the thing that was valuable to them and I see that a lot with a lot of clients that come to me is they want that outside perspective, they want someone who is removed from their day to day to come in and say, well here's a thing you might not have thought of, and that's the value of a consultant.

Dan Oh, so true!

Dan Oh, absolutely.

Dan That's awesome!

Dan Yeah.

Dan We handed off Pattern Lab, that was a deliverable, and we knew from the kick-off that they've used Pattern Lab before; all of their framework is on .NET, so they basically did a port of Pattern Lab to .NET and we delivered a PHP Pattern Lab which they would match against their .NET Pattern Lab and we'd sort of collaborate, so it was sort of like we worked in the same repository but half the repository was a PHP one and half of it was a .NET one; it was totally crazy!

But we knew that that was going to be the deliverable because they are going to have to maintain this site, not only for… it wasn't one site; they publish a hundred and fifty different sites over sixty countries, so it's like, this is a massive site that has a hundred and fifty variations, so a strong style guide, a strong Pattern Lab was going to be really crucial to them. And because we knew that we were going to deliver that, the first deliverable was a spreadsheet where we had one sheet for atoms, one sheet for molecules, one sheet for organisms and one sheet for a thing that we were called presets instead of templates, and we just listed all of the elements, all of the atoms, all the molecules, all of the organisms, all of the presets in the spreadsheets and just had cell by cell discussions in Google Docs about, well should this be a molecule or should this be an atom, and why is this a molecule instead of an organism? What if we combined this one and this one?

It sounds tedious but it was actually really awesome because we were all speaking the same language from the start. We knew that that's what we were going to be building towards and so we could have those discussions, and it made building the Pattern Lab really easy because we'd worked out all the details in the Google Doc.

Dan Yeah, and to be honest, we learn a ton from them too. They were writing their own version of Pattern Lab while we were writing, and we were trading notes with them, so they would build a thing completely different than the way that we would build it and we would have conversations about it and some of those things we were just like, yeah, your version's a lot better, we'll just use your version. Or we'll add this one thing to it. So it really was a collaborative process with their team.

Dan Yeah, it was cool, it was a lot of fun.

Dan Yep, exactly. So, they've got everything in their version and they're just porting over pieces from ours, just piece by piece as they do their unit testing and they're going through and rolling it out one site at a time because they've got these major sites, this massive directory of sites so they're doing all their testing now and rolling them out one by one, because each site has a different requirement and different reporters writing for them and all of it.

Dan So that thing, yeah, that's a good question. That thing was out of our scope, so we knew that that was going to be a huge project that honestly we didn't have much experience with. They were way better at that, so we just said, hey, we're going to focus on front-end performance. That was the thing that we're going to do; really high quality mark-up, really, really fast performance for these sites, because one of the things that was important on this project in particular is that performance is literally a matter of life or death for them. They have people in places like Uzbekistan who illegally cross country lines just to access the content because that's the only way that they get news.

Dan And some of these people have been jailed or have been hanged just for accessing their website. So we can't have a page loading in thirty seconds; that just can't fly, and they only have mobile phones there, the highest speeds are 3G speeds, so it's all 3G on smartphones; no desktops, nothing like that, so our project was specifically focused on really, really well performing pages and elements and just the front-end experience, and then all the back-end stuff, all localisation, all that stuff they were handling in-house.

Dan Yeah, exactly. So we would have tons of variations of the same pattern, so for example the header, we would have a left to right version of the header and then a right to left version of the header and that was actually I think just when you guys started rolling out the pattern modifiers and things like that, so that came in really handy for using the same pattern and just swapping up content and I think, if I'm not mistaken, Tim would be better to answer this, but I think Tim came up with a really good way to control it all using the directions stuff in CSS and he's a wizard at that stuff, so there's a ton of stuff that I don't even understand about what he did, but we use basically the same patterns and just had variations of them using pattern modifiers or just sending new JSON to it or things like that.

Dan Exactly.

Dan Yeah.

Dan Yeah, totally.

Dan So, because of this project, while we were working on this project, Tim actually created a Grunt… I don't know what the right word is, a Grunt package I guess, for performance, so it's called Grunt Performance Budget and it measures per element, per pattern, how fast that pattern is loading. So it's a little thing that sits in the top right of Pattern Lab that tells you in milliseconds that this pattern loaded in twenty seven hundred milliseconds. It was awesome, not just per template or per page, we were measuring performance for all of that stuff. We also were measuring performance at the element level, at the pattern level…

Dan …how quickly was this molecule loading, and we were able to track down, OK, well this molecule's pretty heavy, but maybe a variation of it wouldn't be so heavy so they could choose, do we want the heavyweight one or do we want the lightweight one, depending on the context of the actual page that they were trying to build, so that was one thing that we did. And then we just made really heavy use of performance budgets on this project. We were always inventorying the competitor sites and I do error quotes around competitors, it's a news site, it's not technically…they don't have competitors, but we were looking at places like Al Jazeerah and the BBC and the Guardian and places that are really taking into account performance on news sites and we were always looking at what they were doing, so there was a lot of cutting the mustard tests going on; there were a lot of using that Grunt module to measure performance on a molecule level and then we were constantly updating the performance budget to say, OK, this was the original budget that we had but this thing requires a little bit more JavaScript, so real-time monitoring the performance budgets were a big thing for us too.

Dan Yeah, exactly.

Dan Yeah, we were working in the same Git Repo, so it's like they had what they had what we as soon as we had it, so being pretty transparent about that and just giving them access to all of it, it let us have early conversations; earlier than we were comfortable with, but it was better overall for the process.

Dan Good question. So, the scope of the project was basically we were going to audit their organisms and we were going to create new ones where we needed them. The thing that we didn't get to do on that project, which I think had we done it over, I would want to do this, is go back after the usage, so the thing that we just talked about; once they roll it out, I have confidence that they're going to be good sites because they have a good team, but I would still love to be in there and check it out and make modifications and work with them on that, so as of right now, we haven't scheduled anything like that, and the sites are still in development right now, so probably over the year they're going to start rolling them out but I'd love to in six months or a year, just go back and check those things out and do some more work with them to figure out what assumptions we made that were good assumptions and what assumptions we made that were not so good assumptions…

Dan Yeah, exactly.

Dan Yeah, gotcha. The first piece of advice is, don't rely heavily on a deliverable to solve this for you: rely on your listening skills to solve it for you.

So, we did element collages for this project; I'm looking at the project hub right now. The first deliverable that we had was the Pattern Lab spreadsheet; that was the first thing that we gave them. Here's a spreadsheet with four sheets: atoms, molecules, organisms, precepts. The second deliverable was a performance budget. The third deliverable was an element collage, and these came within a few days of each other.

The element collage went over super-poorly; it wasn't the right thing for this project because they looked at the element collage and they were like, "this is so abstract for us; we're used to working in Pattern Lab. We would rather talk at that level".

So this project, they were less concerned about the brand, because this was a heavily templated site that had to roll out across sixty different sites, so each site was going to have its own brand, its own colours, its own typefaces, so they were less concerned with that, which I didn't really realise at the time, so I made the wrong deliverable; I made the element collage and then when we went through it, I was thinking in my brain, this isn't going as well as it should, and they gave us the feedback, they were like, well we're not really sure what we're looking at and why this is important.

So we switched gears, so we were like, OK, let's just stop doing the element collage stuff and I actually went to full comps on that one. I did small screen and large screen comps and that gave them a much better idea of what the sites would be, what the site would look like, so I did a home page and a sub-page and then from that point, then I started doing element by element; I would design organisms; I would design… let's see what we've got here… there's a sidebar that's a side nav drawer thing, so I designed that, do a couple of variations of that and then I would do the article body or a comment thread, and I would design organism by organism and each organism I would do at a wide screen and at a small screen.

And then while I was designing those things I would save each one of those organisms as an asset in the library and then once I got to designing enough organisms, I would test designing pages. So, what does the article detail page look like? Well, I'll grab this element and this element and this element and this one and this one out of the library and I would build the page literally in like twelve seconds, because I have all the elements already designed.

Dan Exactly, it's like the design equivalent of includes, right? So that I would design pages just to look at them for myself and I'm showing to Tim hey, does this look right? And then we'd made tweaks from there and some of those I would show to the Radio Free Europe team and some of them I wouldn't. Some of them were just me validating that these elements work well together, just testing them out, and some of them I had questions about so I'd show them to the team; hey, what do you guys think of this? And they would say well, these two things aren't really working well but yeah, that's what I thought too, so go back and revise that.

And that wasn't a process that we'd planned from the start, so I don't know how we would've been able to plan for that. So I think just being kind of adaptable to what your clients are responding well to and not well to and just knowing that within the time-frame, you're going to come up with something that's going to be good for the client; you just have to figure out that thing and it's OK to figure it out real time, as long as you're honest with the client about that.

I think a lot of people have the fear that well, if we look like we don't know what we're doing, then the client's not going to feel good about paying us. That's partly true, but if you're transparent about it and say, look, there are a number of ways we could do this, we're just not sure which one is right because we haven't worked with you yet. Well, we'll figure that out together; just have confidence that we'll get to the right end point. But trust us that we'll do stuff in the middle and luckily Radio Free Europe, they trusted us enough to do that, so we got there, just not in the way that we initially charged in the beginning of the project.

Dan Yeah, totally.

Dan Exactly. And for them, we handed our Photoshop files to them and they were like, yeah, we don't care about these, because they didn't use them; they wanted Pattern Lab files and they've got Pattern Lab, so that was their way of doing it.

Dan It's good to be able to hand off…

Dan Yeah, totally. They're a great team to work with. And so I think it's good to hand your client… here are six ways that you could update this site: pick the flavour that suits you best.

Dan Well, I'm still evolving what that definition is for me, but I think so far what I've come to is: everything that they need to build their site and no more, because I think one of the things that I fall into this trap all the time is, I want to deliver everything. Every single element that they could possibly need to build the site; I'm going to style the keyboard selector. They might never, ever use that. They don't even know what that is!

I've spent valuable time and their mind-share in looking at a style guide that has the keyboard selector. Maybe they would, and that's OK. I think there's a fine line between planning for all of the possible scenarios and playing for too many possible scenarios, so I think it kind of speaks to the point that Anna, that you brought up, which is like, we just want less classes. And it probably wasn't because you wrote too many classes: it was just too much to manage in your head.

So I think sometimes style guides tend to be too much. I would never use that element; I would never use the sixteenth variation of that alert… it's just there's too much. So I think spending more time up front to really understand what elements you're going to need or they're going to need and really making those as tight as possible, I think that's time better spent than every element possible, we're going to have twelve pull quotes for them, and then they only end up using one. That's a waste of your time, it's a waste of their mind-space and just wasting that HTML file I guess.

Dan Yeah, yeah.

Dan Yeah.

Dan My pleasure.

Dan Oh yeah, I love it. I love doing it and I wouldn't be where I am if people hadn't shared that kind of stuff with me, so I feel like it's only fair to pay it forward.

Dan Thanks. Same to you guys.