The other day, I got to thinking about tasks and procedures. We had just remodeled our kitchen, and I was flipping through the user manual for our new dishwasher, looking for a section that walked me through the process of washing dishes from start to finish. But the user manual in my hands offered no such trajectory.
Instead, I found the procedures I needed sprinkled under headings that used a mixture of imperative statements (“Start the dishwasher”) and feature names (“Child Lock”). I found the procedure for adjusting the top rack under the heading “Rack Accessories,” the procedure for unloading the dishwasher under the heading “Loading the Dishwasher,” and the procedure for loading the silverware basket in its own self-titled section.
In short, the manual dumped a bunch of procedures at my feet and expected me to organize them into chronological order.
That’s when I started thinking about tasks and procedures—specifically, the differences between them. When I use a product, I have a task in mind: making a phone call, tracking my expenses, and in this case, washing dishes. Many user guides, however, treat procedures like my dishwasher’s manual does: Not as different phases of one task, but as tasks unto themselves.
But is there a difference between a task and a procedure, I wondered? And if there is, does that difference matter to users?
I did some research. According to two popular books on technical communication, a task and a procedure are one and the same.
In The Insider’s Guide to Technical Writing, for example, author Krista Van Laan writes, “As you develop task-based documentation, make sure you clearly define the starting point and the stopping point for each task. In other words, what is the first step the user does to start the procedure? What is the final step that indicates success? Use a consistent format to present each task–a description of the task and its purpose, a lead-in heading, and set of numbered steps are typical” (90). Ms. Van Laan uses “task” and “procedure” synonymously.
And in Technical Writing 101: A Real-World Guide to Writing Technical Content, authors Alan S. Pringle and Sarah S. O’Keefe write that “Procedural information consists of steps that tell a user how to perform a task. Because most content has a great deal of information about how to use a product, you’ll probably spend a lot of time writing procedural information, also called task-oriented information” (103).
So, according to these authors, procedures are tasks, and writing procedures is writing “task-oriented information.”
But a gentleman named Mr. Webster disagrees, and so do experts in fields that address people at work.
Here’s how the Webster’s Encyclopedic Unabridged Dictionary of the English Language defines both a procedure and a task.
- “procedure: 4. Computers a. the sequence of actions or instructions to be followed in solving a problem or completing a task” (1542)
- “task: 1. a definite piece of work assigned to, falling to, or expected of a person; duty. 2. any piece of work. 3. a matter of considerable labor or difficulty” (1945)
The definition for a procedure implies that a procedure is part of a task. And the definition for a task implies that a task is more involved than following one series of discrete steps.
People who study the field of ergonomics define a task as “a subunit of a job or the group of activities that accomplishes the work objective or job” (Work Rite Ergo: http://www.workriteergo.com/ergonomics/glossary/).
So a task might be a procedure, or it might be several procedures. But to a user like me, a task accomplishes a goal, and any procedures I complete are phases I walk through to get to that goal.
Why does this matter to us—and to our users? Because if we don’t understand the user’s idea of a task, we risk letting the product’s features determine the organization of the document.
That’s what my dishwasher’s user manual did. It’s as if the writer said, “Oh look! There’s that nifty upper rack. Let’s discuss its features and how to adjust it. And the Child Lock feature. That’s important; It needs its very own section.” Not helpful.
What would have been helpful? How about this: One section, or maybe just one procedure, that covered these items:
- Loading the dishwasher
- Adding detergent and rinse aid
- Selecting a cycle
- Selecting options like Child Lock
- Starting the dishwasher
But wait, you cry! Where do I describe the differences among the cycle settings, or when to use the safety features, and how to adjust the upper rack, and how to use the rack accessories like those nifty tines that flip up and down?
Here’s what I propose: Either put things such as cycle settings in a simple table beneath the related step, or put the table in an appendix and add one sentence to refer to it within the step. For example, “To choose the cycle, press Normal, Auto, Heavy, or Quick Rinse. For details on these options, see Table 1: Cycle Information.” A user can then either skim the table you’ve included or skip to that section for the information. If she doesn’t need it, she’s free to move on.
Before I etch my philosophy in granite, however, I want to know what you think: Are tasks and procedures the same thing? If not, what’s the relationship between them?
