Our Blog

The Things We Make and Do

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

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.

  • http://www.pybop.com Shelly Bowen

    Thanks, Erin, for putting deliverables in context! I so agree with everything here — not all projects/companies need all deliverables and so much of the strategy is delivered as conversations and metaphors and connections between people.

    One thing I’ve also noticed is that no matter how successful a particular deliverable has been for some of my clients, the format or “delivery” of this same information may be completely wrong for another client.

    The spreadsheet is a great example. Some clients go giddy over a well organized spreadsheet. Others refuse to even look at it. So we content strategists often have to get creative with effective, influential delivery.

    Thanks again!

  • http://www.pybop.com Shelly Bowen

    Thanks, Erin, for putting deliverables in context! I so agree with everything here — not all projects/companies need all deliverables and so much of the strategy is delivered as conversations and metaphors and connections between people.

    One thing I’ve also noticed is that no matter how successful a particular deliverable has been for some of my clients, the format or “delivery” of this same information may be completely wrong for another client.

    The spreadsheet is a great example. Some clients go giddy over a well organized spreadsheet. Others refuse to even look at it. So we content strategists often have to get creative with effective, influential delivery.

    Thanks again!

  • http://cdginteractive.com Jennifer Hoppe

    Excellent post, and a propos, as I just had a conversation with my boss about what should comprise content strategy deliverables in a given project. I also agree with Shelly’s comment that the method of delivery may vary, depending on the  temperament of the client. More often than not, a cogent executive summary is your friend!

  • http://doriantaylor.com/ Dorian Taylor

    Since most of the work involved in any of this stuff resides in our gaining comprehension, we can consider deliverables as both communicative interfaces to the client and receipts that we did something. The distinction reminds me of a remark Sterling made in his keynote at IDEA 2006: that which is interesting is not important and that which is important is not interesting. (NB: I’m inclined to splice “necessarily” into the appropriate spots of that little antimetabole.)

    For instance, to perfect the technique I’m working on to perform automated content inventories, I produced a number of artifacts, including a web-scraping program and a glob of RDF data which it disgorged. Neither of those are interesting to anybody but me. But both are enormously important.

    Ghetto-rig up another little script to turn the RDF into CSV files for consumption by a graph visualization app and massage for a bit and all of a sudden I find myself with something that is indeed interesting. Is it important? No. How can I tell? Because if I lost it I wouldn’t be screwed; I could just whip up another one.

    What is important about these interesting-but-not-important artifacts is that they be amenable to being understood, and therefore valued, by other people. I mean, really, we’re in the business of cogitating hard problems and reconciling arbitrarily many considerations. Deliverables are just part of the Kabuki. And yes, well-defined processes will generate well-defined classes of artifacts, though I wonder if we should consider that incidental to the information we are trying to expose.

    Anyway, I agree completely that focusing on the form of proximate deliverables belies the importance of their content, which is kind of ironic coming from a content strategist.

  • Chris Turner

    There’s something to be said for the value of studying CS documentation while donning a Reverse Engineering Cap (Patent Pending). If you take on such a review knowing that what’s on the paper hints at a larger dimension, there’s great potential to explore what goes on between the lines and behind the scenes. 

  • http://incisive.nu/ Erin Kissane

    Completely agree. In essence, content strategy thinking has to go into the process of making content (deliverables) for our clients.

    Turtles all the way down.

    Also, your “magic layer” in the post I linked above is still one of my favorite things of all time. Thank you for being awesome.   

  • http://incisive.nu/ Erin Kissane

    Summaries, graphics…whatever it takes to move the right information into the right heads. 

  • http://friendly-machine.com John Hannah

    As a designer/developer flirting with CS, I thought this was really helpful. I’ve taken a lot of what you’ve written (bought your book) and I’m using it to sell the adoption of a rudimentary CS at my day job.  Change is often slow. But many thanks for the continued guidance.

    Oh and the pic of the book was hilarious, BTW. 

  • http://incisive.nu/ Erin Kissane

    Dorian, you’re a peach.

    Kabuki tells stories, which are how we (mostly) learn. So there’s that.

    I’m interested in artifacts that imply (and jump-start) a whole world of processes—and also in the loss of detail and depth inherent in that handoff of information. (Viz polytheistic reconstructionism.) 

  • http://incisive.nu/ Erin Kissane

    YES. This is my great hope.

  • http://incisive.nu/ Erin Kissane

    It’s a wonderful book! In a slightly bizarre way. I loved it so much when I was about eight.

    (And thank you, and I’m so glad you found it helpful.)

  • http://doriantaylor.com/ Dorian Taylor

    I nominated Kabuki because of the schmaltz, but polytheistic reconstructionism looks like another good candidate.

    Please forgive me, I’ve been up to my eyeballs in cognitive/perception science, cybernetics and math literature for the last few months. It’s starting to make me think funny things.

    My favourite book on the subject of cognition and communication is Cognition in the Wild by Ed Hutchins, best read in conjunction with The Things that Make Us Smart by his buddy Don Norman.

  • http://twitter.com/GabbyAtConfab Gabby

    You make me so happy to be learning about content strategy!

    I loved your article, especially how you argue for not being rigid on what deliverables are needed. We need to be adaptable and understand the real purposes behind them.

    A certain someone is often in my ear about applying content strategy approaches and techniques to our deliverables. We should be as focused on understanding the user goals when preparing project deliverables as we are when crafting, say, a website’s content.

    Heck, you could go so far as creating things like personas, at least rudimentary ones, for each major project! OK, maybe that takes it a bit far, but I like the way of framing the challenge.

blog comments powered by Disqus