Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Analysis of tasks and errors is a hugely important activity for anyone seeking to understand how users interact with ITS or wishing to create the environment in which the interaction will take place – between users or between a user and an object/activity. Task analysis requires understanding and documenting all aspects of an activity in order to create or understand processes that are effective, practical and useful. Typically a task analysis is used to identify gaps in the knowledge or understanding of a process. Alternatively it may be used to highlight inefficiencies or safety-critical elements. In both cases the task analysis provides a tool with which to perform a secondary function – usually design-related. Error analysis is a specific extension of a task analysis and is about probing the activities identified by the task analysis – to determine how and why a user might make an error, so that the potential error can be designed out or the consequences can be mitigated.
The person conducting a task analysis first has to identify the overall task or activity to be analysed, and then to define the scope of the analysis. For example, it may be that they wish to examine the tasks performed by an operator at a monitoring station, but are only interested in what the operator does when they are seated at an active station. This would be the defined scope of the analysis.
Within this overall activity all the key subtasks that make up the overall activity must be identified. It is up to the person undertaking the analysis to decide what represents a useful and meaningful division of subtasks. This is something that comes partly from experience of performing such analyses and partly from understanding of the activity being analysed. Crucially, each subtask should have a definable start and end point.
With the subtasks created, the investigator then defines a series of rules and conditions which govern how each subtask is performed. For example, it may be that the monitoring station operator has at their workstation a series of monitoring systems (subtasks) where each subtask is distinct and separate – and it may be that the operator must perform the subtasks in a pre-defined sequence. The investigator must specify the rules governing how each subtask relates to the others. For example: “perform subtasks A and B alternately. At any time, perform subtask C – as and when required”.
The investigator would then look at each subtask in turn and perform a similar process to the process described above. The subtasks that make up subtask A would be identified and the rules governing their commission defined. This process of hierarchical subdivision continues until either there is no more meaningful division of tasks that can be performed – or the investigator has reached a level of understanding useful enough to inform the design.
Performing a task analysis allows a researcher to identify the following:
An error analysis builds on the task analysis and requires a similar approach. It looks at all the different ways in which an operator or outside agent could perform an error in each subtask identified. For example, one subtask for the operator of a monitoring station, may be to activate an alert system. Errors could include (among others), selecting the wrong incident response plan, pressing the wrong button, failing to push a lever all the way, looking at the wrong screen or dial, or activating the system at the wrong time. Typically such an analysis would be performed by considering each of a list of possible error mechanisms in turn, to avoid missing potential errors. Again, a combination of experience in conducting error analysis and an understanding of the workings of the overall activity are useful.
Before conducting a task or error analysis it is important to define what the output of the analysis is to be used for, as this will influence how the analysis is performed. For example, it may be that the investigator is only be interested in particular subtasks and activities – or that a particular level of detail is required, below which the analysis is useless and beyond which it is simply a waste of time and effort. Knowing the level of detail required is a key parameter as without this cut-off point, the analysis could go on almost indefinitely. A basic task analysis is a useful way for anyone to gain a clearer picture of any working environment. For more detailed analyses or situations where the task analysis is to provide the foundation for a larger set of activities, it is advisable to acquire the services of experienced practitioners.
The following is a basic overview of the key principles/stages:
break the overall task down into stages:
A task analysis is often useful in its own right. It may also be useful to conduct a complimentary error analysis. Again it is best to use an experienced professional for large-scale analyses – but for a basic assessment, the following method can be applied:
Print