News & Announcements

Stay up to date with all the latest Do it with Drupal news.

Speaker Interview: Karen McGrane

by jponch on Jun 16 2011 - 11:01am with 3 comments

We've got some tremendous speakers from a variety of disciplines at this year's Do It With Drupal in New York City, so we're continuing to sit down with them and ask them a few questions to help everyone get to know them a little better. Recently Lullabot's Jeff Eaton got the chance to ask Karen McGrane a few questions.

Jeff Eaton: You've got a strong background in design and information architecture, and you've worked on projects from the New York Times site to Encyclopedia Britannica online. More recently, you've been talking a lot about content strategy. Why the focus on content?

Karen McGrane: I'm not really a content strategist — I pretend to be one on television! Here's what happened: when I was thrown into this field in 1998, I was an information architect. I ran the information architecture group at Razorfish, and there was another group called "content strategy." At that point in time, information architecture was a huge party. We had conferences, and mailing lists, and books, and everyone was talking about it.

I had no incentive to try to grow content strategy, and I look back on that time and think, "I made a huge mistake!" All of my energy went into getting people to talk about information architecture, but I wasn't getting them to talk about content. I benefited for years from working with people who were doing content strategy, and were very complimentary to my skill set, but no one was talking about their work.

I hit about 2004, and I was running the entire user experience group at Razorfish in New York. Content strategy was part of that, and suddenly it became my responsibility to manage content strategists and hire them and get people to care about it. I had a lot of "Oh, shit!" moments where I realized that many people just weren't thinking about it at all, and didn't even know how to talk about it. That's when I got religion: I realized that if I do anything, I need to tell people why they need this, why it's important, and why they need it in their projects. And now, five or six years later, it's great to see it really taking off.

Jeff Eaton: That raises a second question: A lot of people are now used to thinking about information architecture as the navigation, and where things live and how they relate to each other, but what is content strategy? Why are so many people suddenly realizing its importance?

Karen McGrane: I think so much of web design and development is approached as just that: design and development. What does it look like and feel like? What are the technologies we'll use? How will we code this? There's been this third leg of the stool, the content, that we've never really talked about, or we've treated as somebody else's problem. We say, "Oh, that's the client's problem!" or, "We're going to come in, and we'll do a redesign and put in a CMS, and that will solve everyone's web problems!"

The truth is, technology and design alone don't solve many of the problems, and often that approach doesn't even provide a good experience for the user. Really, what the user is there for is the content: all of the templates and designs and performance and navigation don't matter if the user doesn't say, "I have a reason for being here. I had a question and the content helped me."

Two forces that have driven us here, I think, are the development of content management systems and the rise of social media and social marketing. Businesses are now saying, "We've tried to put in tools to help us support content creation, but now we need to create ever more content to support our social channels." It's gotten so complex and difficult that people are starting to wake up and say, "Content is way harder than we thought it was. What are we going to do to solve that problem?"

Jeff Eaton: You just spoke at the Web Content Conference in Chicago about some of those issues; one of the buzzwords that's been getting a lot of attention lately is adaptive design. How does that relate to this problem of content complexity?

Karen McGrane: If I look back at the last 10 years in this field and think about how we've tried to educate the outside world about what the web means, we've tried to explain what a messy world it can be. "This isn't print! You can't put words on a page and print them in ink, and say they'll always look just the way you wanted." We've spent a lot of time trying to educate people about browsers and operating systems, and the fact that you can't achieve absolute control from a design perspective.

There's been a lot of work done with web standards around that, and now people are talking a lot about "responsive design." What do you do from a design standpoint to make sure that your site can adapt itself to someone viewing it on the desktop, or on a handset, or a tablet? How do you make design choices to reflect different screen sizes, different layouts, and different device capabilities? That's really important, and I'm glad that there are smart people talking about that, because it's brilliant. Ethan Marcotte’s fantastic book Responsive Web Design was just published by A Book Apart.

What I want to talk about is what has to happen on the content side to support that. Too often, when people talk about web standards or they talk about responsive design, they talk about it in terms of what has to change visually. They don't talk about the fact that things also have to change in the content. If you're making decisions about how much space you have, and how your design should adapt itself to that, you should be making decisions about the rest of your content, too. "How can I prioritize? How much should I say in this context? How much depth should I go into when someone can only see so much?" It's the same kinds of challenges: you can't predict how big a screen someone is reading your content on, you don't know what platform they'll be using, and you have to start making decisions about very abstract things. What's a title? What's a short description? What's a summary? What's the full text of my article, and how do I use those different pieces effectively in different contexts? How do I “atomicize” my content so it can be served up in different ways, in different contexts, for different devices?

We've made huge leaps forward in design and front-end coding to support that, but I don't think our content practices have kept up. The problem isn't the feature list of your content management system, or the APIs it's using. Technology can solve that, but we're not talking about the human side: the editors, the writers, the creators. We need to work with them and ask, "What do you need to create and manage content for this crazy, splintered new world?"

Jeff Eaton: Do you have any advice for people who are just starting to tackle this problem? Are there any easy wins for people who are trying to tackle both the design and the content aspects of the problem for their own sites?

Karen McGrane: My main advice would be, "Now!" Now is the time to start separating content from form. For real. We've been talking about this for so long, but too often we still think about our content in terms of where it's going to live on a web page rather than what it means. "Oh, this is the sidebar content!" No, it's not. It's related or ancillary content, or it's navigation, or it's a pull quote. It might live in the sidebar now, but that's just where you happen to be placing it right now.

Mobile has convinced a lot of people to start thinking about this. It isn't the end-game, but maybe it's the wedge that can get you into the conversation. Look at your site on a handset, on a tablet, on the desktop, and talk about the differences between them. Ask, "What do we need to do from a content standpoint to support delivering what matters to all of those devices?" That's not a technology problem at all; it's a strategy problem. We need to talk about how to communicate effectively in the different contexts, and about whether our content model supports it. What are the essential content objects we deal with? What metadata do we need to organize them effectively? What are the rules that our business has around them? Unless you're asking those higher level questions, unless you're thinking about it at that level, you're going to be caught off guard. You'll be designing for today's hot platform, but it won't be the hot platform in the future.

There aren't a lot of easy wins! There are a lot of thorny questions, but the businesses that really dig into them now are set for the future: this problem is not going away.

Jeff Eaton: You've been talking about these problems and some of the solutions at quite a few events this year — in fact you're just finishing a six-month, six-city tour of the country. Do you have any tips for other travel junkies?

Karen McGrane: Oh, I've got lots of them! The first thing you should do is sign up for some kind of virtual assistant service. I use Fancy Hands, and there are others ones out there, too. Here's the thing: They search Google for you. There are all kinds of questions you have when you're traveling all the time that boil down to, "Where do I go for the best..." and "I'm in a new city, how do I solve this problem..." Just email them the problem and they reply with answers: it's so much more efficient. I can search Google myself, but when I'm traveling like that, I don't have time to hunt.

Second, having a really good suitcase is probably one of the most important things you can do for yourself. Don't skimp on your suitcase purchase: it's not the time to economize! Get a great one.

Third, the most efficient way to pack is to roll your clothes. Don't fold them, roll them up into cylinders! You can fit all kinds of things into your suitcase if you do that. If you're living out of a suitcase for six months, you want to bring as many shoes as possible: they're your best friends and you'll miss them terribly, and you'll fantasize about them when you're not with them. Pack efficiently, and you can bring more of your friends with you.

Comments

technology and design alone don't solve many of the problems

Right on! A big problem I see is getting buy-in from clients on this approach. They are used to a certain website development process - a way designers (et al.) have trained them to follow over the years - and it's taking time to change that.

The second big issue I see is that good content is expensive. The resources involved can be daunting for some organizations. So even if you can get buy-in on the value of content strategy, you have a second challenge - making the case that it's worth the investment.

I wonder if there are any resources on making the business case out there?

re: "good content is expensive"

"good content is expensive"

...as are good design and good development. :-P

Content is rarely the focus of web redesigns and this often leads to massive budgets being used to create incredibly attractive "containers" (and of late, attractive and 'responsive' containers).

Responsive design should really be paired with adaptation/curation of all the relevant content (text, images, media etc.). This is by no means simple (certainly there is no CMS that enables this out of the box...) but needs to be the long-term goal to ensure we can pair the most appropriate layout(s) with the most appropriate context(s)...and content.

Making the case for content

Yeah, making the case for content strategy is no easier than any other investment: it's about presenting the rewards of planning for a project's future, and the potential consequences of ignoring that work.

At the Confab conference earlier this year, Karen dedicated an entire presentation to "Selling content strategy" -- there are several great writeups of the session online. http://www.suiteseven.com/blog/2011/05/selling-content-strategy-karen-mc... and http://www.barbariangroup.com/posts/8275-confab_session_wrap_selling_con... in particular are standouts.

If you're interested in the Content Stretegy/business intersection, you should definitely make it to Do It With Drupal for Karen's session! ;-)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p>
  • Lines and paragraphs break automatically.

More information about formatting options