When conducting behavioral analyses of systems during development, it is an implicit assumption that one can decompose a unitary behavioral activity into its constituent elements. Stated more clearly, when evaluating the design of a particular system, in order to assess the role of the human in performing various functions, the analyst must first be able to break human functions and actions down into sub-functions and sub-actions. Commonly, such a break-down is accomplished with a task analysis. Task analysis, first developed by Miller in 1953 (Miller, 1953), provides the system analyst with information about the intended use of the system and, also, with information about the performance demands placed on the human operating within the system. The general purpose of this kind of analysis is to define, describe, and eventually evaluate the role of the human in performing necessary actions to complete some general goal or specified task.
Task analysis is appropriate and desirable when evaluating the nature of the interaction between a human and a machine, with emphasis placed on human performance more so than on machine performance. For example, the interaction between some type of computer software and a potential user of that software could be evaluated in this manner. A software manufacturing company might be interested in conducting usability testing and task analysis on a sample of potential users to uncover bugs or problems in newly developed software. In another example, understanding the capacities and limitations of an airline pilot in his work environment, i.e., the airplane cockpit, could be facilitated by conducting a task analysis on his activities within the pilot-cockpit system. Thus, task analysis could be utilized in many different types of human-machine systems and, arguably, even in human-human systems, e.g., verbal transmission of information.
According to Dix, Finlay, Abowd, and Beale (1993), there are three basic kinds of task analysis related to human-computer interaction: task decomposition, knowledge-based techniques, and entity-relation based analysis. A task decomposition, or "how to do it" decomposition, breaks down tasks into sub-tasks, typically in the form of a hierarchical task analysis, or HTA. That is, higher-order functions are decomposed into second-order functions in a hierarchical manner, either textually in tabular form or graphically in a type of functional flow diagram. Knowledge-based techniques, on the other hand, involve the use of taxonomies, which are defined according to the specific overall goals of the analysis. Taxonomies of objects and actions are created, serving to organize knowledge regarding how the tasks will be performed. The overall taxonomic structure is affected by the way in which objects in the structure are cataloged and analyzed. Typically, emphasis is placed on the relationship between objects and on observed similarities between the different objects.
In entity-relation based analysis, the emphasis is placed on the relationships between actions and objects, instead of on the degree of similarity between them. The principal objects and actions involved must be first be identified, allowing object/action descriptions to then be delineated. Objects may be classified as concrete objects, actors, or composite objects. Actions reflect the relationship between the patient, e.g., the thing whose state has been changed, and the agent, e.g., the thing that causes the change. The next step would be to analyze the various relationships, including object-object, action-object, and so on. This type of object-oriented analysis could be applied using an HTA or "life-cycle" diagram which would represent all the actions that are associated with a given object. Thus, there is some degree of overlap among the three types of task analysis discussed by Dix and colleagues (1993). These types of analyses would be particularly appropriate when evaluating the relationship between computer users and the computer interface, whether the system involves human interaction with software or with the ergonomic layout of the input device, i.e., the keyboard.
Task analysis can be useful in a number of computer-related design settings. According to Dix, Finlay, Abowd, and Beale (1993), a type of knowledge-based task analysis can be used to develop training directed toward novice computer users regarding some task, e.g., using manuals to instruct how to operate some program, but including some degree of conceptual structure. A task analysis incorporating taxonomic structure could also guide such training. In addition, when training has to be transferred from one system to another, a task analysis performed on each system could provide helpful information about design problems. Finally, detailed interface design, e.g., involving the design of menus or GUI-based software, requires the use of task analysis to fully illuminate at which step in a task problems occurred.
Via the use of executable task models, some computer scientists are beginning to see the value of task analysis in software engineering (see Copas & Edmonds, 1994). The primary reason for this is that task analysis seems to be very effective at addressing issues of user requirements, providing valuable insights into problems associated with interface design. In an executable task model, a series of interaction screens are generated which allows user requirements to be demonstrated to the software developer in a concrete and clear manner (as distinguished from the conventional rapid prototyping approach). Copas and Edmonds state task analysis, although traditionally viewed as somewhat redundant when conventional analysis tools are also utilized, can make a unique contribution to software design and development, when applied.
In the realm of human factors and engineering psychology, task analysis also contributes significantly to the design and test/evaluation process. However, within these fields, there is quite a bit of variability in how a task analysis is carried out, based on the vast number of different types of human-machine systems that exist. Only a few different methods will be discussed here, although there are many works in the literature regarding basic methodology of task analysis and variations from it (see Fleishman & Quaintance, 1984; Vallerie, 1978; White, 1971).
Some researchers hold that tasks must first be described and identified before a task analysis can be appropriately carried out. Meiser (1985) proposes a task description should be performed prior to a task analysis, including the following steps: 1) examine each design alternative, 2) for each design alternative, list action sequences necessary to accomplish the task, 3) categorize actions based on whether they are associated with operation or maintenance, and according to the hardware/software subsystem to which they belong (if appropriate), 4) describe each action with respect to action, equipment acted upon, result of action, cause of action, feedback provided, and criterion of task completion, and 5) break down tasks into subordinate tasks (if appropriate). Such task descriptions can assist in organizing tasks and sub-tasks based on prespecified criteria. For example, by defining the purpose of the task and determining the equipment that is common to multiple actions or steps taken during task performance, the task analysis can provide hints as to what type of control/display hardware is required and what type of skills the users must have.
Analysts may not know beforehand to what degree of detail a task should be described, how molar or molecular, how abstract or specific. For example, should a task analysis break down a task to the level of behavioral fundamentals, e.g., processes involved in the perception and discrimination of stimuli on a display, or to a level that subsumes a number of subtasks involved in performance, e.g., monitoring the display and making a decision represent one function or action within the overall task? Thus, task descriptions can help the analyst determine the purpose for which he is performing the task analysis, and how the questions that the task analysis is designed to answer will be answered. The actual task analysis may be viewed as the logical, next step in systems analysis and, when finished, will reflect general conclusions derived from the task description.
After the task has been properly identified and described, a task analysis can then be conducted. According to Meister (1985), first, individual tasks are analyzed in terms of work station and job design, noting important factors to successful task completion such as possible adverse consequences due to malfunctions, critical information required, performance required by human, cognitive/ perceptual/psychomotor demands, and error characteristics. Then, for each component of the task, manning requirements, e.g., level of skill underlying task performance, output characteristics of correct performance, training requirements, e.g., behavioral dimensions of the task, task complexity, and frequency of occurrence of the task, and test/evaluation requirements, e.g., feedback provided, level of error recoverability, are outlined. Thus, by using Meister's methodology for conducting a task analysis, concrete recommendations can be made with regard to how the workspace or machine interface related to a particular job might be improved to increase work productivity and efficiency.
Others analysts stress that the task analysis need not be sophisticated, as long as the overarching goal encompasses the identification of task elements so they can be later combined meaningfully and realistically in one or more evaluation tasks (Ravden & Johnson, 1989). In this case, the type of evaluation that will be carried out later in the design process is taken into consideration during task analysis, which typically occurs earlier in the process. According to Ravden and Johnson, the first step of a task analysis is to collect pertinent information that will allow the evaluation tasks used later in analysis to reflect accuracy and validity, with respect to the particular system in question. Next the information should be collated and represented somehow, taking into account the following questions: 1) Is the representation in sufficient detail to create generic evaluation plans?, 2) Is the description of the task clear and unambiguous?, and 3) Will it be possible to present this representation to users of the system and obtain useful comments and explanations? Basically, the goal up to this point of the task analysis is to determine, in sufficient detail, e.g., including higher- and second-order functions, what is done, how it is done, and why it is done. Next, iterations of the analysis are conducted, with both users and analysts, refining the representation of the task in question. Therefore, Ravden and Johnson hold task definition and description, coupled with user and analyst feedback, can facilitate the development of evaluation plans such that the system can be properly assessed.
In addition to the types mentioned here, there are many, additional different types of task analysis since there are many different kinds of systems to which they can be applied that involve different taxonomies. However, there are some categories that are common to many of these, including: function/activity/behavior, error characteristics, response required, feedback provided, time taken/needed to perform task, skill level, task location, task complexity, and accuracy/response criterion. Some methods are based on demands placed on the operator or user of system (e.g., Armsby, 1962). Others involve identification of task descriptions from training functions, which are skills and knowledge inherent to different task types, and then categorizing these functions by equipment effectiveness (Demaree, 1961).
What is most important about a task analysis is not the exact methodology that will be used to perform the analysis but that a definition of the task itself has been explicitly defined and agreed upon. For example, the task might be defined as the series of actions necessary to perform some function, the successful transfer of information between two system components, or the set of abilities required to perform the task. In addition, it is important that the analyst tailors his task analysis to the system in question, addressing issues that are deemed most important for successful operation of that particular system.
A final, logical question might be... where does the analyst go to get information needed to conduct a task analysis? Information useful in a task analysis may be obtained from 1) system documentation such as previous task analyses of old systems, test reports, or test specifications, 2) from task descriptions, 3) from existing operation, instruction, or training manuals and materials, 4) from direct observation of old or related systems, 5) consulting end-users, or 6) via empirical research conducted by analyst. Also, some companies may have established procedures or codes for how certain tasks should be carried out, and these sources can be consulted. Reference should be made within the task analysis to any outside documentation that was used.
In sum, task analysis is useful for assessing the role of the human in basically any human-machine system. It forces the analyst to define the task of concern explicitly and determine the exact steps taken to successfully complete the task, early in the design process. Also, potentially problematic factors, relevant to human activity, may be recognized and addressed before the design is actually implemented. Finally, the task analysis assists the analyst in thinking about the system in both abstract and concrete terms, allowing him to make better decisions about system specifications and parameters.
References
Armsby, D. H. (1962). Task demands analysis. Human Factors, 4, 381-387.
Copas, C. V., & Edmonds, E. A. (1994). Executable task analysis: Integration issues. In G. Cockton, S. W. Draper, and G. R. S. Weir (Eds.), People and Computers IX (Proceedings of HCI, '94), pp. 339-352. Cambridge University Press: Cambridge, England.
Dix, A., Finlay, J., Abowd, G., & Beale, R. (1993). Human-computer Interaction. Prentice Hall Europe.
Fleishman, E. A., & Quaintance, M. K. Taxonomies of Human Performance: The Description of Human Tasks. Academic Press: New York.
Meister, D. (1985). Behavioral Analysis and Measurement Methods. New York: Wiley-Interscience, John Wiley and Sons.
Miller, R. B. (1953). A Method for Man-Machine Task Analysis (Report 53-137). Wright Air Development Center, Wright-Patterson Air Force Base, OH.
Ravden, S. & Johnson, G. (1989). Evaluating Usability of Human-computer Interfaces: A Practical Method. Ellis Horwood Limited: West Sussex, England.
Vallerie, L. L. (1978). Survey of Task Analysis Methods (Research Note RN-80-17).Army Research Institute, Alexandria, VA.
White, R. T. (1971). Task Analysis Methods: Review and Development of Techniques for Analyzing Mental Workload in Multiple-Task Situations (Report MDC 55291). Douglas Aircraft Company, Long Beach, CA.