Content strategy is about asking the right questions. Instead of starting with outlines or documentation plans, we need to step back, develop a content strategy, and then think about specific deliverables.I constantly get email along these lines:
- How do I justify XML (or DITA or a CMS or TCS or a wiki or really, any tool)?
- How can I use Flare (or RoboHelp or Doc2Help or ePublisher or whatever) to create a specific output feature (usually something that’s difficult or impossible to do in that tool)?
- What’s the best way to make my PDFs files pretty (or accessible or searchable)?
These are not the right questions. Let’s take a look at the questions that will help you establish a content strategy for technical communication.
1. Who is the audience (or who are the audiences) for your content?
Usually, we know the answer to this question, at least in theory. Even if you think you know the answer, spend some time researching this question. Does your audience have any common characteristics? (For example, you might be writing for enlisted military personnel, or web site designers, or accountants.) Do you know anything about how your audience likes to get their information?
2. What information does our audience need?
Another relatively easy question, at least compared to what follows. But explore this further…do you really know what information people need or are you working off a list of product features and assuming that you should document them?
3. What is the best way to deliver each type of information?
Here’s where life gets more difficult. Many, many people start with an inventory of the current software on their computers, and then determine the “best way” to deliver content based on the following:
When you have a hammer... // flickr: clearlyambiguous
- Current knowledge of tools and technologies
- Readily available software
- Personal preference
This is not the right approach. Instead, answer the question, What is the best way (not the most familiar way and not my favorite way) to deliver information to customers?
This is the point where I lose half my readers, who are yelling, “But I can’t get my company to give me new software!”
Fair point. It does not, however, change the answer of what would be best for your end users. Start with the ideal, and add constraints later.
So, what is the best way to deliver a particular type of information? It could be:
- A traditional paper manual, especially for restricted content in environments in which laptops, Internet access, and electronic devices are not available.
- A web-based configuration tool that lets the user filter down to the needed specifications.
- Help and other online content
- Forums, wikis, and other collaborative content
- Live video or screencasts
- All sorts of other things
It is a mistake to start a content strategy by making a list of all of the manuals and help systems that need to be developed. Instead, ask whether you should be developing manuals and help systems, or whether something else makes more sense.
4. What is the best way to create and deploy information in the chosen formats?
Beware the evil bulldozer // flickr: st3f4n
And here, in step 4, we finally get to talk about our favorite toys—the tools and technologies we use to create and manage content. Once you know what sort of content types you need, you can then backtrack into figuring out what process is best suited to develop the content.
Remember that your preferred way of developing content may not be the best way to develop the content.
5. What is the best way to address content management, updates, localization, reuse, and so on?
In addition to a plan for creating and deploying information, you also need a content management plan. Your organization may or may not require software for content management, but you do need to know how you will manage and version content.
6. How and when is content destroyed?
After you develop, deploy, and deliver, you may have to destroy. What happens when you release version 2 of a product? What do you do with version 1 content? In the rush to figure out how to create content, this issue is often overlooked.
Think of content strategy as a journalism exercise:
- Who needs our content?
- What content do they need?
- Where should that content be available?
- When do I create, deploy, and destroy content?
- Why does each piece of content exist?
- How can I create the most effective content?
Once you develop your content strategy, take a look at what’s actually possible within your organization. If it’s impossible to implement the ideal content strategy, what can you do to begin moving your organization in the right direction? Can you find ways to show that your strategy is working on a small, inexpensive piece of the whole, and use that success to get support to take another step forward?
Technical communication is no longer bound—physically or metaphorically. It’s time to open up the practice of technical communication to new content types, new collaboration models, and to a more strategic view of content.
All very true. Yet on Monday morning when I walk into the client meeting to talk about the new project, they’re going to say “We need you to create some PDFs.” It’s very hard to move managers away from that mindset.
It’s hard, but we have to try. Do you think it will make any difference if we start referring to ourselves as content strategists rather than as technical writers or technical communicators? Put another way, if I refer to myself as a content strategist, will that Monday meeting go any differently? Instead of saying “We need some PDFs,” might they say “Tell us how we can make our content work more effectively”?
That’s an honest question. I’m anxious to hear what others think.
@Larry: I’d say that not every company/client is mature enough to ask (or being asked) the right questions. Sigh…
We have to get out of that corner of self-pity telling ourselves that our boss doesn’t do this or see that. It’s more a matter of standing up and telling our boss or client: “Guys, if you want results, I deliver. But if you want GOOD results, I can work that out. Just let me do my job and stick to yours!”
@tbo: I see it as my job to prove to my boss why exactly this result is good (audience, information needs). Just telling them “Let me do my job…” will result in nothing, I suppose.
“Start with the ideal, and add constraints later.” I love this one
The correct questions proposed are the same questions I have always asked in a “Documentation Plan.” Maybe it can be called Information/Content Plan. I guess Content Strategy is the new buzz word. Looks like the content of these types of plans vary depending on one’s training and experience.
@Larry: Is it possible that the term “technical writer” carries sufficient negative connotations that simply rebranding might be effective? I don’t have an answer, either. I do believe, though, that it is critical for us (whatever we call ourselves) to move away from a tools-first approach. THAT is not the path to success. I also believe that a lot of content will move into delivery methods that fall outside the traditional book/help approaches.
@tbo: I agree that there’s been too much learned helplessness.
@Ben: That puts you in the extreme minority. Most documentation plans I’ve seen have a definite book/help mindset.
@Ben: For me, the content strategy answers the big picture questions: “What do we want to do, and why?” The doc plan answers the tactical question: “How will we do it?” The doc plan has to support the content strategy. But they’re not the same thing.
I’ll have more to say about this in my soon-to-be-published guest blog article at DMN Communications. You’ll find it next Monday (Oct. 25th) at this location: http://www.dmncommunications.com/weblog/
I agree with Larry – the doc plan is not the content strategy. I also don’t think all tech writers become content strategists. In my experience, the vast majority of tech writers are just that, and the title is appropriate. It is the rare tech writer who is willing to step out of that book paradigm and consider what we deliver in the larger realm of content strategy. Rather than repackage everyone as a content strategist, I think we need to repackage those documentation leads, project leads into content strategists. One person, stepping back to take the larger view, and developing a strategy that is then executed through the doc plans and the tech writers.
Excellent post. I’d like to comment more on the other comments than the post. The idea that technical writers execute a doc plan without considering the larger picture is ridiculous. If so, you’re a dime-a-dozen technical writer. A good technical writer examines the audience, the deliverables they need, the timeframes they need them, and so on. Technical writers are content strategists because we produce content. Have we been going about it unstrategically all these years? I think this is a buzzword that merely recasts technical writers in a new light. I have a post on this coming up — not so much the semantic debate as merely what the core criteria or strategies that content strategists/technical writers should consider.
Just a tip, but rather than using @ replies you could implement threaded comments. That way replies would appear below the appropriate comment you’re replying to.
This is a great article and highlights some of the advantages and disadvantages of this “Content Strategy” tag. I recently guested an article on DMN Communications blog (http://www.dmncommunications.com/weblog/?p=2195) where I highlighted the issue of job titles and their relevance to content strategy.
@Tom “Have we been going about it unstrategically all these years?”
Based on everything I’ve seen in my career, I think the answer to that is “yes” about 80-90% of the time.
It’s my experience that most people focus on their available/preferred toolset, and then figure out what they can do with those tools to deliver tech comm. I am asking them to take a step back and really think about their requirements instead of limiting themselves to what their favorite content-development software is capable of doing.
“Let the users do it” may be a reasonable strategy for some information. That assessment needs to be part of the overall content strategy.
[...] core competency of any technical writer/communicator. In Sarah O’Keefe’s recent post on Content strategy for technical communication, the questions she asks about audience, information, deliverables, timeframes, formats, etc., are [...]
I added my take on the whole content strategy question here: Why Help Fails. Particularly see the end as a follow-up to this thread.
I agree that many tech commers don’t spend enough time in strategy mode and are more comfortable jumping directly to tactical mode.
@All re: differentiating content strategy from content tactics, it is definitely important to view information/content as a company asset and not dismiss content strategy as the latest tech buzz.
In terms of tactics, I think it is a matter of framing tech comm goals using the non-tech comm terminology of the people we’re working with. I have been getting lightbulbs to go on with Marketing and Web folks, when I talk about online help development like website development. With Engineering/Dev folks, I draw out the parallels between content development and software development, for example:
Just as there is a software development lifecycle, there is a content development lifecycle with similar phases.
Just as development codes for machine systems and their related constraints (operating systems, processing speed, etc), we code for human systems and their related constraints (accessibility issues, processing speed, etc).
In terms of clarifying business requirements vs functional specs, no one would hand the development team a business requirements doc specifying “the Widget feature must be written in 32-bit .NET and must call a javascript function 5 times” (the Dev equivalent of “we need PDFs”). The dev team creates the functional specification, designing the “how to implement” based on analysis and consideration of technical constraints. So should the content development team. We must get our team mates, colleagues, and managers to differentiate between what the user needs from a business perspective, the correlating info requirements (SME input), and then let the content development team design the best communication solution that addresses the requirements.
But that just relates to content tactics (requirements & execution). If we step back and address strategy first, as Sarah and other strategists recommend, then we begin to see the continuum of our organization’s content and the arc it should be taking from creation to maintenance to end of life. For example, when your org is selling a product to a Prospect, the marketing pieces highlight business pain points and persuasively define how product X solves them. The Prospect decides to become a Customer and now Users (with those same pain points but not involved in the sales process/ related info) must use the system. What is the strategy to ensure the UI text, User Assistance content, knowledgebase, etc. recognizes the business pain points and coordinates to quickly solve them? If the information continuum is never discovered, then Help (or deliverable X) is doomed to failure and continues to be the place of last reference, as Tom’s post highlights.
At the risk of being a pariah, the article title is on `content strategy’ and the article mostly discussed delivery decisions and audience analysis. Am I missing a definition of `content strategy’?
Alas, but in 20+ years of practice delivery for me has been straightforward. If you set up carefully you can deliver nearly anything with about the same LOE so there’s never been a need to think about what was “best” or “easy”.
Similar logic applies to the audience. In a world where most of the audience doesn’t even grok what a `document object’, DITA Topic or XML container really is, the rest of the audience analysis is somewhat irrelevant. If I set up carefully, then additional audience analysis doesn’t tell me anything – other than that particular type of audience still doesn’t understand the solution.
So… my difficulty has always been ‘setting up carefully’. What are my content objects and how do I get the audience to use them? Any thoughts on that?
Thinking 2 moves down the chess board, the obvious response would be to say that if I determined the “best” delivery mechanism and had a better “audience analysis” then setting up content objects would be much easier. Which still doesn’t tell me about to do it, but never mind.
Been there, done that. Any other thoughts? From where I’m at, the solution keeps getting back to correctly defining content objects in the first place.
@David: No plans to shun you. At least not for this.
I think it’s worth noting that my definition of the “content for which you need a strategy” extends beyond topics. For example, we’ve seen several cases this year where companies are rethinking datasheets. Instead of delivering static PDFs, they are delivering HTML versions or, in one case, abandoning the “datasheet” concept entirely and switching to a web-based configuration tool that accomplishes the goal of getting users the information they want. Just not as a traditional datasheet.
In other cases, the strategy might be to set up a wiki and let the users create/contribute content.
Those are both examples where the design decisions go beyond “how do I create reasonable topics?” In some cases, the strategy might include questions like, “Which content do I develop and which content does the community develop? How do I support them in doing so?”
Audience analysis is important in determining content/level of content, but also in thinking about best or preferred formats. Military pilots in a cockpit need different information delivery than a World of Warcraft gamer at home.
Your question, “How do I get the audience to use my content objects?” is really interesting. The first part of the answer is that your audience has to find your content. Unless your information is regulated or restricted, that probably means making it available to the general public and, more importantly, to Google and other search engines.
I am in the process of creating a content strategy white paper, which will delve into this topic in more detail, so stay tuned. And thank you for jumping into the conversation.
This whole trend is fascinating because it continues to highlight the inadequacy of the term “technical writer” to describe what we do. I admit that I’ve seen many yes-sir type of technical writers that you describe. The PM says, I need a manual, and the technical writer produces a manual. If that’s how we’re defining a technical writer, as a take-orders lackey with some writing skills, then I wouldn’t consider myself a technical writer. I’m more of a content strategist/information architect/instructional designer/information designer/content manager/web designer type of person. I know that a lot of tech writers aren’t like me. A lot of tech writers don’t question whether we’re delivering in the right format, what the audience’s true needs are beyond what the PM says, etc. So maybe I’m just a lot more “strategic” than what I’ve allowed my job title to reflect.
This still goes against everything I’ve been preaching about what a technical writer is and does. In my latest podcast, Technical Writing Is More Than “Click This, Select That”, I argued that tech writing is only a fraction of what technical writers do. They also do all of these other roles too — ID, IA, AV, CS, and so on. Maybe I’m wrong. Maybe all a technical writer does is write. If that’s the case, I need to change my job title and the focus of my blog. If that’s how we’re defining it, technical writing is drudgery that I wouldn’t recommend to anyone.
I know this sounds like a cheap shot, but I noticed that you recently rebranded your site’s home page to say “Content Strategy for Technical Communication.” Unless I’m mistaken, that’s a new branding. Are you doing anything different that you didn’t do in the past? Are you starting to now think strategically about all the tools you’re recommending for clients? Are you just now starting to analyze your audience? Are you just now starting to question whether the format is working for your communication needs? If so, congratulations. I’m glad you finally made the transition into asking these types of questions.
I say this with sarcasm, because I know you’ve been addressing those questions and issues all along. That’s why I think the content strategy branding is just a new term for what the good technical writers/consultants etc have always done.
@Tom: Once the strategy has been set for a particular product (or product line), there definitely needs to be some “churn it out” type of writing. So, not all tech comm needs to be strategic all the time.
re: cheap shot/rebranding
There are a couple of things converging here.
1. “content strategy” is clearly gaining traction as a buzzword. We’ve struggled for years with explaining clearly what we do, and that phrase describes it as well as anything.
2. I’m not above jumping on the bandwagon.
3. There *has* been a change in what our customers are asking for over the last five years or so. Before that, our customers were looking for tools experts — “we need someone to build a FrameMaker template… write some XSL-FO ….” We still have those requests, but we are now getting a lot more questions about strategy. That is, customers are bringing us in earlier in the process to figure out what they should be doing. (We’ve always had opinions about whether their strategy made sense or not, but were usually brought in after the big-picture strategy was set. Now, we’re showing up to help set the strategy.) Our branding reflects that we want to encourage this.
4. So…I would say that it’s our customers that are thinking more strategically.
@Tom: It’s been clear that the role of TW has been changing since the dot bomb craze, if not sooner. I knew TWs in a 1980s start-up that tested and debugged code better than the engineers, tho perhaps a start-up is not typical.
@Sarah. I thought about my question (‘How do I get the audience to use my content objects’) after posting and decided it wasn’t quite broad enough. The issues I’ve really struggled with for 20 very odd years revolve around `How do I get the audience to identify, manage, and use the objects which represent their own problem space?’
There’s opposition at each stage. The biggest problem may occur before stage #1, with simply getting folks to recognize that their problem space can be analyzed as a set of objects to begin with. It’s psychological. Everyone wants to see their stuff as unique, so naturally their unique stuff can’t be reduced to reusable objects. Shades of Descartes and Reductionism, but never mind. Folks like seeing their stuff as new and creative.
I don’t maintain that _everything_ can be reduced to objects. Only that reducing the 80-90% of the stuff that can easily be so reduced frees up brain cycles to enjoy the 10-20% that’s much more creative.
Now all I need to do is write a book about this….
If you look at the history of tech comm, this discussion about the term content strategy is exactly the same discussion that occurred when people started to promote the term “technical communicator.” Apparently the STC used to be called the Society of Technical Writers and Publishers, but they changed it in 1971 to the Society for Technical Communication to be more inclusive of the various types of media and techniques technical writers were using. (See this article for reference.)
From 1971 until today, as time has marched on, there have been more and more methods for communicating instructional material: screencasts, elearning, podcasts, interactive tutorials, online help, quick reference guides, dynamic help, context-sensitive help, and so on.
Additionally, the tools market has exploded. You’re not just choosing between Robohelp or something else; you have at least 50 different tools and methods to choose from. DITA or wiki? Author-it or Flare? Sharepoint or something else? Online help or PDF? Collaborative tool or CMS? Screencasts, elearning, or flash embedded in PDF? Lots of choices and options.
The result? With more options, there’s also more confusion and a greater need for strategy in the beginning. What tool? Why? Depends on the audience and purpose? There’s a greater need to step back and ask the larger questions rather than just diving into tactics.
The way I see it, content strategy is a natural next step in the evolution of the profession, which started as technical writing. Writing is much more than we do. It then evolved to technical communication. But communication is more than we do. Now it has evolved to strategy. There are still many professionals stuck in phase 1, just writing manuals. There are many professionals engaged in phase 2, creating both manuals and elearning and perhaps illustrations. There are professionals engaged in phase 3, deciding on the right format and message for the audience, writers, and company.
It seems like just last Summit, Kathryn Burton was announcing that we finally changed the name from technical writer to technical communicator in the Bureau of Labor and Statistics Handbook. That new definition now seems inadequate to describe what we could/should/would do in our current roles. Here’s that new definition:
One could argue that with the terms “develop and design,” one is doing some planning and strategizing about the audience and purpose. But it’s not called out in a direct way. Maybe it’s not done much at all.
I’m curious to think about the next step after content strategy.
[...] sure we know where they are so we deliver assistance and training in their preferred channels. We shouldn’t start with a technology and make our strategy fit it. We serve our audiences better if we remain open to various avenues of communication, even using [...]
[...] Strategy”. A lot of the discussion (for instance this from the web content angle, or this with technical publications glasses on) seems to centre around what exactly content strategy [...]
[...] a comment on the ongoing thread on Sarah O’keefe’s Scriptorium post on Content strategy for technical communication, Larry Kunz, who played a part in earlier distinctions between the term technical writer and [...]
I’m finding the various conversations going on right now about this topic very interesting. It sounds like we’re all agreeing by disagreeing–it seems like everyone is saying that we (or someone on our technical writing team) needs to be thinking strategically. And in many cases, we (or someone on the team) have been, it’s just not been called content strategy.
I agree that as long as someone is doing that, what the title is probably shouldn’t matter. However, I would argue that a change of title could help chip away at some of the preconceived notions about what techwriters do and what they are capable, notions that can stand in the way of doing both the strategic and the tactical right.
When – about 20 years ago – I trained to become a “technical editor” they told us: “You are now learning to do a job about which everybody thinks he can do it, too.” We (in Germany) have gone a long way since then: Now we have job ads saying for a “technical editor” instead of “assistant for manual writing” or something like that. But still there are a lot of people out there who think they know better … it sounds like most of them are customers …
My way to handle that is: Explaining. If the customer wants PDFs and you think he’s wrong: Explain why you think he’s wrong. E.g.:
PDF presents information in “serial” way – very good for explaining mechanisms but bad for contextsensitive (GUI) help, because the user needs to quickly find info about a very specific part of the product/GUI.
In a PDF searching and finding specific words is a lot more difficult and time consuming than in a hypertext help, because you can only look up one word at a time.
The job title and the tasks usually correlate with the size of the employing company: Are you working in a big firm? Then you’re bound to have a pretty narrow scope. The smaller the company, the more widespread the duties.
The “technical writer” you’ll find in big firms with a big CMS. There they have only a tiny scope to work on (content- and knowledgewise) and others do the pre-structuring and the programming to produce the output. The TW has a fixed working environment that supplies him with x functionalities and templates and not a single one more. Sometimes they’re not even able to bold letters or decide whether a bullet list or a table should be used …
As soon as you have to think about layout or which information to give in what form and in what place you’re not really a TW anymore, but move towards “technical communicator” or “technical editor”.
Content strategy is definitely a part of the job of a TS or TE – as is the choice of appropriate tools. We just did/do that: We are working on a new documentation concept including content strategy. The rough outlines of the concept were enough for us to chose the tool. We decided to buy a tool with various output formats to be able to react more flexible to changes of operating systems and other technologies …
The documentation concept is in the prototype phase – we learn a lot from working on the prototype, so it will probably take another x years. I don’t really have any idea on where it will take us …
It is even more difficult when the company is not even asking these sort of questions about the *product*, instead they just throw some “stuff” together that may meet the customer’s needs. And then say “can you document this”.
Asking who it is for and how they should use it is futile as no one has given any thought to it.