New things to learn

XVII.3 May + June 2010
Page: 75
Digital Citation

Intentional communication


Authors:
Kristina Halvorson

Design and content. Content and design. It’s impossible (and stupid) to argue over which one is more important than the other—which should come first, which is more difficult or “strategic.” They need each other to provide context, meaning, information, and instruction in any user experience (UX).

Despite this screamingly obvious interdependence in any online user experience, the two sit at opposite ends of the proverbial totem pole. Up top: design. This is “where the magic happens.” It’s a mysterious process, one in which art and science come together to create intuitive interfaces, compelling visuals, and flow. Superior design skills are perceived as rare and precious. Design is hard.

Content? Anyone can do content. You there. Typing. Do some content. See? Down to the bottom of the pole you go.

Design is perceived as a strategic undertaking, while content is the stuff we churn out ad nauseam, hopefully engaging at least a few of our users along the way. For this and myriad other reasons, design and content aren’t usually considered simultaneously in our project processes. Design first. Content whenever we can get to it. (As Peter Merholz once facetiously said, “Content is just an undifferentiated substance for me to pour into my design.”)

Whether you’re a practitioner or a project stakeholder, you may have noticed that this disconnect between design strategy and content creation can cause a few problems. See: 99 percent of online content.

When Content is “Someone Else’s Problem”

As UX designers, we regularly see the results of our efforts fall far short of our original vision due to poorly executed content. When content efforts are underestimated, last minute, and generally siloed from our design processes, we end up with either the subpar content we started with or new subpar content. And in about two seconds, that same subpar content can destroy our online user experience.

It’s not that we don’t care. It’s simply that dealing with content creation and governance isn’t something that has traditionally fallen within a UX designer’s jurisdiction. Don’t get me wrong. We’ve fought for process improvement. We’ve begged to have the writer involved earlier in the project. We’ve pushed for answers about content before starting to structure pages and moving toward visual design. And every time, there’s never enough time. Or not enough budget. Or people. Or concern.

Sometimes, we’re even encouraged to give up hope that things will ever improve. In Web 2.0 Redesign: Workflow that Works, Kelly Goto and Emily Cotler insist that “late content is consistently one of the biggest reasons for project delay. The task itself and the resources needed to complete the task are severely underestimated. Accept it. Plan for it. Charge for it.”

In other words, don’t bother trying to find a different way to do things, because this is a problem without a solution.

But UX designers are not a complacent bunch. Improving both on- and offline experiences is what gets us out of bed in the morning. In fact, for most of the UX designers I know, creating better experiences is more than a job. It’s a mission.

So it’s typically somewhat of a revelation for designers and developers to discover that they are, in fact, empowered to help fix the content problem. And that fix is content strategy.

Content strategy plans for the creation, delivery, and governance of content. It plots an achievable roadmap for individuals and organizations to create and maintain content that audiences will actually care about. It provides specific, well-informed recommendations about how we’re going to get from where we are today (no content, or bad content, or too much content) to where we want to be (useful, usable content people will actually care about).


How did the design community come to collective, tacit agreement that content is “someone else’s problem”? Is it beyond—or beneath—our design sensibilities? Is it simply out of our control? Or does the word “design” itself automatically imply “everything but content.”

 


We need to include content strategy as a mandatory part of any user experience-design project, both short-and long-term. Because, without clearly defined ownership of content-related outcomes, we’ll continually see our hard work rendered ineffectual by lousy content.

Thoughts on “Design”

How did the design community come to collective, tacit agreement that content is “someone else’s problem”? Is it beyond—or beneath—our design sensibilities? Is it simply out of our control? Or does the word “design” itself automatically imply “everything but content,” thereby excusing us from all associated responsibilities?

The dictionary’s definitions of “design” pretty much fall into these three categories:

  1. Visual design
  2. Design for form and function
  3. Planning/a plan for a defined, desired outcome

And, not by coincidence, these three categories are parallel with the disciplines that have traditionally fallen under the umbrella term of UX design:

  • Interaction design (function)
  • Information architecture (form)
  • Usability engineering (testing the outcome)
  • Visual design

You’ll notice, of course, that there’s nothing here about content. Which means there’s usually no one at the table when we’re designing for user experience. Which means no one is truly, deeply considering content recommendations and requirements. Which is precisely what’s causing the problems in the 11th hour of any Web project.

So, if “design” is the word we use, we need to work hard to expand the way we think and talk about Web and UX design to include, literally, the stuff we design for—the content.

Speaking of Content

The way we talk about content can begin to shift the way our project teams (and we as individual UX designers) approach the UX design process. We need to do more than just cajole and complain. We need to demonstrate specifically how our design templates implode because the imaginary content we created them for turns out to be different from the real stuff. We need to explain that the boxes on our site maps and wireframes can’t just be filled in by a copywriter. We need to be able to articulate exactly what’s going wrong in our content processes (or lack thereof); why and where it’s going wrong; and offer specific, actionable recommendations about how to fix it.

How can you change the conversation?

Don’t talk about content as though it’s just copy. “Copy” means words. “Content” means audits, analyses, Web readability, plain language, metadata, structure, life cycle, and more. It’s far more complicated and time-consuming than just writing. Make sure the client understands that content doesn’t just “happen.”

Ask who owns the content, and keep asking. The sooner someone steps up and takes responsibility, the more likely tough questions will be asked early in the project cycle.

Once you’ve identified content owners—the people who request, create, approve, publish, and oversee the content—engage them in conversation. You’ll often find that their experience and perspectives can provide much-needed context for (and sometimes even contradict) the viewpoints of your primary project stakeholders.

Semantically, even the phrase “content strategy” has an immediate impact on our perceptions of content (mountains and mountains of junk, a problem so big we can’t possibly begin to solve it). However subtly, “content strategy” begins to shift our take on content as a commodity—something easy to come by, undifferentiated—to a valuable asset worthy of strategic planning. So start saying it. Often.

Words into Action

Because we rarely have answers about the content early in any project—who owns it, where it’s going to come from, how much of it we already have and whether or not it’s even any good—we’re forced to make a lot of assumptions about the content, the fuel that will make our Web products go. Moreover, the content itself—what exists now, and what will be created—is rarely under our jurisdiction. So we can only hope that our carefully considered design will ultimately deliver useful, usable content to the right people, in the right place, at the right time.

The good news is that there are, in fact, processes and tools available that can improve our chances that said content will become a reality. Even better news is that these tools and processes are slowly finding their way to the UX design table as part of content strategy.

How can you integrate content strategy into your design process? It’s pretty simple, actually: Make content your problem.

If you’re designing an application, ensure that you create brand-appropriate voice and tone guidelines. Yes, you might be writing the copy as you go, which means you can keep things consistent. But if someone else has hired you to do the design, it’s likely that the copy will be rewritten or expanded at some point by someone who is not you. Define brand values. Demonstrate how voice and tone should embody those values. Create a usage guide to ensure consistent terminology and recurring interface copy. And, while you’re at it, make sure that content requirements are clearly called out throughout your technical documentation… including the error messages.

If you’re designing a website, begin with a quantitative audit of existing content. Ask what content people want; ask why they want it, then figure out if it maps back to business objectives and user goals. If it doesn’t, throw it out. Invite content owners to usability tests. When appropriate, test real content. Once user experience-design recommendations are complete, conduct a qualitative audit of your source content prior to completing a gap analysis.

Then, prior to finalizing content recommendations, work with the client to confirm that sufficient resources have been allocated for the creation and maintenance of that content. Otherwise, you’re handing over a UX strategy that can’t be fully executed, let alone sustained. And that won’t improve anyone’s experience.

How We Can Change

In a recent Q&A with Sparksheet’s Dan Levy, Jeffrey Zeldman said:

Content informs design; design without content is decoration. Content has the same relationship to design that product has to advertising. Good ads are based on the product; good designs come from and facilitate the content. This is one reason we bring content strategy to every design assignment, and one reason we insist on working with real content, not lorem ipsum (placeholder) content. Nothing is sadder than a beautiful design that works great with lorem ipsum but doesn’t actually support the real content.

Our shared goal, across all Web disciplines, is to create beautiful designs that prioritize, contextualize, and effectively deliver content that people want and need. That’s what the Web should be. And, as always, it’s ours for the making. Successful, collaborative design means making content matter, starting now. Think about it. Talk about it. Do it.

Author

Kristina Halvorson is the founder and president of Brain Traffic, an agency specializing in content strategy and writing for websites. Widely recognized as one of the country’s leading content strategists, she speaks regularly to audiences around the world about how to deliver useful, usable content online, where and when your customers need it most. Halvorson is the author of Content Strategy for the Web (New Riders, 2009), which helps to define the discipline and business value of content strategy, offering simple steps for introducing the discipline into the Web project process. She lives in St. Paul, Minnesota.

Footnotes

DOI: http://doi.acm.org/10.1145/1744161.1744178

©2010 ACM  1072-5220/10/0300  $10.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.

 

Post Comment


No Comments Found