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.
These included:
- Evaluating whether content is useful, valuable, actually worthy of being on mobile (or the desktop, for that matter)
- Assessing the amount of content that can appear on a “page” on different devices, and striking a balance for different form factors
- Creating multiple forms of headlines, teasers, or body text, so valuable information doesn’t get truncated randomly
- 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.
via planetweb
0 commentaires:
Enregistrer un commentaire