Hockey Sticks and User Assistance: Writing in Times of Resource Constraints

Take Them Out at the Knees

In a perfect world, we could estimate the effort our work will require with great precision and tell folks exactly what we can do and what we can’t do. This kind of project-planning rigor would make compromises of scope and quality easier to calculate. Unfortunately, few of us have the data to manage our technical communication process with that kind of precision. But even in an imperfect world, we can do predictions along these lines: “I don’t know what our exact capacity is, but it is less this year than last—or isn’t keeping up with increases in demand—so we have to cut back somewhere.”

And that’s where the hockey stick curve comes in. You must decide how complete you can afford to be and how good the work needs to be, making sure you keep resources on a project or task only as long as they are on the steep part of the hockey stick curve. So let’s take a hard look at how we can compromise scope and quality in managed ways.

Scope

First, evaluate your documentation suite: Is every document needed equally? I emphasize the word equally, because I assume they are all necessary—that’s why you included them in the documentation plan in the first place. But, for example, would the negative impact of dropping the Quick Start card be the same as dropping the online Help or the Administrator’s Handbook? This can get tricky, in so far as you have to define and assess negative impact. Certainly product acceptance and customer satisfaction with a product are two important criteria, and you might have others that you want to consider as well.

Also, you must weigh criteria against each other. For example, a weak Help system might not hurt acceptance in the marketplace, but could be critical to day-to-day customer satisfaction or the reduction of support costs. A company with a stable installed base that faces high support costs might be more willing to throw the Quick Start card under the bus to maintain a high quality Help system. On the other hand, a new company trying to garner market share might value market acceptance more highly. Thus, they might be more willing to keep the relatively inexpensive, but high initial impact Quick Start card over the more expensive, robust Help system. Will both companies have to pay a price for their compromises? Of course they will, but such decisions are part of the business of technical communication.

Next, evaluate whether users benefit more from broad coverage or deep coverage. Readers of my columns on know that, as far as Help goes, my vote is for broad and shallow. I don’t know where users will ask for Help, but I know they won’t stay in a Help system for long; therefore, I need to cover a lot of topics, but not in great depth. On the other hand, specialized documentation might instead opt for in-depth coverage of a few critical topics. For example, a System Administrator Guide might ignore topics that are common to system administration in general—making the assumption that a system administrator would be familiar with them already—but provide in-depth treatment of activities that are unique to the product at hand.

Quality

For technical communicators, quality is perhaps the toughest thing on which to compromise knowingly. Given the opportunity, we would polish and revise a document forever. There is an old axiom that says, “There comes a time in the life of every document where you must shoot the writer and publish the damn thing.” A similar axiom comes from product management: “Better is the enemy of done.” The tough business question every writer must ask and answer is: “How good is good enough?” This is not heresy; the concept of levels of edit has been around for decades. A levels-of-edit approach defines differing levels of editorial rigor according to different levels of document importance. For example, internal technical documents are not edited as rigorously as customer-facing ones.

In general terms, the knee in the quality curve is that point at which the user quits noticing or caring. For example, I would hate to send out a document with words misspelled. Users are apt to notice spelling errors, and this would degrade their perception of product quality in general and the credibility of the documentation in particular. But I don’t know how much extra effort I would spend to get rid of incorrect uses of transitive versus intransitive verbs such as “An error message displays” or to get rid of comma splices. Am I saying the correct use of language is not desirable or is not important? Of course not. I’m merely trying to assess where it falls on the hockey stick curve. For example, let’s say we have several writers writing the topics for a Help system. Toward the end of the documentation cycle, we discover an inconsistency—such as one writer kept saying “Select the check box” and another kept saying “Click the check box.” Is it worth going back over several hundred topics to fix it? Wrong question! The better question is: which will return more value, doing that or moving on to the next project?

Conclusion

If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company—as in the market acceptance versus support costs example we looked at. When the answer quits being “Yes,” move your limited resources to the next item on your to-do list.

Finally, if you are a technical writer and the only resource you control is you, evaluate issues of scope and quality in your own writing projects. And keep a hockey stick handy in case someone tells you to “do more with less.”