Why Goals and Tasks are the Same Thing (part 2)
In Part 1 of this post series, I discussed goal-directed design and the more customary way to view goals and tasks, along with their distinctions. In Part 2, I will lay down my claim about the true nature behind these conceptual tools. And in Part 3, the final part, I attempt to address the implications drawn from my claim, supposing how we may use my rants to further us in our ways of general thinking and in our more specific instances of user-centered design methodology.
To continue my discussion, I'll get the ball rolling with my slightly blunt contention- which is; the only difference between what constitutes a goal and what constitutes a task is the relationship between two. To put it another way, Albert Einstein was right when he said it was all relative- it all depends on how you look at the goal or task in question.
In Part 1, I listed out several typical assumptions about the differences between goals and tasks. Here, I will list them again and provide perhaps some more clarifying rebuttals to the statements.
- Goals are high-level; Tasks are low-level.
While globally true, this is more of a descriptive and subjective accusation and is not objectively prescriptive for labeling across multiple goal/task analyses.
- Goals are abstract; Tasks are physically observable (concrete).
This is a tough one- after all it is a pretty easy way to think about it. However, it requires a vigorous exploration into what it means to be abstract in order to see that abstraction is extremely difficult to classify and most likely exists as some type of graded continuum- not an either/or. But I’ll save the philosophy for a different time and place! Often times, tasks are fully or partially abstract as well. And sometimes sub-tasks are not fully observable. - Goals are something a user has; Tasks are something a user does.
This is simply a property of the terminology you are using. Only once you call something a goal does it make sense for you to “have” it, as opposed to “doing” it. Once again, it is not a prescriptive way to deal with entities which could be called either tasks or goals. - Goals do not change; Tasks do change.
This is simply not true. It’s a close approximation, but fatally false. Goals do in fact change. The difference is that high level goals change MUCH more slowly and less frequently than do low level tasks. Once you understand the continuous scoping nature of goal/task hierarchies, it will be easy to see that statement number 4 is an oversimplification.
Now, allow me to make some claims about goals and tasks that I think are better suited for accuracy which follow from the above diagram:
Goals and Tasks aren't qualitatively distinct.
Give me a task and I'll show you how it's really a goal for another set of subtasks. Conversely, you can provide me with a goal, and I'll show you that it's really a task that exists to reaching some higher-yet goal. The thing that makes the two different is the state in which you view it relevant to another. At any one point in time, the entity under inspection could be a goal or a task depending on how you view it.
Goals and Tasks are relevant to each other.
A task is only a task if it is subordinate to a goal. Likewise, a goal can only be considered a goal if it is composed of one or more tasks. Otherwise, it too is just a task...Another way to put this is that if a goal doesn't have a reason for being accomplished or desired that satisfies some lower steps to get there, then it doesn't have the right to be called a goal.
Goals and Tasks can be mapped onto a continuum.
Create a goal/task diagram that extends as many hierarchical levels as you'd like. Now, recognize that you cannot draw any straight line that separates concrete physical tasks from abstract ones. Instead of creating false categories, it is more accurate to map them onto a continuum where at the top lie MORE abstract, higher-level, slowly changing goals and where at the bottom lie MORE concrete, lower-level, often-changing tasks.
Goals and Tasks change over time, albeit at different rates.
While tasks at lower levels can change very quickly and often, higher level goals can change very slowly or seemingly not at all. Think about it- while you may always have the semi-constant goal of getting your coffee in the morning, the way in which you go about getting your coffee may vary from making it yourself, to your loved one making it, to going to a coffee shop on the wya to work, to grabbing some at work. While I may at age 40 decide that coffee is no longer my drink of choice due to stomach ulcers or some sleep somnia, my lower level tasks that lead to my acquiring coffee change much more rapidly (every other day compared to almost 20 years from now).
Ask WHY to traverse to a Goal, and ask HOW to see it's respective task(s).
At any node in a goal/task hierarchy, one may ask why it is being performed. The answer you get is a goal or a set of goals. Likewise, if you ask how a particular node is performed, the answer you get is a task or set of tasks. This is actually pretty basic, but the cool thing is that you can ask these questions for ANY node in a goal.task hierarchy! In fact, once you apply this practice to a range of nodes in a hierarchy, it really becomes clear that goals and nodes are really only relative terms.
Another cool thing is that these questions act as arbiters for the top and bottom boundaries of a goal/task diagram. It is at the point when one no longer cares why or knows why that the top of the boundary is fully identified. Alternatively, when one no longer knows how a task is performed, or cares how it is performed, we see the bottom boundary.
If you feel my claim is misguided, ridiculously time-wasting, or just plain wrong, please feel free to comment and explain your side. Otherwise, please ponder the argument above. I hope to explain the usefulness from these points in my next post, along with some interesting implications that they draw.
Until Part 3...
Labels: methodology
posted by codyfrew @ Wednesday, October 31, 2007
250 Comments
