For the last several months, I’ve been working with Krista Stevens (Executive Editor, A List Apart), Ethan Marcotte (author, Responsive Web Design), and Brain Traffic’s own Erik Westra (Director of Media and Events) to build Contents, a new magazine for content strategists, online editors, new-school publishers, and everyone else obsessed with content online.
The village that it takes
Contents isn’t a Brain Traffic project, but at every step of the way, Erik and I have been inspired, grounded, and supported by our friends and colleagues here.
On one side of the building, two-thirds of our leadership team is immersed in the final stages of writing and revising the second edition of Content Strategy for the Web—and another of my colleagues is editing it as they go. Across the office is one of the co-organizers of the Minneapolis-St. Paul CS Meetup. Down a couple of steps toward the kitchen, Erik is laying the groundwork for Confab 2012. And in every room, on every conference call, and in every meeting over bagels and coffee, my colleagues are building the future of content strategy on real-world projects for clients around the globe.
Ultimately, client work is the heart of our company, and in the eleven months since I joined Brain Traffic, I’ve seen a lot of fantastic projects created and launched. It goes without saying (or it should) that our client work benefits tremendously from the shared work of the larger content strategy community, the members of whom are tirelessly creating these events and publications and resources.
For me, at least, it’s impossible to do either client work or community building well without plenty of exposure to the other. And maybe it’s because so many of us started out as writers and really love to blog, but the CS world seems to understand the importance of that symbiotic relationship more than any fledgling discipline I’ve seen before.
What’s coming up at Contents?
In the coming months, we’ll be publishing columns, articles, interviews, conference reports, product reviews, and more. Some will be practical and focused on tools and techniques. More will focus on expanding our understanding of the work we do, and to create connections between fields we still think of as separate worlds, but that have much to share with each other: content strategy, but also digital data preservation, library science, new journalism, communication theory, and many others.
As Mandy Brown put it in her article for our first issue, successful communities require two things: “a place to gather, and things to talk about.” And we clearly have a lot to talk about—have you seen us on Twitter? With @Contents, we hope to provide a place—an equivalent, maybe, to the auditoriums and conference-center hallways where our community comes together in physical space.
In the end, this is about you. Our doors are open and our writers are smart, curious, and excited to share what they’ve learned. We hope you’ll come in, grab a coffee, and join us.
Last week, a designer I know tweeted about his contempt for people who talk about consuming content. His point was that the conflation of many different kinds of interaction with many different kinds of content does a disservice to our users. It’s a good point, and brought up a gap in my professional vocabulary that often annoys me: For practical reasons, I often need a term that expands the idea contained in the verb to read to cover content read aloud by a screen reader or provided as an audio or video file.
Listing the appropriate verb for each media case gets old fast: “after they read or watch or listen to text or videos or audio files on their computers or other devices” is enough of a mouthful the first time through. Consume is a convenient umbrella term, but I won’t lie—it makes me flinch a little bit every time I use it.
Before I go further, a little background information. Back in the day, I had a blog about the evils of jargon and euphemism. It was probably read by about 25 people, but it gave me a place to publish brief, fiery sermons about the evils of using leverage to mean “use” and rightsizing to mean “layoffs.” Ten years later, my work has shifted from writing and editing content to developing editorial and publishing strategies for clients, but I still strike those terms from every document I touch, and words like solutioneering still give me the clammy sweats.
Consume content falls right on the line between terms I can grit my teeth and use and terms that make me want to rinse my mouth with bleach. And it does seem a bit silly to use consume when nothing is actually being removed or destroyed in the process. If you read a paragraph of text, the text is still there when you’re done. YouTube videos don’t evaporate after watching. And over-general terms for user behaviors always have the potential to obscure the complexities of specific interactions and encounters.
The notion of consuming content comes from the language of economics, wherein some of us produce goods or services and other groups consume (buy, use) them. The jargon of consumer and consumption isn’t new—John Locke introduced the term in 1692, and “conspicuous consumption” was already a hot idea in 1899. When Emerson wrote in 1860 that “Every man is a consumer, and ought to be a producer,” he wasn’t speaking only of the making and buying of material things. In the old world of publishing, we could speak of the producer-consumer relationship in terms of texts: publishers published and readers read, and that was the end of it.
Now that magazines and even books may include not only text and illustrations, but video and audio features and enhancements, the language we use needs to accommodate our reality.
Experience and absorb were the most frequently suggested alternatives, with assimilate and enjoy following closely after. Eating and drinking words were also enormously popular: you suggested devouring, ingesting, imbibing, quaffing, gorging, digesting, grazing, chowing, and slurping. Our field’s weird obsession with cake and bourbon is no longer a mystery.
As the results continued to come in, it became clear that some of us imagined alternatives to consume that included only the process of taking in information, whereas others considered consume a synonym for the larger process encompassing intake, understanding/ synthesis, and use. As the tweets settled, I made a Wordle image of the results, and then spent a little time breaking down the implications of the frontrunners.
This is what happens when you ask for synonyms at lunchtime.
Experience: This is probably the closest thing to a medium-neutral alternative to consume that covers the … experience … of reading, watching, and listening to content. I’ll admit, though, that I find it too vague to use in my own work.
Absorb: We already talk about absorbing information—and when we do, I think we’re implying both intake and the beginnings of understanding or synthesis. And if we are, that means we’re assuming that the content is working, in a sense. If a site user reads a paragraph of educational text, but doesn’t understand it, can he be said to have absorbed it? Maybe.
Assimilate: Same connotations as absorb, with extra Borg-flavored deliciousness.
Enjoy: I really like this one, but it’s heavily dependent on context. We might expect our audiences to enjoy a feature film or an essay, but a lot of the content we handle simply isn’t meant for enjoyment. In the last few years, I’ve worked on content projects for a museum that focuses on the Holocaust, for a children’s hospital, for a human resources site that eases the process of managing employee benefits, and for a physicians’ association. “Enjoy” is obviously out in those circumstances.
My favorite suggestion of the day was the simplest: use. I like use because it highlights the difference between using a website (or mobile app or …) and using the content contained on that site (or app or …). If I visit a medical reference site, watch a video, and make a healthcare decision based on what I’ve learned, I’m using that content. If I skim a page of copy about a product that I then choose not to buy, I’m using that content as well. When I watch a YouTube compilation of Maru’s finestbox-jumps, I’m using YouTube, but am I using the content itself? Maybe not. Either way, I think use is a good concept to have around as we discuss the ways in which our users encounter and interact with the many kinds of content we publish.
At the end of the afternoon, I was left with a big stack of semi-synonyms, a heightened sense of the small but important differences implied in the words we choose to talk about user behavior, and a growing certainty that the topic isn’t remotely settled. I’m a fierce advocate of clarity and precision, but even I have to admit that precision of language is a virtue only when it improves our communication. Talking around important ideas helps no one, and there’s a fine line between righteously rejecting empty neologisms and being unhelpfully fastidious about our language.
So is consume content one of those clunky but necessary terms we genuinely need to express an important idea, or just a way of avoiding the precision and specificity of thought required to make responsible design and strategy decisions? I think it depends on how we use it. When it stands in for careful consideration of specific use cases, we’d do better to replace it; when it lets us speak about a new class of uses as a class, it’s both useful and appropriate.
The kids are all right
Earlier this week, I saw five smart, articulate presenters introduce new-school publishing tools, projects, and ideas to an audience of readers and creators at General Assembly in NYC. Three of the five presenters talked about consuming content without a flicker of embarrassment, and they did so as a way of collecting our multifaceted reading/watching/listening/browsing/using experiences under a single term that serves as the content-specific equivalent of using a website (or tool or app). Inherent in their work was a serious consideration of the many specific interactions between human and content that make up the user experience.
There’s always a risk that our focus on high-level systems and categories will obscure the attention to the specific, often messy details that make our work genuinely useful to real human beings. But if we’re going to make big, ambitious things, both registers—the abstract and the super-concrete—are essential. As long as our language reflects the full scope of our work, I think we’re going to be fine.
If you’re new to content strategy, or if you’re thinking of hiring a CS person or an agency to help you deal with your own content, you’ll probably be tempted to spend a lot of time looking at the documents we call “deliverables.” Deliverables are concrete, which is reassuring. They’re also repeatable (in theory), so looking at documents for one project should tell you something about the kinds of documents required for another project.
It’s easy to focus on the concrete and the repeatable—sometimes to the exclusion of other aspects of content strategy work. But the concrete things we make don’t always reflect the whole of the work that we do.
Things to Make and Do, Volume 9 of a 1970s edition of Worldbook’s Childcraft encyclopedia of awesome things. Volume 9 is, objectively, the best. Note well the hypnotic effect of the paper-plate dragon.
Image credit: Awful Library Books
Documents on the brain
In the last few years, the content strategy community has begun to standardize on a central set of documents, and we’ve been thinking and talking about them … a lot.
And that’s fine, as long as we maintain perspective on what deliverables really are, what they’re not, and how they fit into our work as a whole. It’s easy to conflate what we produce with what we do—to confuse CS documents with CS itself.
Deliverables are great. Especially those that are repeatable in form, if not in content. They can save us tons of work reinventing the basics. They help us scope projects, teach new practitioners, and reassure clients that their money buys something they can touch (and write on with a ballpoint).
But they’re still what we (visibly) make, and not what we do.
Deliverables accomplish three main things:
They force us to standardize our processes
They document some aspects of the work we do
They help us sell our ideas
To understand the distinction between making and doing, let’s step through those functions, one at a time.
Standardized documents—those we carry from project to project in one form or another—tend to impose repeatable processes. If we’re going to deliver a competitive analysis document, we’re going to have to … analyze the competition. In an orderly way that makes sense when set down in crisp black toner. And if we’re going to deliver content audit findings, we’re obviously going to need to audit the content.
This stuff gets much more nebulous as we move into vaguer document descriptions like “high-level content strategy recommendations,” and that’s because those processes really aren’t as repeatable. Each client’s strategy must be built from scratch, and although we can decide to arrange our recommendations in standardized ways, their actual contents will necessarily be unique in every project.
Documents communicate our analytical, synthetic, and creative ideas to other people so that they can evaluate and use the ideas themselves. They may also let us “show our work,” justifying our recommendations, explaining the steps in our analyses, and offering views of the data we’ve consumed along the way. But there are also scads of ideas, processes, discussions, and other kinds of brainwork that don’t make it into deliverables. Not in a recognizable way, at least.
For example, collaboration on work that “belongs” to other disciplines, from feature/interface design to microcopy, rarely shows up in CS deliverables. And much of the groundwork for high-level recommendations—things like audits, gap analyses, stakeholder interviews, and user research—should usually be present in deliverables only as brief summaries, lest decision makers be bored into a coma by too many spreadsheets.
There are usually other types of internal, non-deliverable documentation that track many of these different kinds of work, but by definition, those other forms usually aren’t public. For these reasons, looking at deliverables alone can produce a distorted picture of the efforts required to get to final recommendations.
Because we live in reality instead of a scholarly abstraction, deliverables must also help us sell our ideas to clients and managers. Excellent deliverables are persuasive … and persuasive in ways that are specific to the project and surrounding situation. No boilerplate allowed.
Of course, deliverables can’t be useful sales tools unless they’re a solid manifestation of our consultative work. Smart decisions don’t quite sell themselves, but smart decisions supported by concise explanations of the reasoning behind them are usually quite persuasive. Especially if the decisions and rationale are explicitly connected back to the goals and requirements everyone agreed on at the beginning of the project. (You did do that, right? Get everyone to agree on those basics? If not, start with this post.)
Deliverables aren’t …
Let’s flip it around for a minute and consider what deliverables aren’t. They’re not:
A replacement for good processes
A comprehensive record of our work
A substitute for the synthetic, analytical, and creative thinking and problem-solving that constitutes content strategy
If you’re trying to get your head around content strategy, either as a new practitioner or a client/manager, deliverable reviews can help quite a lot. But remember always that what you’re seeing on paper is the visible tip of a much larger and more complicated chunk of ice.
(And those slightly terrifying goggle-wearing seals that keep swimming under your boat carrying underwater welding equipment? Those are the content strategists. Don’t worry. They’re your friends.)
What does that mean, in practical terms?
If you’re trying to learn more about CS, or about the capabilities of a particular firm or practitioner, don’t just talk deliverables. Ask about process. Ask about philosophy. Ask to talk through completed projects and the results CS produced.
If you’re a new practitioner or someone who’s curious about CS, talk to people who work alongside content strategists, like designers and project managers. Talk to clients or managers who’ve seen a CS project all the way through. Think about all the underwater effort that goes into producing the shiny deliverables you can see and touch.
If you’re on the client/hiring side, remember that in the end, it’s not the deliverables or even the thinking behind them that matters, it’s whether those things produce results: whether they save money, make money, bring order to chaos, produce intelligence from messes of data, communicate ideas more effectively, prevent derailments, and meet the goals you set out to meet. And if you’re the one championing a CS project, a lot of that is under your control, even if you don’t produce a single deliverable.
Do all of that and no matter who you are, you’ll go into your next project with a much better understanding of what’s going on under the surface of all those painstakingly proofread deliverables we love so much.
Then Confab happened, and there were marketing folks and UX people and publishers and journalists and data designers all speaking and listening and drinking Lorem Sipsums—and there was way more PLUR in the house than I’d dared to hope for.
So I think we’re heading in the right direction. But before I move on from the hippie stuff entirely, I want to clarify some things from the last post. Starting with this whole UX business.
I Come in Peace
First, a disclaimer. User experience (UX) design is a field in flux. Its central terms are in dispute, as are the boundaries of the field itself. There are those who believe that UX design is something very specific, and those who believe that anything that influences a user who has an experience counts. Blessedly, I’m a specialist, so this is not my fight.
For the purposes of my own work and writing, I tend to think of UX design as a kind of design work associated with certain methods, processes, and values. It’s not limited to the web, or even (theoretically, at least) to the digital world.
I’ve spent most of my career working alongside fantastic designers and developers, many of whom consider themselves UX people. That’s my world, and I believe CS is and should remain a critical part of UX design work.
For a long time, I tended to assume that the only “real” content strategy was the kind of content strategy that took place within the framework of UX.
But it turns out that CS doesn’t belong solely to people who do it the way I do it: CS is not a synonym for UX, or even exclusively a subset of UX. And that’s because CS is in contexts and fields both within and outside the purview of UX design. (Using the working provisional pseudo-definition above.)
CS ≠ UX, Take Two
One useful way to think about the relationship between UX and CS may be to consider the relationship between UX and programming/IT work.
Some kinds of programming—notably front-end and UI development—are inextricably entwined with UX design. (Or at least they should be.)
Other kinds of programming and IT work, including a lot of back-end coding, IT architecture (virtual and physical), security, and a host of other activities may well support and be influenced by UX design choices, but aren’t themselves part of UX design. That doesn’t mean that IT work is more or less important than UX work, just that they’re different.
In the same way, a lot of CS takes place within the boundaries of UX design projects and processes. And a lot of it—CS that deals with enterprise-scale data design, the long-term management of publishing processes, old-school marketing/communications planning, and so on—also goes on outside those boundaries.
This Is a Beautiful Thing
My slightly muddled point in the original post was that people are doing CS work within higher education, mass media and publishing, journalism, information science, marketing, and plenty of other fields without engaging in anything that resembles user experience design methods.
And that this is not only OK, but excellent, because it gives us chances to cross-pollinate and learn weird new things and get better at what we do. Developing a big-tent CS community that recognizes the virtues of diversity and niche work benefits us all.
Where Do We Go From Here?
A lot of great posts appeared after Confab, including two from Jonathan Kahn and Sara Wachter-Boettcher, that discuss ways of moving ahead as our community continues to gel. From Jonathan’s call to arms:
Confab showed me that we have a community of people who are spending their time sharing and learning from each other about how to change their organizations so that they can start to get hold of the overwhelming problems associated with content strategy, web strategy, and web governance.
That’s amazing. What I learned at Confab is that all of us can and should do more to broaden the conversation, involve more people, start to get this change train moving. Brain Traffic and others have led the way: now it’s your turn. Start a meetup, host a work lunch, write a blog post, submit a talk to a conference.
Once you’ve established a bit of voice, it’s time for ears to take over – time to start listening to and collaborating with those people we fought so hard to let us in in the first place.
I’ve been super-lucky to work with content-savvy UX/design teams from the get-go, so I can attest to the benefits of close collaboration. And I think Jonathan’s quite correct to shoo us all out onto the streets to raise hell in our own ways.
I also want to suggest one more course of action: we need to be more aggressive about learning from smart content people who don’t work in the same ways and contexts that we do. And to that end, I have a proposal.
The Summer Blogging Challenge
Some of you may share my fond memories of the summer reading programs run by schools and libraries during summer break. Long, hot afternoons outdoors with a big stack of books are still my favorite way to experience the peak of summer, and I collected a lot of scratch-n-sniff stickers for my trouble.
It’s 100 degrees in New York City today, and I’m issuing a challenge. Between now and the end of August, in the spirit of cross-training, I challenge all of you who are practicing and learning about content strategy to read at least one book or blog series, attend a talk, or otherwise dig into an area of content strategy work that’s well outside of your own expertise. And then to blog about what you’ve learned and how it might affect your approach to your work.
And because I am still ALL about the stickers, yes, there will be (tiny, ridiculous) prizes. Comment here or send a note to @braintraffic on Twitter when your post is up to get in on the bounty. Southern hemisphere readers will receive especially fine (tiny, ridiculous) Winter Blogging Challenge prizes. Special awards will be given for the most prolific reader/poster; gummy rodents may be involved.
One of the things that's consistently difficult about governance—the long-term management of content—is keeping sufficient resources available after a site launches.
If you think finding people to write, review, and revise content leading up to launch is tricky … you're completely right. But it's still easier than keeping those people available later on, once the adrenaline rush of launch has subsided and the never-ending process of reviewing and improving site content has kicked in.
One thing that helps is a set of good tools:
A style guide that genuinely supports your culture as well as providing clear mechanical guidelines;
A CMS that supports your workflow and makes publishing easier;
Page tables or content templates that clarify the fundamental purpose of each major piece of content.
But tools only work when there’s someone to use them.
People are really, really busy
The people who have the subject-matter expertise required to create and maintain content are often some of the most overworked employees in any organization—which is saying a lot, given the larger corporate trend toward over-commitment.
Content work—and especially online content work—is more often presented as an "extra" job for subject-matter experts and anyone else expected to contribute content whose title isn't "web editor." And when the work is presented as an extra task that isn’t central to employees’ job descriptions, it tends not to get done.
So although most content strategists aren’t especially well versed in the management side of organizational dynamics, the problem of governance forces us to consider ways of reserving time, freeing up resources, and recognizing effort. And that’s why a video made by content strategy thinkers at Autodesk has cheered me up so much this week: it does so much right, and sets a wonderful example for dealing with this seemingly intractable problem.
Here’s the video:
What’s so wonderful about this approach is that the video itself is aimed at an internal audience. It explains the purpose and importance of the Autodesk content strategy initiative in clear, unpretentious terms and then goes a step further by breaking down the ways in which the efforts of people who contribute to the initiative will be recognized and considered as a part of their overall performance.
(The underlying content strategy is also based on what appears to be a very smart, disciplined system of measuring and refining content over time, but that’s another whole conversation.)
Dragging governance into the mainstream
The problems that this video addresses so directly have been around for ages, and we’ve all had to find ways of trying to resolve them. And because it’s not yet a given that organizations know they need to staff and support their online communications, many of our attempts have necessarily been workarounds.
For example, when a company really needs more people to handle content work, but can’t hire another expert, I’ve sometimes suggested hiring a part-time administrative person to help ease the burden of paperwork and free existing experts to spend more time on content. And a great web editor can often perform a certain amount of resource-allocation magic through sheer force of personality. But these are temporary solutions, not sustainable long-term plans.
By bringing the realities of content-related resource allocation into the mainstream of performance management, the Autodesk team has provided a clear example of simple ways of bringing content development and governance into the core of an organization. And their strategy was developed within, rather than being brought in from outside, which is a great sign. When organizations begin to understand content strategy at that level, the whole CS conversation can become more sophisticated.
Whether you do content work within an organization or as a consultant, you’ve probably bumped into governance challenges. So let’s talk. Are you finding it easier to explain the need for long-term content resources, or are things holding still for you? What kinds of strategies are working for you?
Every couple of weeks, one of my colleagues in the content strategy community wigs out a little bit about marketing people co-opting “our” terms and processes for their own (presumably nefarious) ends.
As a content strategist who comes from the world formerly known as “web design” (and now mostly called “user experience”), I’ve felt sympathetic twitches when I see these complaints. Not out of territorialism, necessarily, but I, too, dislike seeing the whole sweep of content strategy work reduced to “content = customer acquisition!” After all, we’ve fought to have content strategy recognized as a core component of user experience work.
So it was with this bias that I sat down, a few months back, to write a book. And one of the first things I had to work out was what I really meant by “content strategy”—and why I felt it didn’t rightfully belong to the folks with “social media marketing” in their Twitter bios. Along the way, I discovered something slightly upsetting, which is that content strategy doesn’t really belong to user experience, either.
Bear with me, UXers. You can put the diagram down for a second.
What We Talk About When We Talk About …
The thing is, marketing people talk about CS and mean “content strategy as it applies to selling things, building brands, and providing customer service in ways that make people want to buy more things.” A lot of this sort of content strategy revolves around distribution channels, messages, branding, and sometimes, editorial workflow. User-centered design principles may or may not be involved.
Enterprise content strategy people, on the other hand—the people working with data and DITA and knowledge management systems—talk about CS and mean data modeling, technical workflow, documentation, planning for content reuse, and content management, often on a very large scale. Their attention to customer service and support tends to be about increasing efficiency, reducing redundant effort, and achieving consistency. Again, user-centered design principles may be involved, but are unlikely to be a primary focus.
When people from the media world talk about CS, they tend to mean discussions of business models, distribution channels, and the development of content as a product, with secondary focus on marketing and customer service (unless they’re all Paul Ford). User-centered design principles may come up, but they’re far from the center of the conversation, which doesn’t usually get into the details of user experience.
And content people who come from or work in the UX world say content strategy and mean bits of all of the above, but with user-centered design at the core of the work. Product design becomes feature design; messaging and branding become content goals and style guides; data modeling becomes content templates and page tables.
But this sort of content strategy isn’t the One True CS. And even when we do it within user experience projects, content strategy doesn’t fit neatly within the usual boundaries of UX. Content strategy must often precede true UX work, as when it involves the organizational communication planning that must happen before a web design project can begin.
And, of course, all that messy editorial planning and workflow stuff tends to continue long after interface design and front-end development are complete. No other part of a UX project necessarily involves the implementation of long-term organizational practices (unless you expand “UX” to the IT resources that support systems over time, which is a stretch).
The Marmot Wars
You might think of each of these separate kinds of content strategy work as gophers, or maybe marmots. Each tunneling toward a cherished meadow as quickly as its wee marmot paws can manage, until, suddenly, it pops out into the open air—only to discover STRANGE OUTSIDER MARMOTS WITH WEIRD MARKINGS stumbling out of their own holes and blinking in the sun. And then you get the posturing and barking and little finger-snapping marmot West Side Story dances, and it’s all very tiring and no one gets a snack.
My point is not that the marmot-meadow is big enough for everyone, though it mostly is. The differing models of CS do sometimes come into competition, especially when clients aren’t quite sure what they need. User science people will probably never get along with the folks on the ad-world end of the marketing continuum, and editorial nerds will probably continue to underestimate the value of data wonks (and vice-versa).
But, we should nevertheless recognize that content strategy is a big, big world. It’s not just that we all have different specializations and approaches, though that’s true. Content strategy is a big ol’ loosely connected network of practices, and it doesn’t belong to any of us any more than graphic design belongs to advertising or project management to aerospace engineering.
I’ve met more than a few real, actual marmots, and let me tell you—we’re smarter than they are. So let’s give the rodenty turf wars a rest and try talking about content strategy in ways that admit the possibility of other useful kinds of CS work.
There’s value in looking beyond our industry-specific tunnels and expanding our own capabilities to include some of those other kinds of CS, so we have more to offer our clients when they need it. That’s one of the reasons I’m stupidly excited about Confab.
The fact that so many of the sharpest minds from the far reaches of Big Tent Content Strategy are all going to be in one place—and I don’t just mean as speakers, either—can only mean good things for the curious content specialist.
With rapid growth comes weird pressures and the potential for irrational infighting, and we are definitely in a spell of rapid growth. We need a gathering of the tribes. And I daresay we could use a big party, while we’re at it.
So I hope to see you there—or around, online—whether you come from social media marketing or the geekiest depths of the data-wrangling world, WEIRD MARKINGS and all.