RWD Podcast Episode #36 : Karen McGrane

Transcript 

Justin Avery: Hey, everyone, and welcome to Episode Number 36 of The Responsive Design Podcast. My name’s Justin Avery, and I’m your host and curator of The Responsive Design Weekly, our weekly newsletter that’s all about … you guessed
it … responsive design stuff.

This week I have another sponsor, which is Media Temple, MediaTemple.net. They’re a web-hosting
company, and they actually provide the hosting for this site, which is pretty cool. They’ve got a range of different things which they offer, different hosting services, so if you’re just getting started with your first website and you want a nice, easy-to-use WordPress site, they’ve got something for
you. A one-click install will get you started and running. If you’re thinking of delving into the dark art of the server world, you can get your own little dev box and install Linux and Ubuntu and build a server with Engine-ex and a whole bunch of stuff. It’s a lot of fun.

They’ve got all that sort of stuff, and if you’ve got a full-stack system or an app, they
also have dedicated boxes as well; so a full range of entry points for anyone at any level. I use them. I can’t recommend them highly enough, even if they weren’t sponsoring this podcast as well. They’ve actually got a special discount for all you listeners out there. If you use the code, RD25, you’ll
get 25% off your web hosting, and that is across all of those ranges of products as well. Go and check out MediaTemple.net.

Thank you for sponsoring the show, guys.

This week I’ve got an awesome special guest, which is Karen McGrane.

Welcome, Karen.

Karen McGrane Thank you. Thanks for having me.

Justin Avery: Thank you for coming on. This is like a crossover show if I could dare say, a responsive design pod-caster and her responsive design podcast.

Karen McGrane It’s like when the characters from Laverne and Shirley showed up on Happy Days.

Justin Avery: What is this? The pod-caster will explode. I want to talk about your podcast a little bit later on as well. We had Ethan on as a guest at one point, and I don’t think he was … You guys hadn’t actually started producing
or at least publishing the podcast when I was speaking to him, so I was really excited to see that he was doing something, and I was equally as excited that you were at the other … What is that? Host, isn’t it? We’re hosts.

Karen McGrane Oh, yeah, co-host, yes.

Justin Avery: For those listeners that aren’t aware of who Karen McGrane is, I was wondering, maybe just give us a bit of a background of what you do and how you got into the industry.

Karen McGrane My goodness. I have been working on the web since 1995, so my 20-year career here. I’m a long-time user experience and content strategist. I got my start working at an agency called Razorfish, where I started the UX group
there, and I worked there for about 10 years. When I left, I went off and started my own little shop and have been doing that ever since. Now I do a lot of independent consulting. I have done tons of work with publishers over the years, lots of big, mainstream publisher redesigns, and I spend a lot of
time now working with companies on really helping them manage their publishing infrastructure and workflow. Even if they’re not a traditional, mainstream publisher, helping them think like a publisher.

Justin Avery: Cool. When I think of publishers, I think of books, which is horrible, because I work in the web. I shouldn’t think of that way, but I think of large-style, large-scale book and publishing houses, but when you talk of publishers,
you don’t necessarily refer to those, do you?

Karen McGrane I guess I mean usually large-scale magazine and newspaper publishers. I work with a lot of companies that have one foot in print and one foot on the web. What I’ve learned from working with big newspapers or big magazines
in many cases applies pretty neatly to talking to organizations like banks or hospitals or universities or government, because they, to some extent, have a huge amount of off-line publishing infrastructure, and so much of that is moving on the web now, and they don’t really have the oversight and operational
insight into how to manage their web and digital publishing effectively. That’s what I do is help them go in and make sense of all that.

Justin Avery: That’s awesome. Do you think that they were getting ready for this when the web turned up, or have they all just …

Karen McGrane Oh, God, no.

Justin Avery: … missed it?

Karen McGrane No. No. To some extent everybody’s been, they’ve been hiding their heads in the sand for the last 15 years with the sense of, “Ugh, ugh, are we going to have to deal with … Oh, God, really? Maybe the web is just a fad.”
I think now with mobile really becoming such, the explosive growth of mobile is in many ways what has caused these organizations to go, “Okay, right,” like, “If we are going to maintain any sanity and get our stuff to work on all of the screen sizes and platforms that we need it to work on, we’ve got
to rationalize what we’re doing in print and what we’re doing on the web.”

Justin Avery: Are they still looking at it from two different beasts as well, like they’ve got a print problem … Not a print problem. They’ve got their print arm and now they need to improve their website arm, which involves mobile
and a whole bunch of other screens. Or are they combining the approach? Are you encouraging the combination of the two?

Karen McGrane Yeah, I think this is the inflection point. I talk to a lot of big banks, big financial institutions or large hospitals or large universities that, yeah, they still have a significant print infrastructure. They’re still
publishing magazines and brochures and white papers and things like that that are created for print and intended to live in print. Their print-to-digital workflow is in many cases that they publish a PDF.

I understand the organizational constructs that lead people to still have those silos in place, but now with mobile, you can just see them.

I want to say, I am actually probably the most sympathetic person out there as to why that
happens. I understand that you’re dealing with people’s jobs. I understand the organizational constructs that lead people to still have those silos in place, but now with mobile, you can just see them. They’re surveying the landscape of saying, “Oh, so now we’ve got to make our stuff work on desktop
screens but also on all these other screens.” Maybe this is the point at which we have to start thinking more agnostically and thinking more holistically about what we publish. We can’t be siloing our publishing efforts by channel anymore or by size of the document anymore. We’ve got to think of what
we create as something that has a fighting shot of being able to be rendered appropriately in whatever context we want to publish it in. That’s a huge shift, but that’s what I do, so there’s plenty of work for me.

Justin Avery: Indeed. There’s probably more and more as it comes on.

Karen McGrane Yeah. Yeah, it’s great. It’s been fantastic.

Justin Avery: I’m sure there must have been the same number of … I just moved roles now, and I’ve moved into a company that has a strategic arm and a creative arm, and within that creative arm they have creative writers, so they have
a writing side, and they also have the visual side as well. It’s amazing. It really is amazing to see that that much effort these days are being put into the actual words themselves or the messaging.

Karen McGrane I too am heartened by that. I wish it had always been that way. Let us look to the future and a world where everyone puts that much effort into the content and the messaging.

Justin Avery: I know. I know. If only. If only. You have worked on a ton of these projects over the time, but back to when you were saying you formed the first UX group, if you started in ’95, that would have to have been one of the
first … Did you call it “UX” back then?

Karen McGrane Yes. I started there in ’97, and yeah, when I started, I was the first person with any user experience or information architecture or content background, and the group, the initial group, we had an information architecture
group, and we had a content strategy group, and eventually we rolled all that up with visual design under one big user experience umbrella.

Justin Avery: Mm-hmm (affirmative).

Karen McGrane Yeah. I would say that was not atypical of the era. I definitely recall interviewing around in 1997. It’s not that user experience was well-established, but I think there was this growing sense that there was something
beyond graphic design and web development, like, that there had to be some other way of thinking about what we were creating.

Justin Avery: It seems to have happened a lot over the years; right? Since the inception of the web. We just keep finding these new roles which never existed, but then we’re like, “How did we never work with them before?” They’re vital
for the actual projects to move forward and for the web to be what it is today.

I think the web has suffered to some extent by this myth that websites are these things that two people in a garage throw together. For many organizations that I work with, it’s like, these are multi-, tens-of-million-dollar endeavors and every bit as complex as a major film

Karen McGrane Yeah. I sometimes make the analogy to film. If you look at the credits roll on any mainstream film production, it boggles the mind how many different roles there are, how many different types of people it takes to make
a movie. I think the web has suffered to some extent by this myth that websites are these things that two people in a garage throw together. For many organizations that I work with, it’s like, these are multi-, tens-of-million-dollar endeavors and every bit as complex as a major film, so why would we
not expect that new roles would emerge and that we would specify more precisely what someone’s task was on the project as a way of making sure that that important work got done.

Justin Avery: Yeah. That’s a really good analogy. Are you seeing anything at the moment that’s cropping up that will be 2016’s new hot job role or job title, like a lack of something or a refining of a role at the moment?

Karen McGrane Yeah. The organizations that I talk to, as they are implementing responsive design, as they are changing their processes in order to do responsive really well and recognize that responsive design now just is web design.
This isn’t like a one-time thing. This is a future thing. The sense that I have gotten from many organizations is that the distinction between design and development, there needs to be a greater overlap between something that traditionally has been thought of as two separate roles.

I’ve heard of a lot of organizations creating a new role that they call creative developer
or front-end designer or something like that. I guess I will say this edges into the whole, “Should designers learn to code?” question or designing in the browser. I think most of the organizations that I talk to say, “Look, it is simply not tenable to expect that every designer is going to learn how
to code, and that’s not what we are expecting. That’s not how we’re trying to hire, but we do need some people who can straddle both camps, who can put a foot in both camps, and so we’re going to try to recruit for those people.”

Again, I see that as a growth. I see that as new roles emerging. I see that as there being
a larger number of people working on the project, not that smart organizations are trying to replace their designers and replace their developers with one hybrid unicorn. That’s just a bad recruiting policy. It is. If you’re basing the success of your recruitment strategy on finding unicorns, you’re
going to fail.

Justin Avery: That is very true. What’s the knock-on effect for this, though? I totally agree. There needs to be more overlap between the designer and the developer, and you can’t expect … I would love to design a site. I’m a terrible
designer, but I can code a lot better, and so there’s equally opposite people in design. They probably would love to be able to code but their brain doesn’t work in that way or they’re just much better at designing. If we both work on a project together, it’s going to be a better project. Do you think
it’s going to cost more money to deliver that? Do we need to start charging more for these things, charging a less an hourly rates or a high project rate?

Karen McGrane This question of how to use scope and staff projects like this is fascinating to me. My sense is that it is a different way of working. For teams that or probably even better to say for lawyers and for procurement people and people who are writing contracts, teams that are really accustomed to working in a strict waterfall fashion, where design gets done and then handed off to developers, they may look at a process like that and go, “Well, this is going to be twice as expensive, because now you’ve got the designers
and developers working at the same time.”

I don’t really think of it that way. I think that the benefit of having a more collaborative
team, having teams prototype earlier and resolve some of the issues faster in the process, I think actually can result in a process that goes more smoothly and thus will be less expensive. Now, could people come up with a million examples, no doubt, of, “Oh, but I did a waterfall process, and it was
cheap and fast,” or, “I did a more iterative prototyping process, and it cost a million dollars, and we got nothing at the end.” Of course you can. Any process can be implemented badly, but I don’t think I would ever point to an iterative process and say, “Oh, you shouldn’t do that because it costs more.”

Mike Monteiro was on our podcast last week, and we raised this issue of how much does it
cost to do a responsive design. He was like, “Well, it’s going to cost you a thousand percent more not to do it.” That’s how I take it. It’s like you shouldn’t be comparing these things, because you’re not comparing apples to apples. You’re comparing, this is how you just need to work now in order to
get this job done.

Justin Avery: Are these things that you take in to … I jump all around the place … You do workshops with Ethan as well. Are these the kind of thoughts and I suppose organizational change that you try and impart as part of the workshops
that you do alone or with Ethan?

Karen McGrane Yes, exactly. I think what we have found in talking to lots of companies as they are anticipating a big responsive redesign is that for them the design and development challenges are to some extent the easy part. I’ve
had lots of companies come to us and say, “Look, this whole business with the fluid grids and the media queries, we got it. We can do that.” It’s all of the other stuff around how do you work, how does your team collaborate, how do you think about prototyping, how do you think about making decisions,
how you make the trade-offs among what content you show on which screen. All of that is, it’s a part of a responsive design process, but to me it’s just good web development. It’s just good user experience design. These are not things that you’re doing just because they’re responsive design. You just
have to do these things now.

Justin Avery: Yeah. No, totally. I’m sure the same is a lot of the listeners are facing these kind of issues in the workplace, working for agencies. It’s a traditional kind of waterfall approach and there’s the split approach where you
have to get designers and developers, and I can just sense the listeners are now just going, “Just tell us how. Just tell us how.” If someone was to start the change within their organization or within their agency, what would be the first thing that you would recommend they start working on as a small
change, small steps. A big bang approach is very difficult to do. Small steps are often best. What’s the key first small step to get going in this more collaborative environment?

Karen McGrane I think that, one of the things that I talk about in the workshops that I do with Ethan is planning your roll-out strategy, and I agree. I think for many companies the idea of a big bang is way too complex. It’s too risky.
It’s going to take too long. Honestly, I think one of the first things that I would say to work on would be figure out what your roll-out strategy is going to be. There’s different approaches that you can take. You could start with a page. You could start with a section. You could create a beta sandbox,
a mobile-only responsive site while the desktop site stays the same, and then you iterate on your beta site over time.

I think understanding the personality of your organization, understanding how that organization
makes decisions, what the internal risks are, like what would cause you to lose traction internally, because executives or stakeholders are looking at your responsive project and saying, “Well, this thing’s gone off the rails because we don’t have progress in this area.” I think being able to anticipate
how you’re going to do that, that’s the first place I’d start.

I would also say that honestly planning out how you’re going to get stakeholders involved
is a big deal, because the challenge that you’re going to have with an organization that is accustomed to reviewing PDFs, reviewing static mock-ups, like if you have to move them to reviewing a prototype, it’s different. They might be 100% on board with it. They might love it to pieces. They might never
want to see a static comp ever again, but they’re going to have to provide feedback in a different way, and so moving to a more iterative prototyping-based model doesn’t just mean getting your designers and developers more engaged. It means getting the whole organization working differently.

Justin Avery: Yeah. Yeah, that’s the hardest sell I find is around that traditional I wanted a PSD to sign off. I want to see the desktop version.

Karen McGrane Yep.

Justin Avery: That’s what I want to sign off and keep going. I’ve been thinking what I want to do is, because there’s the thing that I always see in Jeremy Keith’s talk, which is … and there’s the website; do websites need to look the
same in every browser.com, and of course there’s a resounding no, and depending on what browser you have, it looks like a different no. If it supports web fonts, then it’s a pretty no. If it doesn’t, it’s an unpretty no.

I was thinking the same thing surely goes for static comp as well; right? If you’re viewing
it on a windows monitor as opposed to a MAC monitor, the color is going to be different, so you see shades differently. Even if you printed it out, a printer will have less toner in a particular color and so therefore it will look slightly different again, or if someone’s color-blind …

Karen McGrane Like your projector, yep.

Justin Avery: Exactly.

Karen McGrane Like the projector that you have, it’s not going to look the same.

Justin Avery: These things are the same kinds of things as browsers. Browsers are just the output method and the screen. I disagree with the thing that they need a static comp because it then looks exactly the way it will, because everyone
… If you’re color-blind you will see differently from the person next to you. We have different eyes. Anyway, that’s …

Karen McGrane So true.

Justin Avery: That’s my rant. You’re doing a podcast now as well with Ethan?

Karen McGrane Indeed.

Justin Avery: It’s excellent. I highly recommend all the listeners to go and search for Responsive Web Design in iTunes; right? ResponsiveWebDesign.com?

Karen McGrane It is ResponsiveWebDesign.com. Ethan had that domain. It seemed like, hey, let’s put something there.

Justin Avery: He bought that a long time ago. He said, “I’m onto something here.”

Karen McGrane Yep.

Justin Avery: You guys have been nominated for Net Awards as well as Podcast of the Year. Congratulations.

Karen McGrane Indeed, yes. Yes.

Justin Avery: That’s very cool. Everyone should go and vote for either them or this one. Totally vote for this one, but I’ll understand if you vote for Karen and Ethan, because they’re pretty cool.

Now I’m just looking at the site. You have talked to 41 different companies about launching
responsive web designs and how it was within the company launching. Aside from what we just discussed then, have there been any reoccurring themes within companies that you found in speaking and things that just keep popping up?

Karen McGrane Well, let’s see. I think the themes that we try to touch on in every episode are things like how did you decide to go responsive, do you believe that mobile users and desktop users need something different, how did you
manage the design and development process, how did you manage your content strategy and how did you make decisions about what to keep and what to get rid of. We talk about performance. We talk about support, so how do they think about what they, quote, unquote, “support.” Then we ask people if they have
any advice for other people who are embarking on a responsive design.

I would say probably the most common theme that we ask about that we almost invariably get
people agreeing with is the idea that mobile and desktop users basically need the same stuff. I would say we’ve had very, very few guests on that say that they organizationally think mobile and desktop is somehow different or that their analytics data shows mobile users and desktop users want and need
different stuff. I would say pretty much across the board most organizations are like, “Yep, we did the research. We talked to people. We look at our data,” and consistently, people on every platform on every size screen want the same stuff, and I think that’s … To me, that’s the best argument for
responsive design that I could make.

Justin Avery: Yeah, absolutely. I sometimes find that the counterargument to that is that I’ve looked at my stats and mobile users are on the website less often. They’re there for not as long and they only visit one page and then they
leave, so they’re just there for short, succinct information. I’m like, “Are you sure it’s not just because your website is really slow and just built for desktop and they’re just leaving?” “No. No. That’s what the stats say.”

One thing that I would hear, what people say, “Well, why should we bother building a mobile website, because our
mobile traffic is only 4%.” Well, that’s because you don’t have a mobile website.

Karen McGrane Yeah. Yeah. I think there’s a lot of misinterpretation of stats, especially in the early days of mobile. One thing that I would hear, what people say, “Well, why should we bother building a mobile website, because our
mobile traffic is only 4%.” Well, that’s because you don’t have a mobile website.

Justin Avery: Yeah, that’s funny. That’s really interesting, though. It’s so refreshing to hear that of all the people, that pretty much everyone is understanding that mobile is the same. Just because they’re on a certain device, it
doesn’t mean they want different things. You tweeted the other day an article in I think it was CIO.com or something where it was a paragraph which says, “Mobile users, obviously always on the move …” and then it kept on going. I was like, “Ah, so frustrating. It’s just such a bad thing to be …”

Karen McGrane I agree. It is such a bad myth to be spreading, but yet it still … I guess it’s like the people who we talk to who have implemented responsive design don’t buy into it, but I think broadly in the marketplace I think
that myth is still circulating, and I think there’s probably a lot of people out there, probably with a dog in the fight, who have a reason for wanting to promote mobile as being something different. They’re going to make more money if they promote mobile as something different, so they’re going to sell
that as a concept.

Justin Avery: Yeah, well, mobile-only houses, like if you have a mobile-specific website on a mobile-specific platform, then with mobile-specific content, then that’s another business that can make money just out of mobile without losing
the responsive work and therefore the mobile work to another company that will offer the full range.

Karen McGrane Yeah. I saw some SEO guy writing, “So, yeah, you want a domain-specific strategy where you’ll have your m-dot site and then your t-dot site for tablets. Then in the future you’re going to want to have your w-dot site for
watches and maybe your tv-dot site for televisions,” and you’re like, “Dude, at what point are you going to realize that this is just not a tenable strategy?”

Justin Avery: I had written a very similar post to that around the end of the March, and I didn’t get a chance to finish it because I was going to release it on April Fool’s Day to say that Google had changed their minds, they were actively
now that Apple had released the watch that they adhered to and they thought that you should definitely get a w-dot domain for watch-specific websites and traffic, but it sounds like he was serious. That’s not good.

Karen McGrane No, no, no. I guess when you look at the world through only your lens, so if you’re the SEO person, he had a solid argument from an SEO standpoint of why they wanted device-specific search queries. It’s like, all right,
I guess that makes sense for you, but what about for all of the other people involved in making this website? Even if you can argue that you’re going to get lift in SEO from having this device-specific scenario, is the increased search traffic actually going to pay off? Is the cost benefit trade-off
of having to maintain six different code bases actually going to pay off for you in the long run? No. No, it isn’t.

Justin Avery: That’s such a good point. It’s not like the search engines are going to continue to go down that path; right?

Karen McGrane Absolutely not.

Justin Avery: It seems like they’re favoring more towards another way of building a site.

Karen McGrane Right. If there is one organization out there that is more invested in the idea of one URL and one page, it is Google. That is their entire way of seeing the world. While Google does not necessarily penalize m-dot sites
or other approaches, Google benefits if you serve everything responsibly. They like it if you just have one integrated, one set of content, one URL.

Justin Avery: Yeah. I’m all for it. I suppose the counterargument which I will point out now because I’m sure that the people who are anti-this, they wouldn’t be listening to this anyway, but their reason why everyone who you’ve interviewed
so far is, “Yes, you should have a single piece of content to serve everyone no matter what the device is.” Of course they’re going to say that, because they have bought into responsive design. It’s obvious. It is just the way to go.

Karen McGrane Yeah.

Justin Avery: It’s definitely the way to go. You do the workshops and you do these podcasts as well, but you also do a lot of other consultative work, like you’ve mentioned, and worked in a lot of large-scale successful projects. What
has been in the past few years your most or what you think is one of the most successful responsive projects, and what actually was the key to that success?

Karen McGrane Am I allowed to say, “ResponsiveWebDesign.com?”

Justin Avery: Of course you are. Plug.

Karen McGrane Because honestly, my best advice for people who are looking to do a responsive design is to have Ethan Marcotte build it for them. It’s worked out extremely well for me.

Justin Avery: Yeah.

Karen McGrane I will say, just as a plug [crosstalk 00:30:02].

Justin Avery: That is a great strategy, though.

Karen McGrane Ethan’s fantastic to work with and it’s just been such a delightful collaboration. It’s been really interesting to see how he does things, how he makes things work. That site is lightening fast. There’s a lot of things
about it that I’ve learned just from hearing him explain, “Oh, okay, I’m going to do this differently, and I’m going to tweak this.” Like, “Oh, look, now it loads before people even click on it. It’s amazing.”

Justin Avery: If I was to go back and do another chat with Ethan, he would equally go, “You know it’s the Responsive Web Design site. Do you know how easy it is to do things if you have a content strategist on your team who provides
you with all the content up front?”

Karen McGrane I think he does say that. I gave him a content model when we started working on the site, and I think he was like, “Oh, good, these are the pieces that I’m going to work with. Okay, great.”

Justin Avery: I’m glad you mentioned content model actually. I recently bought and it’s sitting in front of me here at the moment actually, A Book Apart Series, the whole library. I was very lucky. I had got some birthday money and thought
I would invest in some nice library material. You’ve got a book within that as well.

Karen McGrane I do.

Justin Avery: Content Strategy for Mobile.

Karen McGrane Indeed. That came out in 2012 from A Book Apart. Another little plug is that I have just recently finished writing my next book for A Book Apart, which is called Going Responsive, and it’s about some of the bigger management
and organizational changes that people go through with a responsive redesign. That’s being edited right now, and I hope it will be out this year.

Justin Avery: Awesome. That’s very exciting.

Karen McGrane Yeah, pretty excited about that.

Justin Avery: I was about to get upset if you were going to say that you have rewritten the second edition after I’ve just bought the library. Damn it.

Karen McGrane I would love to do that sometime, but, no, that’s not happened yet. Yeah, the Content Strategy for Mobile book was really, I guess I would say it was very dear to my heart, because it articulated and I tried to explain
so many concepts about web and web publishing and how I think about separating content from presentation. Those are things that have been important to me my entire career, but with mobile it’s sort of … I often say that mobile is what makes people have this light bulb moment of, “Oh. Oh, it has to
work in a bunch of different places. We can’t treat it like a piece of paper anymore.”

Justin Avery: Yeah. One of the things …  really like the book. One of the things, there’s a lot of stuff in it. I lent it to a friend today, or a work colleague. She’s slowly going through each of the different books, and she
was like, “Whoa. This one’s thick.” I’m like, “Yeah, it’s a little thicker than the last one that we had a look at.” The previous one was I think … Is it Erica Kissane? Did she do the one on …?

Karen McGrane Erin Kissane, yeah. She did The Elements of Content Strategy.

Justin Avery: Elements, yeah. She was like, “I’ve now done that one. I’m ready to move on to the mobile bit.”

When I was going through it, you were talking about content modeling as part, as one of
the parts of the book as well. How important is content modeling for responsive, and is it … How important is it?

Karen McGrane Well, that’s a good question. I think I’ll answer that in two ways. One is that a lot of what I talk about with content modeling and adaptive content, and some of the examples that I use, like the NPR, create once, publish
everywhere model, to some extent, that is intended to support a truly multi-device strategy. If you actually genuinely need to serve content in a different way to different platforms. One example that I like to give is a university that has just recently bought a bunch of digital signs that they want
to put up all over campus, and so they want things like news for students or campus alerts or events listings to be able to render appropriately on their website, on their mobile app, and now on these digital screens.

Even a university that has adopted a responsive design approach for serving their website
still may need an adaptive content solution that helps them serve app platforms and these signs as a great example, because it’s like, “Oh, right, if you just stored all of that as one giant WordPress blob, you’re not going to be able to target that content and render that content style, that content
differently on the sign than you would on the website. A more structured, more modeled approach to that content will allow you to serve both of those platforms from the same content repository. You’ll have one set of content that shows up in three different places and can be styled three different ways.

Do I think that’s necessary? If you’re like, “Well, I don’t have that problem, Karen. I
just have one website and we’re going responsive. Do I really need to model that content?” My answer there is, “Yes, I think you still do” in the sense that, one, this is a chance to really break away from an entirely page-focused model of managing content where all of your content lives on a page the
same way that content used to live on a piece of paper and instead have content that is more flexible to be published in more dynamic ways.

Second, I think one of the things that Ethan and I have spent a fair amount of time talking
about recently is doing conditional loading in responsive, so using techniques to progressively enhance not just the code and the design but actually to progressively enhance the content.

The Guardian has a great simple example of cases where at smaller breakpoints they will
show just a headline, and then as the screen size expands, at larger breakpoints, they will show a headline and an image. That’s a very simple example, but to me, that’s the kind of thing that can be done within a responsive design.

The Guardian has a great simple example of cases where at smaller breakpoints they will
show just a headline, and then as the screen size expands, at larger breakpoints, they will show a headline and an image. That’s a very simple example, but to me, that’s the kind of thing that can be done within a responsive design. It follows the ethos of progressive enhancement. Thinking carefully
about the scenarios under which you want to serve less capable or more capable devices, more-or-less stuff, but it doesn’t require the same server side involvement that dynamic serving adaptive content solution would require.

I think smart organizations should be thinking through those kinds of scenarios, saying,
“Oh, okay, great. What if we treat all of our content as if it’s structured, smaller chunks of content,” and we can do something that, to me, is kind of like adaptive content, but it’s progressively enhancing the content.

Justin Avery: Yeah. Yeah. For those listeners that are thinking about that particular example, the Guardian example, because The Guardian do such a fantastic job. They are probably, them and probably the BBC now as well but mainly The
Guardian …

Karen McGrane Oh, the BBC, yeah, yeah.

Justin Avery: They’re such go-to examples of how a site is well-built, a large site with very complex content. When you were talking about loading in the image, having the image appear on a slightly larger breakpoint, if anyone is thinking
that their display none and then display block and the image loads anyway, that’s not how they’re doing that.

Karen McGrane Right.

Justin Avery: They’re actually detecting the screen width and then ajaxing in, for want of a better word, the additional content based on that screen width. It isn’t an additional hit that someone’s not seeing. We’re not hiding content
on the page. We’re just not loading it on first load. That’s right, isn’t it?

Karen McGrane Exactly. It’s not setting display to none. It’s instead starting with the absolute baseline level experience and then adding, progressively enhancing that up for devices that have greater capabilities. I think that’s hard
for people to wrap their head around. Even when I explain it sometimes or it’s like, “But wait, didn’t you say we weren’t supposed to do that?” I’m like, “No, you don’t want to start with the biggest, most complicated version and then hide the stuff that other versions don’t get.” You want to start with
the smallest, least capable version and then progressively enhance it, layer more on top of it when you know the device can handle it.

Justin Avery: Yeah. Really good advice. Very good advice. I know you deal with a lot of different companies, and you are … Actually, I’m going to say this, and it may be completely untrue. You’re not super-techy so you don’t get in
the fields?

Karen McGrane I’m not.

Justin Avery: CMS’s, but you do come across a lot. Have you found if … I’m not asking you for a recommendation. I am asking you for a recommendation. Have you come across a CMS that may work better for this sort of stuff than not?

Karen McGrane I would have to say that is probably the number one question that I get asked. I thought about [crosstalk 00:39:23].

Justin Avery: Oh, really?

Karen McGrane I have a card that that I hand out or something. Honestly, I often sidestep this question by saying I think that most content management systems on the market today, all of the major platforms out there, can actually do
this in the right way. Even CMS’s that have what I would call a really page-centric model, they don’t have to be used as pages. Things like Sitecore or whatever, they may call the default node of content a page, but it doesn’t have to be a page. Drupal did a very smart thing by not calling
it a page and calling it a node, because that actually models more accurately to the way that pages will get constructed out of these nodes or chunks of content.

Justin Avery: Yeah.

Karen McGrane I guess if pressed to give some examples, I’m an advisor to a product called Contentful. They’re a startup based out of Berlin. I like them because they are an API first based content systems. The model that they use is
that they are entirely authoring and storage, so their goal is to provide the best tools out there for content modeling and as a content repository, and then you can get APIs out of their system and pipe it into whatever you want. They don’t care what you’re using on the front end. You can pipe into
another CMS. You can pipe in to static templates. You can pipe into … There’s a bunch of different ways that you can build the site on the front end using their content repository.

Justin Avery: That’s really cool.

Karen McGrane Yeah. I think that that kind of decoupled model is, I guess it’s like if I have to put my money on anything, it’s that sort of decoupled framework. I think we’ve suffered on the web by having web publishing tools. I don’t
mean to pick on WordPress, but WordPress is the classic example to me of a web publishing tool where authoring and storage are so tightly intertwined with the presentation and theming and publication capabilities that it’s impossible to break them apart. You can’t change anything in there without changing
everything.

I think that decoupling authoring and storage from presentation and display and actually
treating those like those are two separate systems with APIs in between them, that is so much more flexible. It is so much easier. There are challenges in maintaining that too. Don’t get me wrong. I think for the long term for where most organizations need to go, that’s going to give them way more flexibility.

Justin Avery: Yeah, that’s a really good recommendation. I’m going to have a look at Contentful and I’ll put it in the show notes as well. I’m just thinking for people who are building these Ember apps and the new Javascript framework
stuff that doesn’t really have much content, this would be perfect for, but if you are building them with those apps, make sure you progressively enhance them and at least kick some content out instead of just a body tag in Javascript, please.

Karen McGrane Yes.

Justin Avery: Speaking of WordPress as well, this will lead on to, probably getting up to that time now, so probably lead onto the last question, but I used to, my last company I worked for, the CMS that runs the responsivedesign.is similar to your example of Sitecore or somewhere it calls it a page or it calls it a news item. The way we used to build to get around it or I built to get around it is I modeled all the content. You still have the page and the page content, which is where maybe the post would go, but around that
I’ve reused the meta data, so it has a meta data screen.

Usually, traditionally, that is fall back-in stuff for in the code that you can’t see. We
re-purposed it to chunk out, so basically content model all the bits, so I have things like the audio file, the podcast guests, Karen McGrane. Your link will be in it it’s own little individual field. It allows me to then reuse the meta data on a front-end point of view rather than just using on the
back end that you traditionally do, so that’s one way to get around that.

The other point about WordPress, I’m currently building a site in WordPress with my wife
actually, and I’ve used a really good tool called Advanced Custom Fields, and that allows you to get past that blob, and you can create, and I’ve done that exactly the way … I’ve read your book years ago, and it helped me with the way that I put pages together and websites together to make sure everything
can link up and reuse different bits, and depending on where you’re listing it. Advanced Custom Fields is fantastic for that. It allows you to really chunk that content out.

Karen McGrane Yeah. I am working with a designer and developer named Laura Shank right now on my personal website, and she is just an absolute wizard with the Advanced Custom Fields. I don’t mean to pick on WordPress. I use
it myself. I will continue using it, but talking to her I was like, “Wow, this is among the most impressive executions of WordPress I’ve ever seen.” It is absolutely possible to do it.

Justin Avery: Yeah. That was one of the things I jotted down too as well. There’s not as many blog posts on your site, recent ones anyways. Have you fallen out of love with blogging or just been too damn busy?

Karen McGrane Yeah, I think a lot of that creative energy goes toward the podcast now. For the time that you have to spend on doing that kind of, I don’t know, just like, “Hey, I only need to say things in public,” that’s where that
energy goes, but I’ll also say, like many people, Twitter seems to fill that void in my life, like why bother writing an entire blog post when you can just write 130 characters.

Justin Avery: One hundred and forty characters. In a blog, though, Karen, come on.

Karen McGrane I know; right?

Justin Avery: Also, I suppose you do a lot of speaking as well. I’ve seen you at a couple of conferences now and always excellent, excellent talk. That would also be like a really, really long blog post; right? So much effort must go
into writing those and preparing for them.

Karen McGrane I do actually wind up posting the transcript of all of my talks as a post, because I wear hearing aids, and I think it’s really important to support accessibility on the web in all of its forms, and accessibility is another
one of those things where it’s like, “Hey, if you do it right, it makes things better for everybody.” Having a transcript of the talk in addition to the slides and the video if it’s available, I think it’s great for people who don’t want to listen to a video or can’t listen to a video. It’s great for
SCO. It’s just great for everybody.

Justin Avery: Yeah. You guys, yourself and Ethan, both transcribe the podcast that you do, which is great. I started transcribing my one, because one of my good friends is a guy from Poland, and he’s like, “I can understand you when
you speak to me because I can see your lips and I can see your expressions, and I get the gist of what you’re saying, but when I listen to you on the radio or the podcast, you’re Australian, and I don’t understand some things.” To read along, and I’m sure America doesn’t get that quite as much. It is,
for people with English as a second language, it’s sometimes easier to digest it in reading format than listening to it, especially with …

Karen McGrane Yeah. You have a warm and compelling Australian accent.

Justin Avery: I put quotes for different parts of the podcast. That is going to be the quote for this one.

I said I was going to lead into a question, the other thing when I was talking about the
WordPress thing. It’s around content and collecting the content as well. We’re building this site for the studio that we look after, and I’ve found it very difficult to … My wife was looking after writing the content and getting it ready, and I was looking after making the website look good, and I
gave her page templates that she could fill out, like the purpose of the page, a high-level description, what things need to be on the page, and her mind worked more in, “I need to see it on the screen to understand how much I need to write or where the bits go.”

I was just saying, “I need to see the content so I know where it needs to go on the page
and how much space it needs and things like that.” Do you have any recommendations around approaching these kind of problems with new website rebuilds and when you bring content and content modeling into the whole process?

I was just working on a website recently in which the person who was in charge of the website, owned the content, basically kept saying, “No, I need to see the designs first. I need to see
the design so I know where the content is going to go.” I’m laughing at that, because I’m like, “No, no, no, you’re doing it wrong. No.”

Karen McGrane Yeah, that’s a great question. I was just working on a website recently in which the person who was in charge of the website, owned the content, basically kept saying, “No, I need to see the designs first. I need to see
the design so I know where the content is going to go.” I’m laughing at that, because I’m like, “No, no, no, you’re doing it wrong. No.”

I think that when people ask for that, they often don’t mean I need to see a fully rendered,
full designed page. They’re not saying, “Pick out every color and every font and all of the layout and show me all of the color transitions and everything.” What they want to know is roughly a wire frame. I think that wire frames have gotten such a bad rap in the industry. I’m sure if I were to go on
Google right now, I could find a million well-respected designers that are like, “I never make wire frames, and they’re a huge waste of time.”

I think the reputation is that they’re a waste of time from an interaction design and a
visual design standpoint. They are not a waste of time necessarily from a content model standpoint. I think that for us to assume that content creators will always understand what we want by giving them a content model and saying, “Sure, you write a headline and a teaser and a body and some bullet points
and add this meta data, and then you don’t have to care about how it gets laid out on the page.” I don’t think that that’s the answer.

There was a post on the Content Strategy Google group a while back in which a bunch of leading
content strategists were talking about how do you communicate content models to your clients, and pretty much every one of them was like, “Oh, yeah, we use wire frames. We use high-level wire frame sketches that are not really intended to communicate the layout or the design.” They’re just intended to
communicate, this is a headline, this is a teaser, this is a link. The Lego pieces that you’re adding are going to get laid out in this way.

To me, that’s just another argument for saying we need lots of rules in the process. We
need all of the tools at our disposal. Saying that we need prototype thing or more interactive tools doesn’t necessarily mean we throw out Photoshop or we throw out wire frames. It just means that as our work gets more complex, we need more tools to do the work.

Justin Avery: Excellent advice. That’s really good. That is really good. I quite enjoy the approach that Stephen Hay talks about a lot in terms of building up a prototype from a mobile first, and if you don’t have the content, just put
in what you’d expect the place to be, which is kind of like wire frames in the browser as well.

Karen McGrane Sure. Yeah.

Justin Avery: I never thought of it from a content model point of view as well. That’s really good.

Karen McGrane Yeah. I have a post on how much I think everybody should, that Lauren Ipsum is okay. There’s been a whole sense from the industry of Lauren Ipsum is the absolute worst thing ever and you should never use it; it’s the death
of websites. I use it all the time. I use it to this day. There’s lots of scenarios under which you don’t really have all of the content, but you know you’re going to have a headline. You know you’re going to have a teaser. You roughly know how long it’s going to be, and you just drop in some fake words
there. You drop in something where the words are going to go here; are these the right words? Here’s a rough idea of what we want to put here.

Did I do that with ResponsiveWebDesign.com? Absolutely. There were lots of pages that Ethan
could start building where I didn’t have to have written every word on that page. I just needed to have a sense of, “Yeah, okay, yeah, I’m going to write a headline here and then there’s going to be a couple paragraphs of text.” I think any processes where we’re demonizing somebody’s way of working at
it, it’s like I would say in almost every scenario, there’s a bad way to do it and there’s a perfectly acceptable way to do it. Let’s try to communicate like, “Hey, these tools are appropriate in these scenarios. Don’t use them to solve this problem.”

Justin Avery: Yeah. That’s actually really good. I totally agree. I think it’s well wrapped up. I think I’m going to end it there, because I think that’s a good way to finish it.

Karen McGrane All right.

Justin Avery: I do have one more question, though. Each week I ask the guest of the current show, so that’s you, to ask a question of our next guest. I have a good idea who it will be next week, but you won’t know who it is, but last
week, Nick Schaden, who is the front-end developer for Get Pocket … In fact, if anyone likes Get Pocket, go and check it out because he’s done a marvelous job on the web app, but if anyone uses InVision as well, which is, it’s a new tool to allow you to collaborate more around designs that come out
of things like Photoshop and stuff … It’s very good anyway. You should go and check it out.

He recently did a webinar on building responsive teams with InVision, and that was live
last night and will be released later this week, so check that out in the show notes, and you should have a look at that because it’s really cool. I digress. His question for the next guest, and he didn’t know it was you, was, “How has responsive web design changed the workflow within your company?”

Karen McGrane Ah, fascinating. Well, I don’t know that I could speak to my company directly. Ethan and I do have a little company called Responsive Web Design, LLC that we use to manage operating, for operating expenses for our workshops,
but …

Justin Avery: So it’s affected it quite substantially really.

Karen McGrane I think if I were to look at that more broadly and say, “How has it affected the workflow in the companies that I talk to?” I would say the challenge of having to look at the work in context on a variety of different devices,
have a prototype available, often a prototype that’s going to be available to people across the organization all the time, so you’re not waiting until the big reveal where you go into a meeting and you project something up on the screen, and you’re like, “Look, it’s our website.” Instead the prototype
is always available. People can always go and poke at it and bang on it.

That, I think is the biggest shift in how people work. It’s a shift because it’s not just
about the design and development process. It’s about how the entire organization thinks about how do we review this work? If I’m reviewing the work on my personal phone, how do I give you comments on it?

That, I think is the biggest shift in how people work. It’s a shift because it’s not just
about the design and development process. It’s about how the entire organization thinks about how do we review this work? If I’m reviewing the work on my personal phone, how do I give you comments on it?

I used to get a PDF but I would send an email back with comments, notes on this PDF. Now
I have to have new tools for communicating, “Oh, well, at this particular breakpoint or at this point on the screen, this thing doesn’t look right” or it’s not the right size, or it’s too low on the screen. I think that finding ways for people to talk about their feedback on a responsive design is a
big challenge, and it really changes the workflow of the entire team.

Justin Avery: Yeah, that’s a tough nut to crack.

Karen McGrane Yeah, it is. It’s crazy.

Justin Avery: I like the approach of the website always on and no big reveal as well as this continually evolving prototype, because I find some people when you’re doing big website redesigns as well or their first big foray into a large-scale
website, they still have this once it’s live, that’s it, they can’t touch it. It’s not like a book; right? Once it’s printed, that’s it. That really is it. You’ve got to distribute and sell the 10,000 copies or whatever you printed.

The website’s continually iterated. It never stagnates. It will always change. I think the
ongoing prototype and continual update of that throughout that design and development process cements that idea into organization’s brains. I hope it does anyway.

Karen McGrane Yeah. To me that’s the big shift of the web is this is not a piece of paper. When you publish it, it’s not static. It’s going to be constantly evolving, constantly updated, and so that means that how we talk about the
work, how we evaluate and give feedback on the work can’t be paper-based anymore. The tools we use to create and comment on our work also have to be digital.

Justin Avery: Yeah. Yeah. I might go for a search. I remember seeing something where you could provide feedback. It was kind of like a browser plug-in, because ideally that’s about all you can do. You’d hit the browser plug-in. It would
work out what operating system you’re on, what device … not device … possibly device, but what browser you were using, what width it was, the speed of the connection at the time. All these things that are really, really vital for us to be able to nail down what the problem was instead of someone
going, “Menu doesn’t work,” which is practically useless.

Karen McGrane Yeah.

Justin Avery: I’ll have a look for that too, because that was actually a really good tool. I don’t know if it ended up taking off, but, yeah, that’s really good.

Karen, this has been awesome. I’ve had a …

Karen McGrane This has been so much fun.

Justin Avery: Yeah, it’s been really fun. I’ve learned a lot. This is my favorite thing about doing this. I get to learn loads of stuff that I’ve been really interested in. Thank you so much for taking the time out of your day and jumping
on this as well. Now, we talked about a few things that you’re doing and you’ve done. Have you any plugs or have you got an talks coming up, workshops, things that you’ve got going on?

Karen McGrane There’s a fantastic event that’s happening in August in Vancouver, Canada. It is called Design Content Conference, and Ethan and I will be doing a full day on responsive web design there, and I’m also giving a new talk
there on adaptive content, so three years after my book was published, I’m doing a look at where adaptive content is today and how I see organizations doing it, doing it right, doing it wrong, what’s going on there.

Justin Avery: Nice. I like the website. I featured this a few months ago actually. I love the angles. Very triangley, the design content. It’s very cool.

Karen McGrane Yeah, the people who organize it, Steve and Shannon Fisher, are fantastic, and their event producer, Erik Westra, is the same guy who produces the workshops for me and Ethan. I give them two thumbs up. They’re fantastic
people.

Justin Avery: Terrific. It looks like a really good lineup as well actually, looking through the list of folks, all very, very clever people.

Karen McGrane Yep. Yep. Can’t go wrong if you come to that conference.

Justin Avery: Awesome. I will also say that everyone should go to ResponsiveWebDesign.com/podcast and check out the podcast. Go to Net Magazine, The Net Awards and vote for your favorite podcast as well. It has to be the Responsive Design
one that makes it into the finals. Definitely vote down on one of those.

If people want to follow you as well, you said you’re now publishing a lot more on Twitter.
Do you have the tweets?

Karen McGrane Do I have the tweets?

Justin Avery: Do you have the tweets? What is your Twitter handle?

Karen McGrane Oh, my Twitter handle is just Karen McGrane. Keeping it real.

Justin Avery: Keep it simple. Don’t turn up “Content Strategist Number One” or something weird. Cool. I’ll put those up in the show notes, but thank you again, Karen, for coming on. It has been super-fun.

Thank you to all the listeners for tuning in and listening. Write us up in iTunes, give
us five stars. That would be awesome. If anyone would like to join me, if you’ve done a redesign or if you’re working on something which is awesome or you even have questions, go to ResponsiveDesign/Contact and just buy something towards me. I’d love to hear what you’re working on or have a chat to you
on this.

Karen, thank you again.

Karen McGrane It was my pleasure.

Justin Avery: I hope to see at some point, but I’ll definitely be following you on the twitters.

Karen McGrane Wonderful. Well, thank you so much.

Justin Avery: Thank you, and I look forward to the next podcast and the new book as well.

Karen McGrane Yeah, even better.

Justin Avery: Thanks, everyone. Cheers. Bye.