The main purpose of task analysis is to identify the actions – observable behavior – that are required to complete the task. This is a separate analysis from something like GOMS, in which the purpose is to get a sense of what is going on inside the user’s head.
Hierarchical Task Analysis
A Hierarchical Task Analysis is a breakdown of major tasks, and their subtasks, as well as a set of plans that describe the order and conditions subtasks are performed. Subtasks will not always be performed – they can be conditional as described in the plans.
The granularity of the subtasks depends upon the purpose of the task analysis, and on stopping rules. One stopping rule is the P x C rule where if the probability multiplied by the cost is below a threshold, stop creating subtasks. Another stopping rule is where the task is broken down to the point where many small mouse or keyboard interactions would have to be described. A third stopping rule is where a user must make a decision. Breaking down mental processes is likely beyond the scope of the system being created.
Once a first attempt at making a HTA is completed, it is a good idea to examine it for omissions or mistakes. Subtasks can be refined to reflect repetitious patterns, discretionary events, and wait times.
Knowledge-based analysis attempts to group things into taxonomies. Eg. steering systems and light systems in a car. Determining the grouping can be quite difficult. Experts can be asked about the systems, or non-experts can be asked to do a card sort. In subsequent iterations of the analysis, groups can be created, merged, or changed.
One type of knowledge-based analysis the author uses is the task-analysis for knowledge description. This uses Task Descriptive Hierarchy, which is a way of uniquely describing each object.
Overall, KBA is designed to give a general sense of a system, rather than the ‘how to do it’ of HTA.
Entity-Relationship task analysis, like Knowledge-Based Analysis, tries to capture objects and actions, but emphasizes the relationships between them, rather than their taxonomy.
Relationships will be between objects, such as human actors, and things being acted upon (patients). Objects will also have relationships with actions, such as subsystem x does y. Events are things that ‘just happen’, ie. there is no specific actor doing the event. For example, temperature dropping below a threshold. Objects can have relationships with events, too. For example, if temperature drops below 65 degrees F, the furnace turns on and heats the room.
Complex relationships can be broken down into messages. Person 1 tells person 2 to do something, and they do it. Person 2 is both patient and actor.
Data about tasks can be found in several places.
Frequently, there is existing documentation, that though not written for task analysis, can be perused for information about tasks. The main caveat is that these describe how something is supposed to be done, not how it actually is done. Further probing will be needed.
Tasks can be observed as they are being done. Observation can be passive, where the task is simply observed as its being done, or active, where questions are being asked about the process as it’s happening. This has the advantage of showing the actual task as it’s being done, but this is very time consuming.
Lastly, information can be gathered from the human actors via interviews. Direct questioning can quickly get to desired information. This is especially helpful after spending time observing the task so that the right questions about unclear elements of the task can be asked.
Comparison of Techniques
Each technique works best for certain types of problems. Hierarchical Task Analysis is best for explaining simpler tasks, especially when producing instruction manuals. For more complex tasks, Knowledge-Based Analysis is capable of supporting more complex structures and concepts.
Further, taxonomies developed through analysis can be the basis of user interface menus.