Why Goals and Tasks are the Same Thing (part 1)

This is an exploration into human intention/behavior structure, what we know about it, and how we communicate about it in order to design and engineer products and services that humans can use effectively.

Here is a prototypical goal/task diagram:

The terms “goal” and “task” are household terms, meaning that they are not necessarily esoteric linguistic tools. However, if you’re in the field of user-centered design, these terms no doubt carry higher significance in their usage and in their implications to your work. Chances are you have a pretty good notion of what these things are and how they are framed with regard to their subtle differences, namely;

1) Goals are high-level. Tasks are low-level.

2) Goals are abstract. Tasks are physically observable.

3) Goals are something a user has. Tasks are something a user does.

4) Goals do not change. Tasks do change.

Originating from the encouragement of Alan Cooper, many practitioners follow Goal-Directed Design, which has its basic tenants on the idea that you should begin building a product or service by first understanding users and their goals, and then design for those goals, and not necessarily for their tasks.

For example, Veronica the [insert role and persona information here] is playing music in her Lexus. We know that she wants to eject a CD from her stereo deck, from within a CD changer that holds several CDs. What she does that is physically observable though is she presses a sequence of buttons on the stereo interface, necessarily in that order, and waits several seconds for the desired CD to emerge from the thin slot it once had entered.

Following the objective of Goal-Directed Design (and if we were savvy), we would design for the goal- which is to retrieve that specific CD. We would NOT want to design for the task, which would consist of things like the following:

1) make the buttons she needs to access closer to her in proximity so that she does not have to ergonomically exert herself and take her focus off of her driving

2) make the buttons bigger and easier to press

3) have them light up and “click” when they are pressed to provide ample feedback for a successful press

Instead, we would re-evaluate why she needs to press these buttons, in that order, in the first place. It will be much better to rethink and validate the high-level needs and interactions for extracting her CD. Goal-Directed Design is a great way to run user-centered processes. It allows a team of designers to keep the user in mind and facilitates creativity and out-scoping so that the team will be less likely to be pigeonholed in one way to do something.

In other words, Goal-Directed Design protects a designer from putting lipstick on the pig.

The only questions are- How do we know that Veronica’s goal is to extract a CD? Did we assume it? Did we ask her? And if we asked her, can we be sure that she is rightfully aware of her intentions and reasons? Even if we were extremely confident that her goal was indeed to ‘get’ her CD, how do we know that she doesn’t have an even higher goal? What if her goal was to change the music that is playing by putting in the Carrie Underwood CD where her Sugar Hill Gang CD used to be in her disc changer? In that case, extracting Carrie Underwood is only a means to an end. Then, shouldn’t we be designing for that goal- switching music, which supersedes extraction?

Or, what if there is an even higher goal- to change moods? Is that what we should aim for? And if so, what does that make our original goal- a task??

Stay tuned for Part 2, where I’ll explain more…