Business Analysis Notes

UX for analysts

Goals vs. Tasks in Interaction Design

5 min read · Updated

In short A goal is the state a person wants to end up in; a task is a step on the way. Alan Cooper argues that confusing the two is the main reason software feels awkward, and that asking “what is the real goal?” often leads to a different, better solution.

Based on: A. Cooper, The Inmates Are Running the Asylum (1999), ch. 10.

On this page

Key ideas#

Goals are stable, tasks change#

Cooper’s illustration: someone traveling from St. Louis to San Francisco in 1850 and someone making the same trip by jet in 1999 share the same goals: speed, comfort and safety. Their tasks are almost opposite. In 1850 you took a rifle; today you leave it at home. Tasks change with technology; goals don’t. A design built around today’s tasks ages with the technology, while a design built around goals outlives it.

Why software ends up task-centered#

Programming means writing step-by-step procedures, so programmers naturally think in tasks. Cooper stresses that this is not a flaw, since good code needs procedural thinking. But when the interface is organized around tasks, connections that are obvious to the user stay invisible to the builder. In one of his examples, an office manager sees setting up and monitoring a shared office system as one activity with one goal: a smoothly running office. She gets two separate modules with two separate screens, because that is how the programmer split the code.

The goal hierarchy#

Cooper distinguishes several kinds of goals:

  • Personal goals are shared by everyone: not to feel stupid, not to make mistakes, to get an adequate amount of work done, and to have fun (or at least not be bored). Cooper puts these first. A system that violates them fails, however well it serves other goals. Not feeling stupid is, in his view, the most important and the most ignored.
  • Corporate goals include more profit, more market share and beating competitors. Cooper calls them hygienic, borrowing psychologist Saul Gellerman’s idea of hygiene factors: necessary, but they don’t motivate the person at the screen.
  • Practical goals bridge the two, for example “handle the client’s request” or “record the order”. The company benefits, but a person does the work.
  • False goals are imposed by the technology or the feature set and serve none of the real levels.

His practical conclusion: software that delivers business features at the cost of users’ personal goals defeats itself. An employee who feels stupid is not productive, so the corporate goal is missed too.

The principle of commensurate effort#

People will invest effort in learning a product when they see a fair trade: more effort for more reward. Cooper’s example is a TV with a thick manual. The complaint is not that the manual is long but that the set makes you feel stupid on day one. If it simply works at a basic level from the start, the owner will later happily learn the advanced features. The design lesson: provide a minimal working set out of the box and defer complexity.

How to apply it#

  1. Write the goal behind every requirement. For each feature or user story, record whose goal it serves. If you can’t name one, question the feature.
  2. Check personal goals explicitly. Ask: could this step make the user look or feel stupid? Could it lead to an error? Treat a “yes” as a defect in the requirement, not in the user.
  3. Keep goals and tasks in separate places. Corporate goals belong with business objectives, for example in a vision and scope document. Practical and personal goals belong with user requirements. Tasks belong in scenarios and solution requirements.
  4. Ask “what is the real goal?” before accepting a task as given. Stakeholders describe today’s tasks. Cooper’s cases show that the real goal often points to a different solution, not just a nicer screen for the same function.
  5. Define the out-of-the-box set. Agree which minimal set of functions must work with no setup, and which can wait until users are ready.

Review checklist#

  • Each screen or story names the persona and the goal it serves.
  • No step forces users to expose ignorance in front of others.
  • Error-prone steps are designed out, not covered with warnings.
  • Functions the user sees as one activity are not split across modules.
  • A minimal working path exists without configuration or training.

Example#

At The Workshop, a fictional chain of bike-repair workshops, the first draft requirement reads: “Front-desk staff can create a work order (14 fields).” That is a task.

The analyst asks about goals. The practical goal is to record the job correctly. The personal goals are not to look slow or incompetent in front of a waiting customer, and not to make mistakes that a mechanic will discover later. The corporate goal is more repairs per day and fewer disputes about price.

The rewritten requirement: when the customer gives a phone number, the system shows their bikes and past repairs. Only three fields are needed while the customer is at the counter; the mechanic completes the rest later. The customer’s goal, “have my bike working by Saturday”, also changes the booking page. It first asks when they need the bike back, then offers drop-off slots that make that date possible.

Pitfalls#

  • Listing tasks and calling them goals → keep asking “why?” until you reach an end state the person cares about.
  • Designing only for corporate goals → check what the same screen does to the person using it.
  • Accepting the current procedure as the requirement → ask whether the goal could be reached another way.
  • Front-loading every option → apply commensurate effort: basic value first, depth later.

Sources and further reading#

  • A. Cooper. The Inmates Are Running the Asylum. Sams, 1999, ch. 10.