The Things We Make and Do

Link to Article

by Erin Kissane on July 28th, 2011

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:

1. They force us to standardize our processes
2. They document some aspects of the work we do
3. They help us sell our ideas

To understand the distinction between making and doing, let’s step through those functions, one at a time.

Process organization

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.

Selective documentation

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.

Persuasion

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.)

GOING DEEPER

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.