"Good Heavens! For more than forty years I have been speaking prose without knowing it."
Monsieur Jourdan in Le Bourgeoise Gentilhomme by Moliere
These days, the tech comm blogosphere, the Twitterverse, and the social media conversation is all about content strategy. All the buzz got me wondering how content strategy fits in with my day to day work as a freelance contract tech writer. Thus far, most clients have hired me to document specific features or modify legacy content to fit in with their documentation conventions and tools. Where does strategizing come in? Furthermore, how do I jump aboard the content strategy bandwagon? What the heck do I know about content strategy?
In talking with a former co-worker recently, I suddenly felt exactly like Monsieur Jourdan in Le Bourgeoise Gentilhomme. I've been speaking content strategy for years without knowing it!
As documentation manager for several start ups over my career, I have had to plan the creation and delivery of content for new products. I asked myself these questions for the company as a whole, the product, and the individual documents:
- Who is the audience and what do they need to know to use this product to do their jobs?
- How do we create the content and manage it?
- How do we distribute the content to the audience?
- What about feedback from the audience? How do we get it? What do we do with it?
You still have multiple audiences looking for exactly the information they need. In olden times, I used to divide the audiences for, let's say a platform (hardware, operating system, and applications), at the highest level into: people who buy the equipment, people who install and manage the equipment, people who install and manage the software, and people who use the applications to do their jobs. All those groups had different information needs. Content strategists for the web need to think about the same kinds of things. No matter what the application is, there are still people whose relationship to it requires different information. The software developer who is creating his application based on your API needs to know details of the programming interface. Other folks at his company need information on cost, digital rights, market penetration, and so on. The content strategist must make sure that all of those audiences can find what they need.
Content Creation and Management
You still have content creation and management to worry about. Who is going to create the content? The developers? A team of tech writers? The customers? A third party? You get the idea. A long time ago, in a galaxy far away I pioneered customer generated content, third party documentation, and content curation in the doc set for our platform.
Our product included a UNIX platform and our customers were mostly scientists who programmed in FORTRAN. So for example, rather than writing a UNIX tutorial, I selected the best available published book to ship with our UNIX platform. I did the same thing for the FORTRAN compiler. Why use my valuable resources to document FORTRAN when there were excellent books on FORTRAN?
Likewise, I engaged one of our early customers who was interfacing their own data acquisition devices to our platform to provide content about that because other customers were about to do what they had already done. My strategy had to accommodate incorporating their content into the overall doc set.
Third Party Documentation
In addition to buying off the shelf books, we also engaged a contractor to develop documents about various UNIX utilities. They were responsible for the production of finished books or booklets, which they could then sell to other clients in addition to us.
The big difference here is that where we could use a standard source control tool like SCCS to manage revisions and versioning and the Bill of Materials to manage what went into the box with the hardware, these days the content is broken into hundreds of small pieces that need to be configured for various types of output. Then we worried about help files and printed books, now we have to worry about web site content, maybe embedded help, mobile content, collaborative content like wikis, and maybe even PDF. The tools are more complicated, but it's still content management.
In addition to the output issues I mentioned above, today's content strategists also have to worry about free vs. paid content, open vs. proprietary content, and sometimes restricting content to paying customers. Click on the support tab of just about any major hardware/software provider and you'll see that some restrict access to the user documentation and some don't. Your content strategy needs to address those considerations up front.
Audience feedback has always been key to great documentation. The wonderful thing about social media is that it makes it a whole lot easier to get that feedback. Where once you had prepaid mailer reader comment forms in the back of paper books, annual or semi-annual user group meetings, Usenet newsgroups, and customer site visits, now you can get instant feedback via blogs, Twitter, Facebook, and any number of similar tools. Today's content strategist must integrate all these channels and have a plan for acting on the feedback.
I have been speaking prose for the entire play.