Create A Website Ethiopia

Applying hierarchical task analysis to web site design is a direct and systematic approach to characterizing the knowledge required by a typical person to use your site.

As the name implies, it involves organizing the tasks in a hierarchy and decomposing the procedures to an adequate level. The process of decomposing the user’s tasks is iterative and involves the following steps:

1. Identify the primary user goals.
2. List the steps that a user must perform to accomplish the goals.
3. Optimize the procedure.

After the task is described at a sufficient level of detail, the procedures can then be optimized to minimize the number of steps, improve consistency among similar procedures, reduce user error, or make any other adjustments that may be critical to your site’s goals.

Often, as a procedure is listed, it will be revealed that the steps to accomplish a goal are actually a collection of other, smaller subgoals. For instance, filling out a form involves filling out a series of text fields, radio buttons, checkboxes, and so forth.

Instead of listing out each individual action for each form element, we can just say “Complete the address text field” or “Select a country from the pop-up menu.”

Each of those steps is actually a low-level interface goal involving a number of user actions. For example, to accomplish the goal “Select a country from the pop-up menu,” the user must
1. Locate the pop-up menu named “Country.”
2. Move the cursor to the menu.
3. Press the mouse button.
4. Locate the appropriate country from the list.
5. Move the cursor to the country name.
6. Press the mouse button.

This type of generic procedure may be used many times in an interface by just changing the name of the menu and the menu item to be selected. Do we need to list this out every time?

No, it is only necessary to specify it once, knowing that it is simply a generic procedure, much like a computer program. Change the input data (e.g., the menu name) and the same procedure can apply anywhere there is a pop-up menu.

Furthermore, there is an additional incentive to optimize such routines, because if you optimize one generic routine, the benefits are seen every time the routine is used, potentially a much greater payoff than optimizing a procedure that is only used once.
How Far Down Should You Decompose a Procedure?

Tasks should only be decomposed to a granularity that you have any control over or that will affect your decisions on interface design choices.

The point is that task decomposition should only be done as long as there is a potential gain from the analysis.

For example, it may not be necessary to list out the steps to select an item from a pop-up menu because there may be nothing you can do to change it.

If the system dictates that only a limited set of interface elements can be used, then a deeper analysis is pointless. However, if you need to choose between two interface elements that can produce the same result, it may be useful t use what is required from the user’s point of view.

A typical stopping point for decomposition is the level of observable user actions, such as keystrokes and mouse movements. However, designers should not neglect the mental effort that users must exert while performing a task.

For example, each new screen presented to the user will require at least several seconds to understand (i.e., time to establish a gestalt).

It is also important to consider items that users must remember between screens and complex decisions that users must make, as these are a prime source for errors.

For guidelines on how to assess the mental actions that users must perform during a task, see Kieras’s “A Guide to GOMS Model Usability Evaluation Using NGOMSI.” (1997) or Raskin’s The Humane Interface (2000).

A good benchmark for determining an appropriate stopping point is whether a person can perform the task properly using your procedures.

The task procedures should be general enough to apply to any set of input data, but include enough specific information that a person could perform the task. For more information on this type of task analysis, see the “GOMS Analysis” sidebar.

Report This Post