Wednesday, October 31, 2007

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.

  1. 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.
  1. 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.

  2. 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.

  3. 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.

If you don't remember my common goal/task diagram example from Part 1, now would be a good time to reference it. Let's take a look at my revised goal/task diagram:

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...


Thursday, October 18, 2007

Bespoke UI for Developing Regions?

The continent of Africa is experiencing an unprecedented growth in mobile interactive systems.

Most people should consider that a good thing. Mobile interactive systems--specifically information-oriented systems--are attributed with progression in the fields of
Naturally, the better a person can leverage the information-oriented system, the more benefit they should experience because of it.

If you disagree, stop Googling until you're convinced. (By the way, try not to take Googling for granted. You're actually quite privileged.)

As a UI Designer for Nokia, I design UIs which are meant to leverage the features of a mobile phone. The features are intended to address the needs of painstakingly researched consumer segments. We design for segments, because one size doesn't necessarily fit all.

It turns out that it's very difficult to design "globally" in many cases.
"To achieve culturally sensitive, successful global access to UIs provides many design challenges in the UI development process."
(Understatement courtesy of Aaron Marcus' chapter in The HCI Handbook.)

So if such an emphasis is placed on segmenting markets, spending money on consumer research, designing for sub-populations (e.g. 18 - 24 year-olds, technology enthusiasts, business people) and running usability tests on representative samples of the population, why are huge percentages of populations having such difficulty accessing information??

I believe the problem is lack of bespoke UI design, and supporting infrastructure, by product of innovative contextual design.

(Bespoke + UI = User Interfaces tailored to specific needs [of a user or user group].)

In a Nigerian survey on the obstacles to use of mobiles in rural areas among market traders it was found that:
"42% had difficulty understanding the phone menus"
The so called "Developing World" is apparently in possession of "hand-me-down" systems that just don't quite fit.

If the systems don't fit the needs of the users, as mentioned above, the harder the system is to leverage and the less beneficial it becomes.

Ergonomics, Systems Analysis, Usability, various branches of HCI, etc. have been tried and tested and proven to be effective in improving accessibility to interactive systems. For reasons not completely clear to me, these sets of methods and techniques are not being heavily used in bringing Information Communication Technology (ICT) to the so called "Next Billion" users.

I think it's time to change that. Some prominent academics also seem to think so.

Labels: ,