Disclaimer: For those of you not associated with the Georgia Institute of Technology, please note that this document was produced as a term paper project for CS6751: Introduction to Human Computer Interaction. It's opinions do not necessarily represent those of the course instructor nor of the Institute in general. This document is not designated for publication outside of the GT College of Computing and may not, under any circumstances, be referenced in other publications. -ed.

Introduction
Evaluation techniques abound for the HCI practitioner, each varying widely in terms of focus and intent. Task Analysis, in particular, is a family of evaluation tools with a rich history. TA (Task Analysis) methodologies have been applied in a number of different design and evaluation fields with a great deal of success.
This document will attempt to provide a limited overview of the more common forms of TA, serving as a reference and practioner's guide in using this evaluation tool. I will provide a general discussion of the various flavors of Task Analysis and provide insight into their purpose and usage. I will then discuss, in detail, the main components of a TA and how each is formulated and executed. Finally, I will give a comprehensive example TA.

Task Analysis description
Task Analyses belong to a collection of evaluation techniques designed to help one uncover details about the human part of a systems equation. (A system is usually defined as any collection of humans and machines that work together to achieve some common goal.) Task Analyses look very closely at what each component in the system is doing (especially humans) and tries to make sense of the action and/or interaction that may be taking place. Task analyses are also concerned with what information is necessary for each part to complete its job, as well as the process or method of completion.
A task analysis is primarily a data gathering and classifying exercise. Observations, interviews, and existing documentation can all serve as information sources. Forming useful classifications of the data is often a more difficult problem. There are many differing views as to what exactly a task is. For some, it is simply a recording of actions of an experienced user. [WKW-95] Others may focus on goals that must be achieved for successful task completion, or perhaps on the interaction of system components.

References to these sorts of analyses go back to 1911. [Gilbreth-11] Later, TAs became popular in the human factors community and began to receive more formal attention. [Miller-53]. In the 60's, Annett and Duncan proposed a more general form of TA called Hierarchical Task Analysis (HTA). [AD-67] While the original TA was used mostly for evaluating human activity and motion, an HTA is capable of dealing with cognitive as well as motor tasks. Over the years the notion of a TA has been modified and repurposed for use in several different fields. Today we find task analyses in many different flavors, serving a broader spectrum of system design, development, and evaluation.
Several fields utilize TA methods; including Process Control, Human-Computer Interaction, Engineering Psychology, Human Factors, and Software Engineering, among others. Each domain modifies the basic workings of a TA for its own purpose - each with a different emphasis and desired result. I've briefly outlined a few of the more popular approaches below.

Other variations between TAs usually involve formatting issues (how the data is graphically arranged); the particular information categories (the taxonomy); and the TA execution methodology (how the TA is carried out). [Meister-85] As mentioned previously, task analyses have been modified and repurposed for years, yielding several home-grown versions and personal favorites. Caution, and a bit of research, should be your guide when choosing a TA methodology.

Task Analyses can be helpful in the design of a man-machine interfaces, determining personnel selection criteria, development of instructional curriculum, and as a summative evaluation tool. It is also sometimes possible to compare what actions are being performed in a system against some sort of standard or document that describes what should be taking place. Perhaps the most important question an HCI practitioner can ask before choosing and implementing a TA is one of purpose - What questions do I have about the system that a TA can answer? Further, what is the scope of the analysis? To what level of detail should the analysis proceed? What taxonomy should be used? To help answer these questions, I'll give a detailed description of the most common TA components.

Task Analysis Component Overview
A full featured TA consists of gathering data in several steps. First, a taxonomy is developed to help classify tasks and provide some means of formalizing what will and will not be analyzed. Next, an allocation is made as to what tasks will be performed by humans and what will be performed by machines, or other system components not within the scope of the analysis. Task decomposition then attempts to break down high level tasks into basic components that can be effectively analyzed. Next, a task description is developed to provide a clear view of what exactly is taking place within each task. Finally, an analysis is performed. Given all of the information, critically evaluate each task based on the analysis goal.

Task Taxonomy
Lots of people have spent time trying to determine a human performance taxonomy. Miller defines a taxonomy as "a means of classifying objects or phenomena in such a way that useful relationships among them are established. A taxonomy is therefore not a mere list of labels with semantic definition: it also has inner syntactic structure." [Meister-85] Fleishman gives four approaches to task classification: behavior description, behavior requirements, ability requirements, and task characteristics. [Fleishman-82]

The choice of a task taxonomy and its focus depend heavily on the goal of the analysis. Some task taxonomies are system specific; they are based on tasks required by a type of system and system activity such as aircraft and flying. Others are organized around particular controls and displays and their characteristics. There are also non-specific taxonomies that can be applied generally to a wide range of systems. Error taxonomies classify types of errors and error mechanisms. Learning taxonomies deal with required behaviors and types of learning. Functional taxonomies look at system functions in a manner similar to a GOAMS decomposition approach. Combinations of these taxonomies, and others, are also assembled to address specific evaluation needs. In the fledgling field of HCI, so many behavioral taxonomies represent the sort of fuzzy classification boundaries that exist - nonetheless, classification is very important and, we hope, will bring us useful information.

Possible taxonomy categories

Task Decomposition
In this step, high level tasks are broken down into smaller, more manageable components, normally referred to as sub-tasks. These are arranged in a sort of hierarchy which gives them a descriptive structure and also demonstrates interrelationships among the various tasks such as dependence and inheritance. The principal difficulty associated with task decomposition is knowing when the level of decomposition is enough. Oftentimes our intuition is the the most useful indicator, though sometimes an explicit stopping rule is formulated. [DFAB-93] This rule may be related to the probability that an error might occur somewhere in the task versus the cost of the error. It may also be expressed as a function of human intervention - that is, when a human must make some sort of decision or perform a complex motor action.
A task hierarchy may be represented as an ordered list or perhaps as a tree or diagram - or by any other method that helps to bring some sort of additional meaning to the task structure. From a graphical representation, additional information about the task structure may be gleaned, such as balance, and depth. If you find that a task hierarchy is severely lopsided, it may be cause for review. While it may turn out that the unbalance is simply a natural feature, it may also be possible that there are errors or omissions present in the decomposition.

Task Allocation
Task allocation refers to the process of dividing up the various tasks or subtasks in a system among the human and machine components. In a factory, for example, a person may use large tools or equipment in the process of assembling a car or truck. The human may be required to align the part being worked on to some sort of machine so that the machine can drill a hole or weld a joint. This is an example of a shared allocation - both the human and the machine have roles in the successful completion of the task. In other systems, the workload may be directly allocated to either the human or the machine. Task allocation may also be dynamic. That is, depending on the situation, functions may drift between system components according to some functional storyboard.
A typical task allocation proceeds as follows: 1) determine what tasks remain to be allocated. 2) describe possible implementation solutions and develop a preliminary feel for the nature of the allocation (static, dynamic, human or machine oriented). 3) develop a set of criteria that can be used to evaluate the various implementation options. 4) based on the implementation comparisons, choose the most cost-effective alternative. This process is repeated again and again down to the lowest levels of the task decomposition chain.

Task Description
Before starting the analysis, each task should be fully described, preferably by a subject matter expert (SME) who can provide additional insight into the nature of the task. When developing a new system, the task description may suggest an appropriate display mechanisms or specific hardware/software implementations. Descriptions can also be used to organize and group tasks based on purpose or function, common equipment utilized, and skills or knowledge required.
The process of developing a task description involves creating a list of features that establish the function to be performed. Keep in mind, though, that analyses may differ depending the purpose and desired results, and thus each task description may contain different information. A possible starting point might include the following features: [Miller-53]

In general, the more task description information, the better. Sometimes information is unavailable, however, and it is up to the practitioner to determine what level of detail will suffice.

Task Analysis
Traditionally, tasks are analyzed in terms of design, manning, training, testing, and evaluation considerations. [Meister-85] In the realm of HCI, tasks might be evaluated in terms of physical and cognitive load, likelihood for error, human limitations, and system feedback, among others. This is the core purpose of a TA - trying to uncover potential problems or pitfalls in a given or proposed interface solution. Each of the steps leading up to the final analysis provides helpful information, and several issues may be discussed in the process of getting to the TA. This final step helps to solidify concerns and provide a basis for suggesting possible design alternatives or improvements.
The general form of the TA is a series of detailed and purposeful questions. These are designed to help the analyst discover any hidden intricacies and develop a deeper understanding of the task's impact on the system as a whole, and on any particular design solutions. Once complete, each task should have a complimentary assessment that can be applied towards the final result, be it a collection of training manuals, design recommendation, system requirements, or perhaps a detailed design specification. Several other forms of final analysis have been proposed over the years. Again, the key issue is purpose and scope - choosing an approach that will yield the most substantial results.

In conclusion, I've given a short historical background for the development of Task Analyses and defined, in general terms, the form, content, and execution of a TA. I will now provide a comprehensive example, illustrating the points I have set forth above. This example was generated specifically to address the TA format I've described. Note that it IS NOT a complete analysis!

References

Author: Kevin C. Scott, December 1997