Tasks Are Not Goals

Goals are not the same things as tasks. A goal is an end condition, whereas a task is an intermediate process needed to achieve the goal. It is very important not to confuse tasks with goals, but it is easy to mix them up.

If my goal is to laze in the hammock reading the Sunday paper, I first have to mow the lawn. My task is mowing; my goal is resting. If I could recruit someone else to mow the lawn, I could achieve my goal without having to do the mowing.

There is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable. For example, to travel from St. Louis to San Francisco, my goals are speed, comfort, and safety. Heading for the California gold fields in 1850, I would have made the journey in my new, high-tech Conestoga wagon. In the interest of safety, I would have brought my Winchester rifle. Heading from St. Louis to the Silicon Valley in 1999, I would make the journey in a new, high-tech Boeing 777. In the interest of safety, I would leave my Winchester rifle at home. My goals remain unchanged, but the tasks have so changed with the technology that they are in direct opposition.

This same pattern of directly opposing goals and tasks is easy to find. When the president desires peace overseas, he sends troops armed with guns, planes, and bombs. His task is war. His goal is peace. When a corporate lawyer wants to avoid conflict with a colleague, she argues with him over clauses in the contract. Her goal is accord, but her task is argument.

The goal is a steady thing. The tasks are transient. That is one reason why designing for tasks doesn't always suit, but designing for goals always does.

Programmers Do Task-Directed Design

Too many developers approach design by asking, "What are the tasks?" This may get the job done, but it won't come close to producing the best solution possible, and it won't satisfy the user at all. Designing from tasks instead of goals is one of the main causes of frustrating and ineffective interaction. Asking, "What are the user's goals?" lets us see through the confusion and create more appropriate and satisfactory designs.

Boiled down to its essence, computer programming is the creation of a detailed, step-by-step description of procedures. A procedure, of course, is a recipe for accomplishing a task. Good programmers, of necessity, see things procedurally, or task-wise. Ultimately, the tasks must get done to achieve the business goals, but there are different emphases and different sequences of doing them. Only some sequences satisfy the user's personal goals.