Create A Website Ethiopia

Hierarchical task analysis is a means of systematically defining a task from the user’s perspective. We can look at task procedures on three levels: user level, platform level, and application level.

User-Level Goals and Procedures
At the top level, task procedures are generic descriptions of the goals users will accomplish, like buying a book.

These descriptions can be viewed as generic because we can accomplish the goal of buying a book through many means, both electronic and physical.

Platform-Level Goals and Procedures
At the bottom level, task procedures are those imposed by the interface. If we are buying books online, we will probably be using a web browser and will be utilizing common web browser interaction techniques such as pointing, clicking and using pull-down menus and text-edit fields.

Alternatively, if we are buying our book from the local bookstore, we will probably employ different interaction techniques, which might include driving a car, searching bookshelves, and completing a transaction with a clerk. This level is also generic in that many different high-level goals can be accomplished using various combinations of low-level procedures.

Application-Level Goals and Procedures
In between the high and low levels, task procedure at the middle level specify how users will accomplish their top-level goals using the low-level interface procedures required by your system’s platform.

This is the level where, as designers, we can often have the greatest impact. High-level goals are driven by user needs and marketing decisions that are often a fixed requirement given to the design team.

Likewise, low-level procedures are often determined by the underlying hardware and software, and also cannot be changed. What we can easily change is how the low-level procedures are used to accomplish the higher-level goals.

We can affect how many and what kind of steps the users must perform. We can determine what information is shown on their screens, and we can determine how many and what kind of steps the users must perform.

We can determine what information is shown on their screens, and we can determine how many pages they have to navigate.

This is true of noncomputer interaction as well. For instance, we could change the procedure by which customers bought books in our bookstore example by having employees personally find books for customers and suggest related books for them.

This would minimize the time customers spend searching for books, but doing this for every customer would be very expensive and might have undesired side effects like reducing impulse buying.

Understanding the tasks and their context
The bigger challenge in performing a task analysis is accurately capturing the essence of the user’s job.

Simply asking users how they do what they do is not enough because users don’t think about the steps they go through. A typical response to “How do you do this?” is “I don’t know.”

I’ve bee doing it this way for 20 years and it’s the only way I know.” Describing procedural knowledge is notoriously difficult for many people. The most direct method is to start by finding any written documentation on how users are supposed to be doing their job, and observing them in action to see how their behavior differs from the “official” instructions.

If no written procedures exist, then analysts must observe users as they perform typical task scenarios.

Formal methods exist for understanding the context of people’s tasks, such as contextual inquiry. For a comprehensive treatment of contextual inquiry and contextual design, see Beyer and Holtzblatt (1997).

Use cases provide a good starting point for organizing this information. For other techniques, see the sidebar “Techniques for Understanding Tasks.”

A potential pitfall when interviewing users is putting too much emphasis on their design suggestions.

Although user participation is critical in the design process, caution should be exercised because users don’t always know how to design what they want or need.

For instance, it is common for some users to assume that an aesthetically pleasing site is more productive. Likewise when considering task performance time, users’ perceptions of their productivity do not always reflect their actual efficiency.

Their opinions about interface quality are always valuable, but they are not always correct.

Report This Post