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

User Assistance

Putting Help in context

A column by Mike Hughes
January 22, 2008

Many technical communication departments are experiencing flat budgets, meaning they’re getting only small or no increases in headcounts, capital expenses, or training dollars. Worse yet, many departments are facing reductions in these resources. These reductions cause production pressures that are often confounded by increases in development headcount, here or offshore. Since more code equates to more features, which in turn drive greater revenues, companies are more willing to increase development budgets. On the other hand, adding writers increases costs, which in turn reduces margins.

How does this relate to hockey sticks?

First off, someone will inevitably tell you, “This year you have to do more with less.” When that happens, hit them with a hockey stick. What you do with less will be, well..., less! The point of this column is: If you are going to do less, you must make sure you are focusing on those things that add the most value. And that brings the hockey stick curve into play.

Champion Advertisement
Continue Reading…

The Hockey Stick Curve

One of the repeating patterns in the universe is the law of diminishing returns, and its graphic representation looks like a hockey stick. For a given change in an independent variable—in the case at hand, effort expended—there is initially a sharp increase in the dependent variable—results output. Then, all of a sudden, the curve flattens out. Essentially, you reach a point where additional effort does not give proportionately greater results. The point at which the curve flattens out is the knee.

Figure 1—The hockey stick curve
Hockey stick curve

This brings us to the central theme of this column: In times of tight resources, you must make sure that you commit resources—such as headcount, tools, training, and time—on the steep part of the hockey stick curve. Once you hit the knee, don’t put any additional resources, including your individual time and effort, on a project. Put them somewhere else instead.

In the rest of this column, I’ll examine what are the independent variables writers can control, and how they can manage compromises on those variables.

The Independent Variables

The independent variables most writers have some degree of control over are scope and quality. To our credit, these are two areas in which technical communicators are reluctant to make compromises. The bad news, however, is that when resources are tight, these areas inevitably get compromised. The only question is: Will the compromise be a managed one or an unintended one?

A managed compromise is one where something gets left undone, because you made a rational decision to leave it undone. An unintended compromise is one where something gets left undone, because you ran out of time at the end of a project. For example, a Help file might not include an index, because you decided creating one was too costly a use of resources, and users could use the search function instead. We might debate whether that was a good decision, but we can all agree that it was a decision based on thoughtful analysis. Or the Help file might not include an index, because you barely finished the topics in time for release as it was, never mind an index. We might debate whether that would cause a big problem for users, but we can all agree that it did not happen that way because you planned it that way; it just happened.

Let’s look more closely at what kinds of compromises writers can make in these two areas.

Compromises of scope entail not fully documenting a product or topic. Scope compromises can be structural, such as the index example I gave earlier, or they can affect coverage. Coverage compromises can have two dimensions. They can be

  • vertical—Documentation is shallow in detail, but wide in scope.
  • horizontal—Documentation is narrow in scope, but deep in detail.

Often, writers compromise coverage in both dimensions on the same project.

Two kinds of compromises in quality often occur: Compromises in the accuracy of information and in the correctness and consistency of language. Reduced headcount leaves writers trying to cover more topics than they have time for. This prevents them from researching source material as thoroughly as they would like. Other constraints such as access to product platforms can require writers to write documentation from screen shots or functional specifications. These kinds of constraints can lead to errors and inaccuracies.

Headcount reductions can further affect quality by their negative impact on the editing process, either by eliminating editorial positions or by reducing the amount of time writers have to edit the work of their peers. To paraphrase a popular ad tagline, one could say that editing doesn’t make new content, it makes content better. But in the cruel calculus of product-development economics, that equates—in the minds of some—to lower margins.

Next, let’s look at ways we can manage these compromises.

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.


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.


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?


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.” 

UX Designer at TSYS

Atlanta, Georgia, USA

Mike HughesIn his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement.  Read More

Other Columns by Mike Hughes

Other Articles on User Assistance Design

New on UXmatters