Assembling the data
The data for the Task analysis can be assembled from several places including business requirements, user research, existing competitive products and brainstorming.
The aim of "high level task decomposition" is to decompose the high level tasks and break them down into their constituent subtasks and operations. This will show an overall structure of the main user tasks. At a lower level it may be desirable to show the task flows, decision processes and even screen layouts (see task flow analysis, below)
The process of task decomposition is best represented as a structure chart (similar to that used in Hierarchical task analysis). This shows the sequencing of activities by ordering them from left to right. In order to break down a task, the question should be asked "how is this task done?". If a sub-task is identified at a lower level, it is possible to build up the structure by asking "why is this done?". The task decomposition can be carried out using the following stages:
- Identify the task to be analysed.
- Break this down into between 4 and 8 subtasks. These subtasks should be specified in terms of objectives and, between them, should cover the whole area of interest.
- Draw the subtasks as a layered diagram ensuring that it is complete.
- Decide upon the level of detail into which to decompose. Making a conscious decision at this stage will ensure that all the subtask decompositions are treated consistently. It may be decided that the decomposition should continue until flows are more easily represented as a task flow diagram.
- Continue the decomposition process, ensuring that the decompositions and numbering are consistent. It is usually helpful to produce a written account as well as the decomposition diagram.
- Present the analysis to someone else who has not been involved in the decomposition but who knows the tasks well enough to check for consistency.
Task flow diagrams
Task flow analysis will document the details of specific tasks. It can include details of interactions between the user and the current system, or other individuals, and any problems related to them. Copies of screens from the current system may also be taken to provide details of interactive tasks. Task flows will not only show the specific details of current work processes but may also highlight areas where task processes are poorly understood, are carried out differently by different staff, or are inconsistent with the higher level task structure.
If the tasks are already well understood, it may be sufficient to just identify and document the tasks as part of context of use analysis.
According to Dan Saffer the task analysis can consist in a raw list of features that the final application will have to carry. (Saffer, Designing for Interaction: Creating Smart Applications and Clever Devices , 2006)
Examples of tasks broken down
- Pick up the tooth brush
- Wet the brush
- Take the cap off the tube
- Put paste on the brush
- Brush the outside of the bottom row of teeth
- Brush the outside of the top row of teeth
- Brush the biting surface of the top row of teeth
- Brush the biting surface of the bottom row of teeth
- Try to make yourself understood while answering the question of someone outside the door
- Brush the inside surface of the bottom row of teeth
- Brush the inside surface of the top row of teeth
- Rinse the brush
- Replace the brush in the holder
- Grasp cup
- Fill cup with water
- Rinse teeth with water
- Replace cup in holder
- Wipe mouth on sleeve
- Screw cap back on tube
Borrow book from library
- go to the library
- find the required book
- access library catalog
- access the search screen
- enter search criteria
- identify required book
- note location
- go to correct shelf and retrieve book
- take book to checkout counter
TaskArchitect is a tool that supports Hierarchical Task Analysis.
Baumeister, L.K., John, B.E., & Byrne, M.D. (2000). A comparison of tools for building GOMS Models Tools for Design. In Proc. of ACM Conf. on in Computing Systems CHI’2000 (The Hague, 1-6 April 2000). ACM Press, New York. 502–509.
Gray, W. D., & John, B. E. (1993).
Project Ernestine: Validating a GOMS Analysis for Predicting and Explaining Real-World Task Performance.
John, B. E., & Kieras, D. E. (1996).
Using GOMS for User Interface Design and Evaluation: Which Technique? This article describes the different GOMS techniques and when they should be used.
Kieras, D. E. (2006)
A Guide to GOMS Model Usability Evaluation using GOMSL and GLEAN4 This
document is a heavily modified version of the earlier "Guides" to GOMS modeling, Kieras (1988, 1997a), and supersedes the 1999 Guide referring to GLEAN3. It contains detailed information about GOMS, its strengths and limitations, how to construct a GOMS model with examples, and how to use a GOMS model to predict human performance.