Episode 111

Going Responsive with Karen McGrane

December 17, 2015

It’s clear. Responsive is the way to go. One website for all screen sizes, for all devices. But what does it take for a company with an pre-existing site or pre-existing way of working together to make the needed changes to go responsive? It's not about the media queries. It's about everything else. Karen McGrane joins Jen Simmons to talk about her new book, and to imagine an amazing future.

In This Episode

  • What does it take to revise an existing site to be responsive? What are the biggest challenges?
  • How can you get the whole team on the same page, understanding the complexity of modern web design?
  • What about responsive web design is so hard?
  • Why using PDFs generated in Photoshop to make final decisions is a lousy way to design. How a process that includes prototypes is much better.
  • How to make big changes to the work flow inside a team.
  • What we can learn from the past, the transition from analog to digital.
  • The possibilities in design that open up once we modernize our content systems and workflows.
  • The dangers of using a front-end framework.
  • What’s wrong with the industry’s current focus on style guides?
  • What does it take to design a true system of content and layout options?
  • How might we start empowering content creators with tools for true editorial design?

You can’t rely on static comps being thrown over the wall to developers to build. It’s got to be something that’s based on a prototype. Those teams have to be working closely together. Those teams have to have a shared language and a shared value system.

Transcript

Thanks to Holly Doggett for transcribing this episode.

Jen

This is The Web Ahead. A weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons, and this is episode 111. I first want to say thank you so much to today’s sponsor, Squarespace. We’ll talk more about them later in the show. And I should say thank you to Pantheon for powering The Web Ahead website, and to Cachefly — the fastest, most reliable CDN in the business.

So today we’re going to talk more about responsive web design and especially about the stuff that’s really hard — which is not the CSS or probably not even really the design of how it’s going to be squishy, but all of the other things around, “oh gosh, I guess this means we have to completely reorganize and restructure our entire company.” And I hear a lot of people who have done great work like helping big companies make this kind of transition talk about those challenges and how hard those are. And so, I have here today, our guest Karen McGrane.

Hi, Karen. I feel like you know probably better than anybody in the entire world what it is that I just said which is really just me telling people what you say not me talking about this topic. But it seems like companies are really struggling to figure out how to have their websites in this responsive era.

Karen
[laughs] Ethan Marcotte and I do corporate workshops with companies to help them understand what’s gonna to be involved in a responsive redesign. And I can remember one developer who was one of the team, core team members, who would be responsible for making the responsive redesign happen, and I can remember him saying, “can you come in and talk to our executives and explain that this isn’t about beating the website with a media query stick? This is about a whole bunch of other changes that need to happen.” And, in a sense, I wrote this book for him. I may not get hired to come into all of these companies, but I would really like for designers and developers to have a book that they can hand to their boss or their project manager or the CEO and say, “If you want to go responsive, this is what it is going to mean for you, not just for me.”
Jen
So you wrote a book called Going Responsive. You can go to A Book Apart.com, and easily find it. It’s cool, I’ve read it. A Book Apart books are intentionally small, and they’re almost like journals in a way — if anybody spent time in graduate school around a bunch of academic journals. I like the fact that they’re designed — at least some of them — I think yours is one of them — designed to be — you can buy a whole pile of them. You can buy 10 of them and hand them out to everybody on your team to get everybody on the same page. Because there’s so many people who make decisions on a project who are not really—they don’t speak the same language that you speak. Or half of them do, but the other half don’t. Everybody’s going to have a different idea of what is going on, and it’s a way to get everybody on the same page. Maybe even before you get started on a project. You can say, “Hey, everybody read this. Now let’s have a conversation about it. Okay, now what are we going to do? Oh, let’s all use the words ‘adaptive’ and we know what that means now and ‘responsive’ we know what that means. We have a sense of what this is going to take, because it is more than just a media query.”

Karen

Nobody can see this, but I’m sliding $5 over the table to Jen. Thanks for that plug. Yes, don’t hesitate to buy copies of the book for your entire team. [laughs]

The differences in language are a huge barrier, and there are a lot of terms that get thrown around. “What’s a media query?” “What’s a breakpoint?” Those of us who swim in the web design and development world have gotten up to speed on what those terms mean, but you have to think how many people, like your boss, may have heard those words but not actually know what it means to design a website using these new capabilities. So one of the things I did in the book is write a glossary that is my own highly-personal definition of some of these terms. It’s really important for teams that are embarking on a responsive process to develop a shared understanding of what some of these common terms mean but also to develop a shared understanding of some of the murkier subjects like, “What is adaptive?” and when decision-makers or team members come in and say, “Hey, maybe we should use adaptive to solve this problem.” Well, what the heck does that mean?

Jen
I would bet especially folks who perhaps are more senior—executives who make big decisions—are probably people who are least willing to admit they don’t know what something means, because they really could lose a lot of clout, a lot of face. So to have a cheatsheet, “oh what does that mean? Oh, yes! I know what a pattern library is, of course!”
Karen
I think it was really having some empathy for the people that you work with.
Jen
I think we should talk about what kinds of projects we’re talking about. I get more irritated every week about the way in which now on the web, a lot of people are working on very different kinds of projects, and they’re not really explaining what kinds of projects they’re working on. They’re assuming everybody’s working on the same projects that they are. First, what kind of projects are you talking about here? Is this for big media corporations or how broad do you think your perspective and what you’re talking about is important on a much tinier site or a site that’s less of a content publication site and more of a some other kind of site?
Karen

I would bet that this is relevant for the 80% middle sizes of projects.

So at the small end of the scale, if you have a website that is small enough that you could blow up the entire thing and start from scratch; if you did a redesign, and that wouldn’t be a terribly painful process; or if you have fewer than 100 pages and when you redesign, you can just redesign from scratch; the things I talk about in this book may be less relevant. Probably because you are not wrangling lots of stakeholders or wrangling complex process — you might just be able to kill it with fire.

And on the far other end of the scale, I think we often point to organizations like Google or Facebook and try to use them as an example to say, “Google is using almost all entirely adaptive solutions, and they’re not going responsive,” and “Facebook has a separate mobile website, so maybe we should have a separate mobile website.” You can’t point to an organization on the scale of Google or Facebook and have it be relevant to your corporate website. You just can’t. They’re solving problems at a scale of a dimension that have no relevance to your problems. For 80% of the website in the middle — they’re complex, they have a CMS, they are — I go to a midsize or large scale organization that has stakeholders, some complexity in the design and management of the site, I think this book is 100% relevant. Because I think that teams that are focused on how they make decisions differently are going to need to understand how responsive forces them to make decisions differently.

Jen
So do you think that this is hard, because—there is something naturally inherent to a responsive website that is hard—or is it because a lot of the sites that we’re talking about and you were just talking about a redesign so we’re talking about some midsize site that needs an update a redesign so it’s got a lot of legacy and I assume a lot of employees who are adding content to the website. Maybe they’re not employees, but there’s a team of people. Is it that responsive is so hard or is it that a lot of those sites were built 10, 15 years ago, and 15 years ago we had such a different idea of what a website even is or what it a team even is and the team was 3 people and now its 300 people and that website is falling down. And it has nothing to do with that it’s squishy to fit on different screen sizes. It has everything to do with 2003 and 2015 are a world apart from each other.
Karen

I don’t think responsive is that difficult. I think it does force you to make more holistic decisions and you have to look more expansively across all of these different sizes and form factors. It forces you to make better decisions about priority and focus and really understand the user experience and what users need, but I don’t think those things are the root of the problem.

Teams have this ancient, calcified website, the publishing system is from 2003, they have dozens of stakeholders, each of whom are focused on their one little thing, and people are afraid. The biggest thing that I encounter is you have a team of people who is convinced that the desktop is working real good. You look at it, and you’re like, “you could do better than this.” But they have metrics in place, a whole framework for measurement and evaluation of success of the website, and they are afraid if they make changes to it — big, wholesale changes — those metrics will go down, people will lose their jobs, fingers will be pointed. It’s that fear of change that has people locked into Stockholm Syndrome with their desktop website. They’ve started to associate with their captors.

All I can do is to point to the range of devices available on the market today, point to the phone in everybody’s pocket that they sleep with. That they take to bed with them at night and say, “You can’t keep privileging this crappy desktop experience just because that’s the measurement for the metrics you have in place. You’re gonna have to take a leap of faith and make these choices.”

Jen
It’s almost like this mobile onslaught — you can no longer deny that this system is no longer working for you. It hasn’t been working for you for a long time. It’s not really working for your readers, your users, and now you have to change now.
Karen
The only thing I can tell them to get them to the other side is, I genuinely believe that your website and your processes will be better if you do this. You’ll be happier with your website, it will be easier to manage and maintain. Your customers will be happier. Your conversion rates are gonna go up. And I’m not saying it’s a slam-dunk. It’s gonna take time and effort, and it maybe a little rocky along the way. Your conversion rate could go down in the interim as you go through this process, or in tweaking the site. If you take the long view, you’re going to be so much happier in the end after you go responsive and after you clean up some of these problems that have been lingering for a decade.
Jen
It’s interesting because I think that people who use the web and consume other people’s websites it’s so obvious when you see a website that feels old, looks old, has old problems in it. It assumes you’re going to look at the sidebars and all the content that’s in it. It’s assuming that you want the navigation to work in a certain way or that you love those fly-out drop-down menus. Then you see a company launch a new design. Or you see a new company — more often a new company comes along — a competitor and they’re better. You trust them more, simply because of their website. Their service might not be better, but it seems better because their website is modern, and it seems like they have their act together. And then I see the old company kind of die on the vine while the new competitor takes over the space.
Karen
I’m a huge fan of the Virgin America redesign. That was done by a consulting firm called Work and Company here in New York. It’s a spectacular responsive site, and it is so pared down. It’s fast, and when you look across the airline space, so many of those websites are so terrible, and the Virgin America team managed to go in and have this laser focus on users being able to book airline tickets. Which is so obvious. Your user goal and your business goal should 100% overlap, and the goal should be make it possible for customers to come in here and buy airline tickets. Yet you look at so many airline websites, and they can’t quite figure that out. The process of going responsive — prototyping, performance — enabled that team to boil everything down to its essence and it makes for a fantastic experience.
Jen
So what other kinds of advice are you giving people? What does it take to have success in a giant overhaul like what we’re describing?

Karen
There are a number of factors that go into it. As you alluded to at the beginning of the call, looking at the organization of your team is important. I imagine there are many web developers and designers across the industry that have long-wanted a more iterative, more collaborative process. Team structures, client contract, just the way that structured silos of design and development don’t often make that possible. With a responsive project, you HAVE to make that possible. You can’t rely on static comps being thrown over the wall to developers to build. It’s got to be something that’s based on a prototype. Those teams have to be working closely together. Those teams have to have a shared language and a shared value system. Frankly, those teams may have to report up into the same people. I’ve heard a lot of companies say, we couldn’t do this if we didn’t start hiring for different roles or move these teams so they report to the same person. Those are big organizational shifts that offer a lot of value, but they’re not things that individual designers and developers can make happen on their own. It will take executive buy-in to pull that off.
Jen
Especially re-organizing what department is combined with what department and each division changes.
Karen
The move to prototyping which is something that everyone is enthusiastic about and has wanted for awhile — that changes a lot in the way that teams work together. I see lots of companies where the entire review process — how you get your stakeholders involved, how you have people give feedback — all of that is based on having PDFs of Photoshop comps. I talk through a process where you start with a Word document and move all that into Photoshop and make a PDF and then people comment on it, and then you go back into Photoshop and you edit — because Photoshop is obviously the world’s best content-editing tool — and you circulate those decks of PDFs around, and every time I walk through this process, people laugh awkwardly, but it’s a shameful laugh like this is embarrassing and I’m like I know you do this I know this is how your process works and guess what? It’s terrible. You hate it, everybody hates it. It’s not an efficient way to mock things up. It’s not an efficient way to collaborate. And if the only thing I got about changing a responsive process to provide a forcing function to make people quit sending PDFs of Photoshop comps around and instead start creating more interactive prototypes — I think that would be a huge win.
Jen
I completely agree with you. I don’t know how people can justify or can live with themselves. A company needs a website, they hire a “design agency” and the design agency completely and 100% considers its job to be to ask a few questions, to go off and design a pretty-pretty in Photoshop and then email back some PDFs and then they’re done. They drop of the PDFs and walk away. The developers come in after that. The developers and designers don’t even meet each other. They don’t even have each other’s email addresses. They can’t even ask a question, but I’ve been on so many projects like that — recently!
Karen
[laughs] I love that quote from Stephen Hay where he says, “Photoshop is the most effective way to show your client what their site will never look like.”
Jen
Never! Especially if nothing else — let’s list the reasons. The fonts don’t render anything like they actually will on the web. Designers use fonts for the “desktop” that aren’t available for the web and don’t ask themselves why. They don’t even bother to double check to see if that typeface is available on the web, “Yes, let’s use this typeface. It’s gorgeous.” [laughs] “It’s on my computer, how come you can’t see it?” There’s no hover state for links. Nevermind everything else you might want to hover or animate or have stages of interactions if something is going to change or morph depending on what the user is doing. No, none of that. It’s just a static, static , static thing. And then all the content is magically the same length as all of the other content. Every headline has the same number of characters. Every teaser paragraph is the exact same length. Every photo has the exact same aspect ratio to it and there are zero pieces of information about how that ideal picture is supposed to function in the real world where the content is constantly different length.
Karen
I have a friend who tells a story who goes into an agency meeting: “We’re doing a mobile-first process, but we’ve decided we’d show you the desktop comps first, because they’re easier. So this is really going to pop on hover.” And he says, “You mean on tap.” And they say, “Yes, on tap.” And he’s says, “Is that why there’s a mouse cursor mocked up on the mobile mockup?” [laughs] Photoshop was never a good tool to design for the web, but it’s even worse when you’re trying to manage mobile interactions, mobile behaviors, and all of the different changes and states across all of these different screen sizes.
Jen
You can’t test-drive anything. You don’t know what that’s going to look like. You don’t know what this font we’re going to use is going to look like in Chrome, Firefox and Safari. We don’t know. And Edge? What is it going to look like on a Windows computer vs. a Mac. Those things should be decided, and when you realize that the font that you chose doesn’t look good on half of your users’ computers. But you can’t even make that choice if you’re not looking at the real thing in a real webpage. I could rant forever, but what makes me frustrated and angry about that topic is that I don’t see everyone agreeing that PDFs generated in Photoshop alone — use Photoshop all you want, just don’t make that the only tool that you’re using. Don’t make it the tool where you make all the big decisions. Make it the tool where you try some stuff out, and then you go prototype it. But to do that thing where you only make PDFs — and of course they’re all letter-sized pages. Because when was the last time you opened up a website and it was the height of a letter-sized piece of paper? [laughs] But I see so many people, so many designers, so many folks defend the use of Photoshop in this way, they want to defend the use of PDFs, they don’t want to change. I understand resistance when you feel overwhelmed and inadequate or scared — I totally get that — but at some point that gets outweighed by realizing it’s a good idea. What I don’t understand is why people are clinging onto — “No, PDFS are great! Photoshop is fine! That’s the way we’ve always done it. I’m not going to make a prototype. I don’t need to learn CSS. Why do I need to know anything about CSS? I’m a designer. I’m supposed to draw pictures in Photoshop.”

Karen

I think it requires a broader organizational buy-in into changing the process. I’m sympathetic to the individual designer who maybe staring down the barrel of having to learn prototyping in the browser thinking, “How am I going to replace the design tools I’m most familiar with on this timeline in order to start working in this completely different way?” That’s scary, and it may not be possible for an individual designer to make that transition without a huge amount of effort.

But, if there were a broader organizational buy-in to the idea that you need to have a pattern library — a front-end framework — that the rest of the organization is going to be looking at prototypes and not expecting comps from those people, I think if wasn’t sitting solely on the shoulders of individual designers, but rather sitting on the shoulders of the leadership of the company — the management of the organization of the company that is responsible for pulling off a redesign like this — I think you would start seeing that change happen.

I worked a lot in the publishing industry, and if you want to see people who have had to go through the 5 stages of grief, [laughs] of not wanting to change, it’s print designers. In the last 10 years, I have gone from a place where I would go into meetings and meet with open hostility from people saying, “We refuse to do this. This is terrible. We don’t work this way. This doesn’t meet our values. This doesn’t work with our process.” Now I will often go into meetings and people with the print background are the most enthusiastic about change, because they realize that’s their career. They’re going to have to work in a different way to have any hope of employment in the future.

I’m willing to bet that there’s a lot of designer/developers out there that if they got organizational buy-in on training them to do things differently and even more important, organizational buy-in that the rest of the company — all of the stakeholders were going to work and think differently, I think that these changes will happen. There’s got to be some bigger motivation. The bigger motivation is that the CEO is going to come and say, “Why does our mobile website suck? Fix this.”

Jen

It sounds like what’s needed is not that an individual designer, but an individual designer can decide this. If there’s one listening right now, go for it! We support you! We cheer you on! But that is hard. You have to go to work next week and crank out work for that project within the hours that you’ve been budgeted by your project manager. There’s a deadline, and you’re saying, “Well I don’t think PDFs from Photoshop are proper way to build a website anymore. I’m going to go learn CSS and HTML — which I haven’t been using very much yet — and completely change the entire way that I work. Sure, I’ll still make my deadline of getting this done within 22 hours.”

You have to do that on nights and weekends or on the side while meeting your deadlines in PDF. Instead, if the whole company said we’re going to make this change whether it’s everyone all at once or do it one project at a time. This-person-that-team, this-person-that-team. Over the course of the year everybody will switch the way that they’re working, or however it works for your organization. Then you could have a class. You could have a workshop. You could bring people in to teach stuff. You could have a hack week where people hang out for the week and learn how to do this. You’re right. You need to get the designers and the developers in the room together. Someone already knows HTML and CSS and can prototype it. The other person is the designer. There’s so many ways this can work, but it’s not the one person who can make the change.

Karen
With this book, my goal is to have a calling card that I can send out — or designers and developers can hand out to their team — that will be an outside stranger, somebody who understands this space, that is writing for A Book Apart, says “We have to make these changes.” Sometimes those individual designers and developers can’t get their boss or the executives to work differently. Maybe when you get the sense that there’s a broader organizational shift happening across the web, then people are inspired to say, “We have to do things differently now.”
Jen
When you look at the websites of your competitors that are gorgeous and successful, and you want to not fail, [laughs] and then you say, “How do we do that?” And you start realizing you have to change a lot of stuff around. “And how do we do that?”
Karen
It’s never going to happen if you treat it solely as a superficial let’s-skin-a-website problem. This has to be treated as a fundamental we are changing things at the very foundation of how we make decisions, how we structure our teams, how our publishing processes work. It gets right to the very culture of how web design, or how digital, fits into the organization.
Jen

We were just describing the designer with the Photoshop, but it’s a lot more than that. It’s how the content gets made, how the marketing happens, how the APIs deliver the content to multiple end-points.

You were talking about print and print designers resisting things, and I’ve had this thought recently as I’ve been talking and thinking a lot about print. As I work on layouts, thinking about layouts. It’s funny sometimes how we imagine print as this thing that’s been the same for a long time. All those print people have all this resistance—or all these set ways, or all this fixed-thinking, because it’s been the same for so long.

Karen
Oh, but it hasn’t.
Jen

It totally hasn’t! Print went through such a big revolution. It wasn’t even called print. The fact that we call it “print”. That makes sense to people who graduated art school who never sent a job to a printing press whose entire career has consisted of drawing things in InDesign, Photoshop and other Adobe products and making PDFs out of them and turning PDFs into their professor. That already has nothing to do with the printed page!

I watched that transition happen from physically assembling a bunch of pieces of paper by gluing them together with wax, and taking that artboard and putting it into a giant camera, and getting it photographed to be put on a printing press – and that was even new. That wasn’t around very long. Before that, people were setting type with little pieces of letters and metal.
That whole industry went through an incredibly painful and radical change in the 80s and 90s.

Karen
Massive waves of change where people had spent 20 or 30 years learning very complex skills. They were experts in working in this one particular way, and then overnight it was 100% irrelevant.
Jen
They literally took those giant machines, and those rooms with those giant machines, and threw them in the trash. And rolled out a bunch of computers to people who had NEVER used a computer.
Karen
Some people could make the switch, and some could not.
You look at it. I don’t know what the parallel would be for us in our industry. It’s like if you imagined that one day, we had to throw all of our computers away. Every mental model, every physical task we knew how to do, and had to replace it with something different? Yeah, now you’re flying airplanes.
Jen
You have to fly airplanes to do your job. Go.
Karen
How many people could do it? So I’m genuinely sympathetic to people who are wrangling, struggling, to say, “I just learned to do this one thing. Now you’re telling me it’s obsolete and I have to do it in a completely different way?” That’s hard.
Jen
It also puts a bit of it into context. We’re just trying to get people to make websites slightly different [laughs] and that’s less of a change than switching from analog to the digital industries. It is.
Karen
Right. When you look at it that way, responsive seems easy.
Jen

Right, exactly. You all did this before, you can do it again! I know you’re still bitter and traumatized by last time [laughs].

In the work that I’ve been doing this year, what I’m hoping is happening, or will happen, is that some of what is lost from that transition from an analog print process to baby computers — when computers were so weak — websites, to something that is more complex. More complex websites, with more complex, powerful, once they get redone to be better, elegant systems.

Karen
I’m so excited about that future. My focus is on the limitations of current publishing systems. I think there are a lot of content management platforms out there — or inadequate CMSs — that force editors to constrain what they’re doing too tightly, don’t give teams the tools that they need to have a more flexible publishing process. You couple that with the stuff you’ve been talking about this year on the layout side, similarly, teams don’t necessarily even know what’s possible. Their CMS don’t make it possible because the front and backend are too tightly coupled so you don’t have that much flexibility. I get so excited about the web when I hypothesize 5 years out where people fix their publishing processes, designers and developers have more flexibility on the frontend to experiment with layouts and do more custom work on the frontend because the backend is flexible enough to support it. I see a world where we could have the tools to break out of these boxes and do more.
Jen
And do some more art direction. Do some really beautiful, unique designs. Because we’re not getting that right now, right? We’re getting a lot of everything is very much the same as everything else and we are stuck in this rut where we’re making a website so it has to be in this shape, in this thing. In fact, people blame responsive web design.
Karen
I know! I roll my eyes at that, obviously. One, I think there are people out there doing some really beautiful responsive work, but two, we’re in the early days of this. We’re still just figuring out the basics of how to make this work. I think that mobile websites look like they were made by Fisher Price these days doesn’t exactly portend the future of web design. It’s people getting some experience in doing this kind of work. Once people have their arms around it, they’re going to be able to be more creative and more flexible.
Jen
People are complaining because they’re seeing lots of websites that are lots of boxes. I almost don’t even know what people are —
Karen
The constraints of using frontend frameworks also make a lot of cookie-cutter websites. My take on it is that using those kinds of frameworks is a fantastic thing to do for prototyping. For your team to be able to quickly mock things up, to have a customized version of some kind of framework seems like a great thing to invest in. To then use that for actual production code has quite a lot of limitations.
Jen
I don’t know that I love the idea of using them for prototyping because right out of the gate all of your ideas are limited by what the prototype can do. I’m thinking around layout and typography and design. So if you’re using Bootstrap, well Bootstrap comes with a whole lot of typography. A whole lot of opinions about branding and design. People think that this Google Material design is a new design framework. Oh, you don’t need a designer! You can just use Material design and you’re all set.

Sure, if you’re making and Android app, cool, because you’re leaning into the Android world, and you’re making your thing of that world. But if you’re making something that has nothing to do with an Android app, why would you use Google’s branding for Android on your completely separate project? Because Google said you should? Well, of course Google wants everyone to copy their branding. That doesn’t mean that you should.

If you are trying to put together a startup, and you want to focus completely on the functionality, and you have no money, and it’s you and your friends and none of you are very good at doing anything visual then use Bootstrap because you’ve skipped over that step. But realize you did something there. You chose to go with a vanilla generic branding and visual design that’s going to come back to haunt you later. Maybe later you’ll want to change it.

Meanwhile people are using frontend frameworks that set page layout. You basically get four templates. You gotta use the same frameworks. Then everyone’s complaining that everything looks exactly the same as everything else. Yeah, because everyone is using the same design template. That’s gotta go. I’m glad it’s so extreme, because people are really tired of it and ready for something different.

I do not think — I’m totally just jumping on your topic and slamming mine in here — that we should be replacing the Bootstrap or whatever today’s, yesterday’s design framework — with a new design framework! I do not want to see a whole bunch of, “look at my Flexbox Design Framework!”

Karen

I have three things to say about that. When I think of those frameworks I think of them as a wireframe tool, than a design tool which is not how the rest of the world sees them. I think they’d be very useful for doing some quick, interactive prototypes to show how different pieces might reflow, but in an experience that’s just about the content or the structure.

Second, the enthusiasm for creating pattern libraries or a design system or a design framework. That can be, if it’s done well, can be a positive experience for the company that’s creating it, because it can help build a shared understanding of the language and vocabulary around the different patterns that are being used, and that’s one of the problems with a framework like Bootstrap. It comes preloaded with all of these assumptions about what all of the components are and how things should work and think. The whole process should be for the company to figure that out for themselves rather than taking somebody’s preassembled vocabulary and point of view.

Third, this is the thing I’m fired up about in the industry right now, is that I see a lot of problems with this enthusiasm for pattern libraries and design systems that seem to be recreating the exact same problems we had a decade ago with creating templates in that we are creating design systems that really still do not take the content into account. We used to tell content creators, “Here’s your 3-column with hero template.” Today we’re saying, “Here’s your hero module.” There’s still not the interplay. What are these design systems we are using? and How do the content creators expect to use them? That’s a grave concern of mine. I hope we get our act together.

Jen

On the second point, if somebody wants to take Bootstrap, open it up, pick it apart, look how it’s organized, get some really good ideas, to fork it, change the name of it, keep what you like, change what you don’t like, add your own flavor to it, add your own branding, or move things around a bit, that’s a great idea. There are a bunch of different ways to do that.

I used to use Drupal themes. For awhile, I’d use someone else’s whole. Then I would use someone else’s, but hack it up a bunch. Then I would not use someone else’s, but I would open up four of them, look at them, steal ideas from all four of them, and mash them together into a Frankenstein version that was more my own than anything else. I didn’t start from a blank page, I’d rip open other pieces, take ideas, take Lego blocks from all over, and jam them together. That’s a great idea.
Having your own templating system or your own framework system — whatever you want to call it — your own CSS objected-oriented organization, and your own this, that, and the other. Some standardization. All of that is a great idea. If you want to open up something like Bootstrap and hack it in order to get to that place, go for it.
When people don’t question what they’re getting, and they don’t even understand it, when they just use it without even looking at it, that’s when problems start to happen.

Let me jump in here with our sponsor, and then we’ll talk about your third thing. We’ll talk about pattern libraries, because there’s something really juicy right there.

Jen
So Karen McGrane, pattern libraries.
Karen
Woo! Hot topic.
Jen
I have been to a lot of conferences lately, and there are a lot of talks about pattern libraries and building your own, designing your own. People find it incredibly helpful and very inspiring.
Karen
Super, super-useful. Wholeheartedly agree.
Jen
The classic example that I see is "look at this website, and see how there are 17 kinds of buttons on this website." It seems everytime that some other team shows up to build a new form they make their own button. None of the buttons match each other. Why don't we have a library that has the button in it, and everyone uses this particular class or markup. Then all the buttons will be the same. Then if we want to change the button we can change the code in one place and all the buttons all over the website will be updated automatically.

Karen
I look at that button example all the time, and it seems like the simplest example of a more complex idea which is if we systemize things either in the CSS or on the backend, then, when we want to make changes, when we want to update something, we don't have to do it on every single page or go hunting through the code to find every example of something. We can treat things like they really are patterns or stencils and have systematic management. The button example — I get a little frustrated with it because it's almost too simplistic. I can't imagine going to a CEO and being like, "All the buttons on the website are different. You should spend all the money it's going to take you to build a pattern library." I don't know that that conveys the depth of the problem, but to try to articulate that if we sat down as a business and thought about what do we publish, why do we publish, what are these components? Having those reusable Lego blocks will make building web pages faster. Creating bespoke 1-off pages is time-consuming and expensive. Having stakeholders walk into meetings thinking that they get a blank canvas and can draw their own personal Taj Mahal and have us go build it for them — that's costly and wasteful. These components make management of the website much more efficient. It's not just about visual consistency; it's about a maintenance process that makes web design and development easier and a lot more sane.
Jen

When I hear folks talk about style guides I totally am like, "Yeah! Totally! Cool! That’s great!" But when I think about my own design work — and I'm not working on big teams these days, I'm not sitting down with corporate multi-million dollar Web projects figuring out how to get 40 people to coordinate their work — I guess it’s well, it’s because that’s not what I’m working on — there's no spark inside of me. I don't get any exciting ideas, because there's not enough about the content. It's not focused enough on systematizing the content of finding patterns in content and then figuring out a way to present that visually. The layout of it, the styling of it, in a way that creates system.

It shouldn't be about a system that makes things for efficient for developers. It should be about a system to make it more understandable to users.

Developer efficiency is cool, especially when resources are limited and if you can create efficiency in one place, it means you can have time and money to build other stuff. Creating technical debt is a terrible idea, so eliminating it along the way as much as you can is important, because 10 years from now you don't want to be in a place where you have to another overhaul.

But I wonder about the question that is not being asked. [Designers creating style guides focus on the micro, and create these design systems, and then they] just drop things into the Holy Grail layout without thinking about it. “The layout is the same layout we've always had, so why do we have to talk about the layout? We're going to put 3 boxes in a row, and then underneath that put 2 boxes in the next row, and then underneath that, another hero graphic, and above all of it we have a carousel, and now we're done.”

Karen

And no content creators know what to put in those boxes. To me, one of the biggest challenges I have wrestled with over the past 10 years is going into content teams and — going into talking to people who are responsible for managing and maintaining the website for publishing the content to the website. We've handed them all of these templates. So here you have a template with a carousel and 2 boxes, and then 3 boxes below it, and you should figure out how to take your stuff and fit it into these boxes. They are like this is a complete mismatch to what I want to say, how I want to say it.

My fear with these pattern libraries is that we're duplicating that exact problem only with smaller components. I am enthusiastic about the process of solving the bigger problems. What really are the underlying challenges with content creators being able to take their ideas, their messages, what they need to communicate and have the right tools or the right pieces to put together to be able to communicate that. What are the design system challenges? What are the pieces that we should be laying out on the frontend to create a usable, navigable, findable experience for users?

My friend Jeff Eaton sometimes says, "people always come to me and say, 'how can I get the content team to use markdown?' and says you know, if you have a problem that can be solved by using markdown, you don't really have a problem."

If your problem is genuinely at the level, then that's not a big deal. The problem is not markdown. The problem is a much bigger systemic editorial challenge. I feel the same way about the frontend style guide button problem. If the only problem you have on the frontend of your website is the buttons aren't consistent, you don't have a problem. That you're focusing on small inconsistencies in styling probably means you're missing the bigger inconsistencies that are rooted in a lack of editorial control over flexibility — having the right editorial tools to communicate the things that need to be communicated.

Jen
There's a whole world. There's a door that we have not opened that no one is going through, but we can open this door and we can go through it. Maybe you and I, Karen, are going to go through this door together next year of real editorial design on the web.
Karen
I know. I sit here, and it's like we can both see that door. We both know where it is, but maybe there's a boulder in front of it. That boulder is our terrible content management systems, and our inadequate ways of tracking and maintaining frontend code. If we could just push that boulder out the way, it's going to be great.
Jen

I was at the New York Stock Exchange working as a frontend developer. We had no way to architect anything, or plan anything as a whole. So I was doing that rogue as I tend to do.

We had just moved into a new space, so the people on the content teams were in the same room. So I was like, I'm just going to go ask them what they want, because these PDFs that got emailed to me from the design company whose name I don't even know don't make any sense to me. Instead of just reverse-engineering this alone — I’m going to go ask somebody. And they loved me for it.

Nobody ever asked them what they wanted. “What do you want this content type to be named? What do you want this field to be named?”

At one point there was a hero graphic with a carousel. I was making a content type, the Stuff That Goes Into The Carousel content type. It had an image, headline, and teaser paragraph and a link to the more button. And the content folks wanted some editorial control over that. They wanted some templates, some options, to be able to say: for this, we want this picture to be half the space inside the carousel with the headline on the side big; and on this one, we want the photo to fill the space with the headline overlaying the whole thing; and on this one, we want... And my reaction to them was "[buzzer noise] you're doing it wrong. This is the web. That's not how the web works."

This was five years ago. I really did feel like, well I'm the designer, I’m of the web, and it's my job to teach these not-of-the-web people what the web does and doesn't do, and doing it that way is doing it wrong. But that's not what I did. What I did was build them a little dropdown, and it had options in it. I named them, not according to the visual layout, but I gave them some kind of semantic names, because who knows what the visual layout will be like in 10 years, so that they could give — now according to some of the stuff I've learned from you — some metadata that would go with that content that would be slightly more useful.

Now here I am — that's the door. The door is giving them tools so that in a much better version of that world, you could, as a reporter, as a journalist, as a whatever, as a designer, as an art director, as a writer, you could put your “content” into the content management system and say I want this one to be more like this. This one to be more like that. This one gets this kind of layout. This one gets this other layout. This one gets this treatment. We as designers and developers and folks building CMSs out — systems — we create a space to say you can do this, you can do that. Give more of what it used to be like when it was physical paper, and you could put the thing where you wanted to. You just put it through the wax machine, and pasted it down where you wanted it on the page.

Karen
[laughs] You felt like you had that control.
Jen
Yeah, you did whatever you wanted. The wax didn't care; you just put it wherever it belongs. Instead of now, which is, we have a header, and the navigation is across the top of the header, and we have this sidebar, and the sidebar is full of crap —
Karen
Yeah, put it in the sidebar!
Jen
I'm just rambling now. I do think that there's a way in which I'd love to see more people start asking this question. Less focused on breaking everything into parts so all the tiny little parts are floating around with no relevance to each other, and more designing the whole, and a bunch of different versions of the whole, so you have 12 different versions of the whole or 25 different versions of the whole, so people can choose from this holistic result or that holistic result or this other holistic result.

Karen

It's truly systemic thinking. Personally, I don't think that if we're planning a design system that doesn't encompass the editorial processes and the content itself, and doesn't encompass the backend publishing system, that’s not the whole system. That's a very superficial layer on top of the website, and if you think about that holistic system, the frontend design, the HTML, the CSS, but you're also think about the content and you also think about the content management interfaces and the publishing process, if you think about that, and what it could mean to have truly componentized-content and design… that is so powerful, it is electrifying to imagine processes and teams that could work that way.

The handful of companies that I've talked to that have genuinely componentized their design system on the backend are living in this amazing world for relatively straightforward web pages that could be constructed out of their existing components. They don't have to use Photoshop; they don't have to use a frontend framework. They could construct the pages using the CMS in the production environment and have that page — send that out on staging and have them comment on the actual web page and then when everyone is happy with it, they just publish the web page. There is no difference between the tools that people use to mockup and imagine what the web page could be and the web page itself.

That may only work for, within their systems today, relatively well-structured ordinary repeatable pages. It's not something you would use for some kind of like out there marketing page or something shiny and glossy and unusual. The more robust those components are — the more robust those Lego pieces are — you probably can pull of some pretty amazing stuff just using those and combining them in different ways. It's so much better and more manageable and maintainable. It keeps everybody on the team focused on creating pages within a system because that is less expensive

Jen
It's an interesting balance to figure out how to structure things, to break them into chunks and structure them and to set rules and bumpers. You're allowed to do this; you're not allowed to go outside of those lines. Then also create flexibility and create freedom and the ability to imagine something new and build something new. In a way, the structure, and having structure makes it possible to have the freedom to build something.

Karen
I can remember talking to one team that, as they were building this out, asked themselves the question: "The people we are going to give these components to, the people who are actually going to be constructing pages on the backend — do we think of them as guardians of the system, of the framework, or do we think of them as artists of the system?” I thought that was a beautiful way of expressing the idea that you could treat the people who had the components as if they were the rule-followers. These are how these components are supposed to be used and you can only use them in this way, and this way only. Or, do you treat them as artists of the system where they are like, "This is the palette I have to work with and I can combine these pieces in new and different ways that perhaps hadn't been expected by their creators, but when I combine them in this way it gives me more flexibility to achieve what my stakeholder or this business owner wants to have happen.” They came down pretty clearly toward saying we want to empower people to be artists of the system. We don't want them completely going mad and doing weird things with our components, but we don't want them to think we said this component can only be used in this way, and this way only, and it's a violation of our style guide if you use it in any other way. They were saying, let's think about reusable pieces that will give people the flexibility that they need to have something emerge from the system. When you're thinking about creativity in the design process, to me, that is where I want the web to go.
Jen
This door that we're talking about that we want to go through is, in my mind, that's the real web. That's what the web actually really is. 50 years from now, hopefully, looking back, all the other things we thought it was will be gone, because there's something there that is inherent to the medium itself. I think that we're still struggling so much with, and don't quite understand or teams haven't had the chance to go in that direction, but that direction really is magical. There really is something there to it.
Karen
It's so ever-constantly emergent. With every successive wave of change we're shaking off a little bit of the vestiges of all of the media that have come before us and letting the web truly be what the web should be. That's fun.
Jen
Cool! Thank you so much for being on the show today.
Karen
Gosh, thank you. I could talk to you endlessly about this.
Jen
I know, well, we have to do something.
Karen
[laughs] Yes, we should get together. We're both in New York.
Jen
We gotta scheme up something. Have you help me work on well, yeah. Stay tuned everybody. 2016 is going to be a good year. People should go checkout your book, http://abookapart.com/products/going-responsive. Especially if they want to get ready for the future of the web… they gotta get their website organized now, and that book will tell you how to get your—everyone will ask me — I love it! How do I convince my boss?"
Karen
Bulk discounts are available.
Jen
You hand them this book and then you have a bunch of meetings. Where else should people find you or follow you?
Karen
They can find me on Twitter, I'm @karenmcgrane (very confusingly-titled there.) They can also go to responsivewebdesign.com and see the podcast and the workshops that Ethan Marcotte and I do.
Jen
Yes, because you and Ethan Marcotte have a podcast, and you have workshops. And you're out on the road travelling and speaking at conferences and stuff. People can find you there.
Karen
They can hunt me down some place and say hello.
Jen
Yes, alright well, thanks again. Thanks to Squarespace for supporting this show, and until next time, that's it. Bye!

Show Notes

a photo of Karen's book cover, on various screens and in paper

Comments

Awesome podcast! I enjoyed listening to it this afternoon. I wanted to point you to a tool that I use that helps me design, prototype, and mock in real time with real content: Webflow (webflow.com). Honestly, it solves so much of what you and Karen were discussing about the state of design today.

I have no stake in recommending Webflow (or the couple of competitors out there), I just really think that a platform like their's is the future for design professionals that create on the web. Being able to iterate, test - in real time -, and then hand off a code base is so much more meaningful and practical for clients.

I'm curious if you've ever heard of or tried Webflow or a similar product.

Thanks again for all that you do and contribute. I look forward to your next podcast!

I regularly listen to "A Responsive Web Design Podcast" that Karen co-hosts (and was mentioned at the start of this podcast) and I often thought she would be a good guest for the web ahead.

It's like a comic book character crossover! :)

Great podcast. I am presently exploring a responsive design tool called "Webydo." The lure for me is that it is code free and it almost too good to be true. I would really be interested in thoughts on this platform?

Add new comment