In that fact lies one of the primary differences between task analysis and Card, Moran, and Newell's GOMS (Goals, Operators, Methods, and Selection) cognitive model. At first glance, the two methods might appear almost identical, but there are several important differences. A brief exploration of these differences will help to point out just what task analysis is and is not.

It is possible to construct a GOMS model for a system based solely upon design documents or a prototype, without any user involvement. Because GOMS assumes that users never make mistakes, they are nothing more than another component whose behavior can be predicted. In contrast, task analysis depends upon the observation of existing systems, as used by real users.

A GOMS model is typically very detailed, especially if it employs something like the Keyboard Level Model, and focuses on one specific goal and the low-level operations necessary to achieve it. Task analysis, on the other hand, generally uses a broader scope, looking at the entire system, and at other elements of the environment where the system is used that play a role in completing a task. It may become very detailed, but usually only in response to the needs of a specific project. We'll look at this more closely when we examine the uses of task analysis in HCI.

Finally, conceptual models are an evaluative, summative technique, used to measure the performance of a system. Task analysis is a generative technique, used to describe the behavior a system and provide a jumping-off point for new design.

Observation of subjects performing the task to be analyzed is the central method of data collection for task analysis. Depending on the project at hand, this observation might be formal or informal, and might take place in the field or in a laboratory. Some normally-evaluative techniques, such as a think-aloud, could be used to very good effect for gathering data for task analysis, especially for investigating the steps taken (or objects and actions involved in) a specific goal. These exercises can either be guided (ask the subjects to accomplish a certain goal and observe how they do so) or unguided (such as observation in the workplace, where the subjects have goals of their own).

Interviews with experts in the task to be analyzed are another good source of data. These interviews could take place independently of direct observation, or could be a follow-up to resolve questions which grew out of an observational session. Interviews should be used cautiously, however, if they are to be the primary source of data, because experts are frequently not aware of all of the steps they take when performing a task - their level of experience causes some details to drop below the level of conscious thought. Careful questioning is required to ensure that nothing is missed.

Task Decomposition

1. Select a task
2. Based your data (from observation, documentation, and expert advice), divide the task into sub-tasks.
3. If your stopping rule has not been reached, repeat steps 1-3 for each of the new sub-tasks.

The stopping condition you use - the level of detail you recurse to - depends on your purpose in performing the analysis. Stopping conditions are needed to keep the process from continuing infinitely. Task decomposition rarely continues to the level of detail of how to perform physical movements.

In addition to a tree of tasks and sub-tasks, rules describing what order sub-tasks are to be performed in are also needed. Hierarchical task analysis (HTA, a variety of task decomposition) refers to the collection of tasks as a 'hierarchy' and the governing rules as 'plans'. There are several ways for these plans to be arranged: subtasks might be sequential, cyclical, optional, or fall into other arrangements.

Once the task hierarchy and plans have been laid out, it's advisable to review them several times to look for omissions. Stepping through the subtasks in the hierarchy (being careful to do nothing that is not listed) can reveal items that were overlooked.

Knowledge Based Analysis

As groups are formed from the items, the groups themselves are then grouped together, building progressively more abstract categories. The structure this process eventually arrives at is termed a 'taxonomy' - a naming hierarchy. Depending on the purpose of the analysis, each item might have a unique 'path' in the hierarchy (appearing only once), or some might belong to multiple groups. Some techniques require that every item be uniquely describable by the groups it falls under, and that if two items are in exactly the same set of groups, either a new group be created to define the difference between the items or the items be combined.

Entity-Relationship Based Analysis

Objects are divided into four categories: simple objects, actors, composite objects, and events. Each simple object may have attributes or qualities associated with it - size, weight, or color, for example. Actors (which are typically though not always humans) have attributes, but are also associated with a list of actions which they perform. Composite objects are composed of a group of simple objects or actors. Actors perform actions upon objects, possibly changing the attributes of the object in the process (for instance, changing the status of a device from 'off' to 'on'). Events are things that take place spontaneously, either randomly or caused by actions outside of the model, which objects and actors react to.

The second half of object-relationship analysis is the relationship between objects. Objects can be related to each other in terms of physical location, or to actions that are either performed with them or on them. Actions may cause other actions, or be triggered by events. The variety of possible events is large, and depends upon the nature of the task.

Why is that insight useful? Most, though not all, computer applications are attempts to make easier tasks users already perform. Word processors replaced typewriters, computer databases have (to a large extent) replaced paper filing systems. In building a system like this, it is wise (as Nielsen's heuristics remind us) to 'match between the system and the real world'. That is, make the system compatible with what the user already does, so that its introduction draws upon already learned skills and fits smoothly into the rest of the work environment.

Step one of this process is understanding what it is that the user has been doing. The new system can then be arranged in a way that is compatible with the user's accustomed behaviors (learned through task analysis), presented in a way that matches the way the user mentally classifies the actions and items involved (gathered through knowledge-based analysis), or include logical objects and the actions associated with them (discovered through object-relationship analysis). This could take place anywhere between the level of broad system design (selection of the tasks and functions to be included in a new system) to detailed interface decisions (the arrangement of menu options based on taxonomy, or on frequency of a given subtask).

In addition to guiding system design, that information can also be used for the creation of documentation - either documenting the task that was analyzed, or presenting instructions for a new task or system in a way that parallels a familiar one, for ease of comprehension. Task decomposition lends itself to the creation of instruction manuals, while knowledge and object-relationship based analysis are more appropriate to reference guides.