Why Technical Writers Shouldn't Be "Writers" - Slides

Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.

Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)

The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.

What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?

Several people have asked for copies of the slides I used, so here they are.

However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."

If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.

Why Technical Writers Shouldn't be "Writers"

View more presentations from 4JsGroup.

Should Customers Pay for the Manual?

Yesterday a friend of mine posted the following on his Twitter feed

OMG! (Company Name) actually charges for their owner's manuals! That's absurd.

Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?

Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.

Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.

Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).

The total cost of ownership for both products over the normal operating span turns out to be just about the same.

Let's take a look at the two scenarios in more detail.

COMPANY A - Documentation Included

This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."

That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).

COMPANY B - Documentation Sold Separately

In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.

One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?

So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.

BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.

On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.

And the customers liked it too.