Technical Writing – Why Providing Every Answer May Not Be Ideal

It’s a technical writer’s job to write manuals and help files. It’s their job to protect expensive helpdesk staff from users who just “won’t read the darn manual.” But where does that job end? Does a completely comprehensive set of documentation solve everyone’s problems every time? If not, why not?
People aren’t like computers – and even computers get confused
The average household computer can conduct an astonishing number of calculations per second, millions and millions in fact. Sadly people can’t in the same time our processing power is limited to a decision or two, a quick scan of a sentence maybe, nothing more.
However even computers can get lost, with the massive increase in storage and memory there’s more and more data for them to review. Looking through all the non-essential data to find the stuff that’s needed right here, right now started to take up lots of time.
So the clever chaps in information technology gave them an index, it’s called cache memory and it was for a limited amount of time a big deal. Because computers with cache memory outperformed those without, now every PC uses a variant of this it’s not such a selling point and attention has moved away from it in the sales cycle.
But back when it was new and fresh many people wondered why there wasn’t more of it, for every megabyte of ram only a few kilobytes of cache were added. If it made things faster why wasn’t there loads of it? Well there were two reasons, the first was cost when it was first added to machines cache memory was really expensive. But the second was technical and obvious, the bigger you make an index, the longer it takes to read – if your cache was the same size as the memory you had, it would take exactly the same time to scan through as the memory itself would and become worthless.
This situation sums up why technical writers can’t include everything, the document is an analogy for computer memory – it’s where you store all your data. The cache is the index. The more you store, the more time it takes to look for that information and users don’t want to wait they want a solution now.
This means that as a technical writer if you include every solution to a niggling problem, and every possible workaround you’re starting to fill your manuals beyond your audience’s capacity to process and when that happens, they ring the helpdesk.
So the trick is to find balance, if you apply the Pareto principle (which states that 20% of your efforts usually achieve 80% of your objectives) you know that you need to concentrate on common issues in your technical writing. The one-offs and unusual instances that you may discover as an expert in using your system can go into the documentation for the help desk, there is after all a reason that helpdesk staff can’t normally be replaced by manuals.
If you do this then your users will be happy, most of them will never call for assistance and those that do will be glad they don’t have to call everyday because you drowned them in information.