Why pay if you can get it free?
One of the main challenges our profession faces is the proliferation of good documentation that’s free. Management increasingly will ask why they should pay us if the same product is available at no cost.
And let’s admit it – sometimes (dare I say “often”?) the free documentation is better than what we charge to produce.
A cautionary tale
There are many examples of free documentation. Let me tell you just one recent story.
I wanted to quickly learn the basics of a particular DTP tool.
I downloaded a free 30-day trial version along with the documentation, launched the application, and dutifully clicked the Tutorial link.
The link blinked. I had the uncomfortable sensation that it was winking, taunting me. Nothing else happened.
A computer re-boot later, it was the same story.
Okay, I thought, I’ll fall back on our profession’s favorite nasty motto: RTFM.
Well, presumably the manual covered the basics, but I’ll never really know. Because it covered so much, in such excruciating detail, with endless cross-reference links, and with poor search capabilities.
There were other “out-of-the-box” types of documentation, some of which required downloading specific applications. None was of any use.
The obvious solution
Increasingly frustrated and with a looming deadline, I called my favorite computer troubleshooter – Leora Livneh. She suggested today’s obvious solution: “Google” the product name along with the word tutorial.
She specified one caveat: Don’t look at anything that’s provided by the company that produces the product, since it typically isn’t worth much. “Don’t take this as an insult to your profession,” she said. Naturally, I immediately took offense.
As if she had waved a red flag, the very first thing I did after receiving a wealth of promising tutorial links was to click on the one with the company’s URL.
There were tons of tutorials. None explained the product version that I needed. Red-faced, I resolved never to tell Leora about not having heeded her one warning.
Getting back to the search results, my preference was for a video tutorial. After tweaking the criteria, the search engine displayed a digestible list of hits.
While checking out the most promising links, two annoying obstacles took turns flashing on the screen: Download a specific player (again!), or everyone’s favorite error message – file not found.
Eureka!
So I went back to the search and selected a text-based tutorial series – one not provided by the tool’s producer.
Over the next couple of days, I did the introductory tutorial procedures, read the concise overviews provided at the beginning of each section, and dipped in and out of areas that were of particular interest.
After investing several hours, I got a handle on the basic concepts, tried out the most important features, and glimpsed the more advanced capabilities.
I would have gladly paid the company to get the effective introduction that I found for free.
Morals of the story
What lessons can we learn?
First, in trying to provide documentation for everyone, we sometimes serve no one.
We need to build into documentation systems the capability to tailor the content for the user. A few simple questions about the user’s level (beginner, intermediate, advanced, upgrader) should result in focused information.
The technology is available now. We should use it widely.
However, just using fancy new delivery systems does not guarantee any better results. The tutorial I used consisted of simple HTML text files with a few links and a couple of illustrations. But it was what a beginner needed, and the language and content consistently reflected that.
On the other hand, the newfangled systems provided with the product, which required downloading new applications, had neither intuitive user interfaces nor sufficient search capabilities.
A standard browser search engine yielded reasonable results in a few clicks. The documentation we provide, which is much smaller and more focused, should be easier – not more difficult – to search.
Video: Promise and pitfalls
While video is an attractive and in-demand training method, it can be tricky.
The costs and time involved are usually significantly higher than for other solutions.
The costs increase even further when we produce sufficient variations to satisfy the needs of the different levels of our audience – as we should.
It is also challenging to ensure that the video is compatible with a variety of players. Few things annoy users more than clicking on a video link and getting an eternally rotating circle or an overly enthusiastic message to “Just take 30 seconds to download SuperDuperPlayer and your video will start automatically! We Promise!! REALLY!!!”
Raising the bar to provide video content is not a free pass to let other stuff slide, like maintenance, usability, and accessibility. It just may make those things more costly and challenging to provide. A careful selection of video and graphic tools should take these crucial issues into consideration.
Making the business case: Free and easy
There’s no turning the clock back to when our users were a captive audience. I doubt that they were happier then, either. They were just more frustrated since if they couldn’t find the answers quickly in our documentation, they felt totally stuck.
On the contrary, we need to argue that happier customers are more likely to stick with our product, use the upgrades, and purchase other products that our company produces. Informed users are a business asset.
So we should convince management that it makes sense to pay us and then make our documentation products free and as easy to access as the other information that our customers find useful.
Our challenge is to provide information that is even better than the material that’s currently generated for free. When we demonstrate that this helps keep our customers loyal, management will be more than happy to pay us.
Note
There are many types of free information, such as user groups. Please share your thoughts on their specific problems and potential.
I dunno, I’m always a bit sceptical of free blogs…
By: David on May 21, 2009
at 2:01 pm
Good piece, Yisrael. I’m glad to see you shaking up our assumptions, especially where a little shaking is in order.
User communities have been filling in the gaps where commercial software vendors fail probably since the 1980′s days of Usenet. With the Internet explosion in the mid ’90′s, user-provided documentation became, in my view, the normative means of offering guidance that the user community could actually rely upon. First with listservs, later with Deja News, and then Yahoo Groups, and now Google Groups, Wiki’s, PHPBBs, social & business networks and so on, users have become the frontline providers of the accessible documentation of decent quality that’s so often lacking.
I agree with your statement that “Informed users are a business asset.” However, the joy users get from documentation comes, more often than not, from an “outside the box” source. For a “micro” model, look at the local (Israel) technical writing community built around Techshoret in the mid- to late-90′s. The traditions and norms for mutual assistance that we take for granted today originated — to a large extent, I believe — from that set of experiences. This often took the form of writing what were essentially documentation mini-modules requested by list members finding themselves frustrated by an absence of available and comprehensible documentation in whatever software products they were trying to use.
To extend that model back to the present, MS Office 2007 deployment is a case in point. Suppose I’m dabbling in, let’s say, Excel 2007. If I wanted to find out how to execute a basic function via the UI, I might look up the answer in the MS-provided online Help. But if I wanted to do something “heavy” like figure out how to code a macro, you can bet my first port of call would be to see what’s been posted on Google Groups. That decision is based on the simple economics of anticipating, based on prior experience, that I’m more likely to get a good answer there quickly than if I poke around in the Help screens.
The problem with convincing management to pay institutional technical writers to provide what user groups are generating for free is fourfold. Beyond the monetary aspect that you mention, you’re struggling against long-established traditions of mutual assistance that end-users have set in place over what’s now stretching into decades! What’s more, nowadays, the ease of accessibility and sheer vast quantity of content that’s out there make us “institutionals” ever more hard-pressed to justify our existence. That is unless beyond adopting tools, forums, and whatnot, we begin inculcating amongst ourselves a professional mentality that regards the end-user’s perspective as foundational to guiding us in determining what and how we write. So you hit it right on the head when you remind us that the stuff we generate has to be as “free and as easy to access as – as and better than — the others.”
The end-user’s key requirement is for a ready source of answers to the issues affecting their everyday work. They don’t want to have to strain too hard to get those answers. They want those answers now … fast & easy are the watchwords. And they expect it for free.
By: Dave Egyes on May 21, 2009
at 2:29 pm
Thanks for another incisive comment, Dave. Your summary of how free documentation developed and why it has become so indispensible is very interesting. I agree with you that we need to liberate ourselves from the old assumption that the users are dependent on our services – as you point out, they haven’t been for quite some time. We need to get them what they need, when they need it, more accurately and more easily accessible than the material produced “non-institutionally.” Either we undergo this paradigm shift, or we’re consigned to the same fate as the typing pool…
By: Yisrael Woolf on May 21, 2009
at 7:44 pm
I strongly recommend that Tech Writers spend about 20% of their time, on a regular basis, performing QA tasks within the company to truly get a feel of the product. The company gains on two counts: 1) The TW gets a real feel of the product and can write about it with the user’s hat on. 2) QA is done on the product by someone with a completely different skillset and mindset, thereby discovering new bugs and enabling the TW to recommend enhancements to the product.
By: Leora Livneh on May 22, 2009
at 6:52 am
Thanks for the suggestion, Leora.
As you point out, dedicating time to testing the product contributes to better documentation and to product improvement. Both are crucial to enhancing the technical communication field in our companies.
Technical communicators should also set aside time to monitor relevant user groups.
If points that are being raised are missing from our documentation, we should insert the missing information in the next release.
If the info IS in the documentation, we should figure out why the users could not find it (and fix it, of course – not just mumble RTFM under our breath…).
By: Yisrael Woolf on May 24, 2009
at 2:48 pm