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

In Part 1 of this long post series, I discussed goal-directed design and the more customary way to view goals and tasks, along with their commonly noted distinctions. In Part 2, I laid down my claim about the true nature behind these conceptual tools, in attempt to both confuse the matter and also clarify it at the same time.

In Part 3, presumably the final part, I will attempt to address the implications drawn from my claim, supposing how we may use my rants to further us in our ways of general hierarchical thinking and in our more specific instances of user-centered design methodology.

I'd like to note that the main conclusions in the claim and resulting discussion lie mostly in the realm of communicating about goals and tasks effectively with team members, as well as thinking about them for yourself. In other words, I am not advocating full-blown changes to the way you acquire and analyze user data or even necessarily in the way you design goal-directed solution.


My aim is to get you to think and communicate with flexibility about user modeling.



I've heard of (and been part of) many squabbles in the confines of meeting rooms where UCD professionals are forced to argue over what constitutes a goal and what constitutes a task in order to establish a common ground of discussion and documentation. And establishing these common grounds is so important to effect collaboration- whether you are a 2 person team or a multi-departmental corporation. The thing is; these types of arguments will always plague the said team time and time again because the division between the two concepts is not prescriptive. Thus, they will have to revisit the same argument every time, albeit with different activities in question.

It's like having to compromise (and often disagree) on rules for a pickup football game every single time you play (even though it's the same group of people). If you could all agree on the basic nature of the game in the first place, then you could establish any rules you want and follow them to your heart's content- as long as you are all happy with how the game is being played.

Similarly, instead of discussing whether or not changing the music in the car is a goal or a task, and then having to have the same discussion about finding a destination on a dashboard navigation system, you should just realize that you are wasting your time and efforts! By putting your time into establishing a more flexible and effective process, with a basic underlying acceptance of the continuous nature of goals and tasks, you can be more effective.

If you can accept the claim that tasks and goals (and other variants of the terms, like activities, objectives, etc.) are really inherently the same concept and differ only in their relativity and global scope, then you will be able to appreciate some consequential implications:

1. Your team communication and process establishment will potentially benefit.
2. You can easily increase and decrease your scope of attention by simply asking why and how, respectively.
   
3. You can realize that just because a goal is 'higher' doesn't always mean that it is more important than a task. If you design a product or service that behaves abhorrently at lower levels (say, the visual feedback of button pressing, or a customer service interaction), then the goal no longer matters to the user experience! After all, a person may never even be cognizant of a high level goal if they are immerse in an appropriately scaled task. See Flow Theory.
4. The methods you use to identify goals can be employed to identify tasks as well- and vice versa. So, if you have an established way of recognizing people's tasks in an observed workflow, but need to identify their subtasks and/or goals for accomplishing the tasks you find, you don't have to use a different process.
5. It's all about finding the sweet spot. Using a flexible goal/task diagram technique, you can quickly identify the top boundary (when the user no longer knows or cares why they do something) and the bottom boundary (when the user no longer cares or knows how they do it). Identifying the boundaries can be very powerful for understanding exactly what level of scope your product should cater to and how to go about planning your UCD project.
6. Actor goals found in use cases are not a different kind of goal from the ones found in goal/task hierarchies created by UCD proffesionals. They are just usually lower is scope than the goals found typical hierarchies (the ones that specify why the use cases are being accomplished in the first place).
   
7. Lastly, goal/task hierarchies and the concepts they represent are NOT prescriptive. They are descriptive guidelines, imperfect by nature, and requiring the interpretation and discussion of qualified professionals.

As my boss put it after a long discussion, goal/task diagrams are kind of like research heuristics, in parallel with design heuristics. They are malleable guidelines that you can use to research users and hopefully design useful and usable solutions.