Task orientation is one of the most important principles of technical communication. But it is also a more difficult concept than it might at first seem. Part of the problem is the vocabulary of tasks.
When we urge writers to be task oriented, we usually contrast it to a different style, which we often call “feature oriented”, or “product oriented”. We say things like, “write about the task, not the product”, or “stop talking about the product and start working for the user”. All of this can make it sound like it is a bad thing to even mention the product and its features. This can lead writers to try hard to avoid framing any task in product terms. Consider this progression of titles:
The breakpoint dialog box
A classic feature oriented title. No hint of a task here.
Using the breakpoint dialog box
A cosmetic attempt to make the content sound task oriented. Chances are nothing has changed but the gerund in the title.
Okay, now we’re getting more task oriented. This is focusing on the user’s task. But, it still mentions the product feature. Hmmm…
Stopping the execution of your code
There, now we’re really task focused. No hint of the product in that one. It’s all about the user.
But wait a minute. If I’m a programmer, and I want to know how to set a breakpoint in your product, what am I going to type into the search box in the help, or look for in the index or TOC? “Stopping”? “Execution”? “Code?” No. I’m going to search for “breakpoint”.
The point is, task orientataion is not about avoiding the use of the names of product features at all costs. It is about helping users do their tasks. And since they bought your product to help them do their tasks, chances are, your product’s features are going to come up at some point.
In order to support the user doing their tasks, we have to use the vocabulary that they would use to describe those tasks. In doing this, we cannot assume that all users are complete novices who have not only never used your product before, but have never done the task before at all. The vocabulary that users use to describe their tasks actually comes from three sources:
Goal vocabulary: Some users express their tasks in terms of the goal that they want to achieve. These users are closest to the idealized novice that many tech writers assume they are wiring for. They don’t have any technical vocabulary, so they can only express their task in terms of their goals. But more experienced readers may also express some of their tasks in goal terms.
Craft vocabulary: Some users express their tasks in terms of the standard vocabulary of a trade. Programmers use terms like “breakpoint” and “linker” and “merge”. Technical writers use terms like “proofread” and “em-dash” and “metadata”. If you are writing about how to do the common tasks of a craft using your product, you should use the vocabulary of the craft (even if it happens to overlap the terms used in your product interface).
Tool vocabulary: Some users express their tasks in terms of the features of particular tools and products. Technical writers might talk about FrameMaker’s “Markers” or Word’s “Document Map” or oXygen’s “Grid view”. Long time users of your product are used to your product’s terminology and to avoid using it is simply to hide information from them.
Of course, not every user comes to your documentation with the same vocabulary. But to write as if every user had just fallen off a turnip truck, and had no knowledge of the vocabulary of their craft or of your product, would be to do them a great disservice. Task orientation is not about avoiding any mention of the product; it is about helping readers get their work done. The terms they use are the terms you should use. Even if those terms happen to include the names of your products features.
But no, this is not a licence to go back to descriptions of “The Breakpoint Dialog Box”. It is about giving readers the information they need to set breakpoints. But if that means letting the works “Breakpoint Dialog Box” slip out, that’s okay.