Responsive Design Won’t Fix Your Content Problem

I spoke to a digital team at a large corporation a while back, and outlined some of the many challenges they were likely to face in creating, revising, and publishing their content so it would work well on smartphone, tablet, and desktop interfaces.

Planning to develop alternate versions of some assets—such as different image sizes and crops, alternatives to large infographics or tables, new demo videos showing both desktop and mobile versions of the interface

Separating content from presentation in the CMS, so content and markup aren’t all dumped into the same blob of a field

An attendee raised her hand and said “I’ve been wondering when you would mention responsive web design. We’re going to use responsive design.” I responded “Well, responsive design won’t fix your content problem.”

Who thinks that, anyway?

I recently posted a link to an article that called responsive design a “poor man’s content strategy.” Then my Twitter feed exploded with people heavily sighing and rolling their eyes, insisting no one would ever conflate the two. Why, everyone knows that the container and what you put in the container aren’t the same thing. Everyone knows that just rearranging modules from the desktop to make them squishy is not a content strategy for mobile. Everyone knows if organizations discover problems that go beyond the specific layout solutions offered by responsive design, that’s not the fault of the technique.

Except not everyone knows that. These are just a few of the anecdotes I’ve heard recently from people working on mobile websites for major corporations—projects with large budgets, committed teams, and executive buy-in:

We recently finished a massive CMS replatforming which necessitated a redesign of the desktop website. There is zero enthusiasm for going back through the content structuring, editing, and approval process with our business stakeholders and our legal review team. Whatever we wind up doing on mobile, we must use the exact same content we have on our brand-new desktop site.

We just spent [insert unfathomably large number here] trying to take our existing desktop website and make it responsive. We genuinely believed this process would be faster and easier if we based it on what we already have. It’s not going well, and we’ll probably need to throw it all out and start over. We would have been better off if we’d started from scratch six months ago.

I was hired as a developer to build a new responsive website, but I’m being asked to make all kinds of decisions about how to edit and restructure the content—decisions I don’t feel entirely qualified to make. I keep telling my client they need to bring someone in to deal with the content questions, but they think responsive design is just a front-end design and development problem.

Our executives assume that since they made the decision to go responsive, every other decision would just be tactical details. In fact, implementing responsive web design raises issues that strike right at the heart of our business and the way we work. We need to fix our review and approval processes, our content management system, our asset management system, our design standards and governance. We need to clean up our outdated, useless content. But it’s hard to get people to step up to solve these bigger problems, because they don’t think they’re part of “responsive design.”

Seems like a lot of people are laboring under the mistaken impression that using responsive design means they can make a mobile website without dealing with their content problem.

Where’d they get that dumb idea?

We told them so. And, okay, yes, they’re using some magical thinking. But straight up, we told them that the mobile website should be the same as the desktop, and that’s why they should use responsive web design. We sold them on the value of responsive design by promising that they could manage and maintain one set of content and it would work across all devices.

We also insisted there’s no good reason to serve different content by platform. We got twitchy whenever anyone started talking about sending different content or less content to mobile devices (rightly so). We pointed out that you can’t discern user context or intent just from knowing screen size or device type. We told them content parity was the first and most important goal when developing a responsive website.

Is it any wonder they assume (hope?) they can just take what they already have, wave a responsive magic wand over it, and have their existing content automagically work on mobile? Why should it be different? We said it shouldn’t be.

Even companies that want to take a “mobile first” approach can’t just throw off the shackles of their desktop content. For some, suggesting the organization “start fresh” with new content would be organizational suicide, touching the political third rail of stakeholders and competing interests. Others acknowledge it’s time for a new approach, but need processes that will enable them to clean up and restructure existing content to make it appropriate for a responsive design. Responsive design won’t fix their content problem—but content strategy will.

Responsive design + content strategy = BFF 4 EVAH

It’s time we acknowledged that every responsive web design project is also a content strategy project. For designers and developers who might not know what to emphasize, here are a few talking points:

Your content must be revised

Even though the long-term goal is to serve the same content to every platform, organizations can’t just use what they already have. Smart companies will seize this opportunity to do what they should have done years ago: clean up and pare down their desktop content. You’ll never get a better chance to fix your content and publishing processes.

You may need to deal with legacy systems

The tantalizing prospect of responsive web design is being able to solve the problem of “mobile” completely on the front end. The front end is so much more malleable than the back end, so of course we want to start there. But many responsive projects require changes to the way content and data are structured and published from the CMS or other legacy systems. For some, an approach to APIs will be needed; for many others, it will be an overhaul of content management and asset management systems.

Design your editorial workflow first

The chicken-and-egg problem of content informing design (and vice versa) just got bigger—call it an ostrich-and-egg problem. While smart people have talked about the responsive design workflow and how design deliverables and processes must change, the editorial workflow also needs attention. Planning for how and when the content team will migrate, edit, and restructure content will help everyone ensure that the content and the design work together. Design deliverables like wireframes and comps are evolving—content teams must also evolve away from reliance on Excel spreadsheets and Word documents to manage this process.

You won’t have time to edit everything

Even the most dedicated and ambitious teams won’t have the capacity to revise and restructure every page of their existing desktop website. Making informed and realistic decisions about what to focus on (and what to punt on) will help with overall planning, migration processes, and design decisions. Acknowledging this early will help get teams and stakeholders on board with the fact that not everything will be perfect.

Plan for long-term governance

Responsive design also won’t fix your design standards and governance model, but we still need to include long-term maintenance in our objectives. I heard a story from one group who said they convinced their company that it wasn’t possible to do responsive design properly unless they also created and enforced a design system. The same argument could be made for developing and encouraging adherence to content standards.

Responsive design itself won’t fix your content—no one ever said it would. But the opportunity to implement a responsive redesign is also the opportunity to fix your content and its underlying strategy. It may seem more complicated to edit your content and fix your processes and systems at the same time you’re designing a new site—but in fact, pretending you don’t have to solve these problems just makes the job harder. Smart organizations will see this as a benefit, not a drawback, and will use this chance to make a better website, not just a squishy one.

About the Author

Karen McGrane plays nicely in the content strategy, information architecture, and interaction design sandboxes. She is the author of Content Strategy for Mobile from A Book Apart; Managing Partner at Bond Art + Science, a UX consultancy she founded in 2006; and formerly VP and National Lead for User Experience at Razorfish. She’s led projects for dozens of clients, including The New York Times, Condé Nast, and The Atlantic. She also teaches Design Management in the Interaction Design MFA program at the School of Visual Arts.

More from this Author

44 Reader Comments

More from ALA

Columns

The number of predictions that algorithms can make about us from even minimal data is shocking. Although we’re offered privacy settings that let us control who of our friends sees what, all our information and behavior tends to be fair game for behind-the-scenes tracking. We simply don’t know everything that’s being done with our data currently, and what companies might be able—and willing—to do with it in the future. Laura Kalbag believes it’s time to locate the exits.

Displays that are more tiny than our lowest-size breakpoints require a more condensed range of type sizes. If you don't already have in place a typographic system that can absorb the demands of this new context (watches, wearables, digital sticky notes, whatever), now might be the time to consider it. Matt Griffin was ready for anything because his site was simple and built to be future friendly.

March 19, 2015

From the Blog

It's all about us this week at ALA. From steps to sleep to social activities, we're counting every kind of personal data you can think of. But what's all that data add up to? How could we look at it—and ourselves—differently? In this week's On Our Radar, we ask ourselves—and our self—the tough questions.

That old monitor you've got lying around? Time to put it to work. Susan Robertson reminds us of how important it is to test our designs on older screens and ensure the things we build work well for everyone.

The future is here, for better or for worse—and this week, the ALA staff has been thinking about what that means: for our code (the impending arrival of HTTP/2), our content (publishing on Medium), and the cost of constant noise.

This week, the ALA staff is thinking about color accessibility, the process of building a vocabulary, the current state of web typography, and the lessons we can learn from skater culture. In other words: it's all about inclusion.