Task analysis is an excellent tool that can be used in many different trades. Today we will discuss the benefits of using task analysis for product design, supporting a training needs analysis, and for supporting a safety-focused analysis. 


If you are designing products, processes or systems, then task analysis is for you.  It can be used to sketch a proposed sequence of tasks and tool use for review by potential users and designers in order to reach consensus on the final design.  A well constructed task analysis that is kept up to date then becomes a communication tool that synchronizes the efforts of the design team, the documentation team, and the training teams.  

When designing a product, specific uses for task analysis might include:

  • Predict difficulties in product or system use.
  • Evaluate systems against usability or functional requirements.
  • Understand the difficulties of using existing products.
  • Develop training manuals.
  • Determine critical information that needs to be displayed.
  • Determine information required to be visible on screen during different aspects of product or system use.
  • Predict possible difficulties in using different design alternatives.
  • Design operating procedures
  • Allocate tasks between people and machines.


In assessing training needs, task analysis can be used to document what is currently being carried out, where current training is useful, and to identify where there is room for improvement.  Specifically, task analysis can:

  • Assess ease or difficulty of learning and transfer of knowledge as old systems are updated with new systems (training gap analysis).
  • Identified misplaced, over/under training.
  • Determine curriculum requirements.
  • Consolidate training requirements across departments.
  • Analysis of training needs.


The Systematic Human Error Reduction and Prediction Approach (SHERPA) is one of the most comprehensive and validated approaches to predicting human error.  It have been used widely in high risk industries such as oil and gas, nuclear power, and aerospace operations.  The benefits of safety analysis include:

  • Prediction of tasks where error rates may be unacceptably high.
  • Documentation of the possible consequences of mistakes.
  • Identification of safety critical tasks.

Hazard Analysis: Reducing Risk of Harm for Trick or Treaters

Screen Shot 2018-07-18 at 3.36.32 PM.png


This year, we thought we’d celebrate Halloween by performing a basic job hazard analysis for Trick or Treaters to help minimize harm and maximize fun this holiday season.

Hazard analyses are incredibly useful because they identify potential hazards and harms before they occur, by thoughtfully focusing on each step of a particular task (OSHA 3071).

As always, the first part of performing a job hazard analysis is to write out all the steps that must be taken to perform a job. Below, we have listed the basic steps of going Trick-or-Treating:


  1. Put on your costume.
  2. Get a sturdy, empty bag that can be filled with candy.
  3. Plan a route to walk for trick or treating.
  4. Leave your house and follow the planned route, planning to only go to houses with their porch lights on.
  5. Approach a house with the porch lights on, walk up the drive, and ring the doorbell.
  6. When the door opens, exclaim, “Trick or treat!”
  7. Hold open your bag to be filled with a piece of candy by the homeowner.
  8. Say, “Thank you!”
  9. Leave the house and walk back towards the street.
  10. Proceed to the next house.
  11. Follow steps 5-10 until you have filled your bag with candy.
  12. Walk home.
  13. Eat your candy!

Next, when performing a job hazard analysis, you should create and fill out a hazard analysis form (ours were modeled on OSHA forms from the OSHA Publication 3071), which will allow you to consider step by step what any potential hazards are that you may face while Trick or Treating.

Screen Shot 2018-07-18 at 3.37.47 PM.png
Screen Shot 2018-07-18 at 3.38.10 PM.png
Screen Shot 2018-07-18 at 3.38.31 PM.png

Next, putting the steps and the hazard analysis form data into TaskArchitect will organize the analysis and allow you to create properties for each of the properties found on the hazard analysis form. 

Screen Shot 2018-07-18 at 3.40.19 PM.png

In addition to following OSHA standards for what to include on a hazard analysis form, we included a consequence rating and likelihood rating, which we multipled to create an overall risk factor. This overall risk factor will help you prioritize and understand the potential hazards that will face Trick or Treaters. 

This holiday season, we recommend that Trick or Treaters inspect their candy carefully, as tampered candy carries the greatest hazard risk factor for Trick or Treaters. The next greatest risk factor comes from the issue of decreased visibility of the Trick or Treater in certain costumes. We then found that the trip hazards for walking down uneven paving or poorly lit areas were the next highest risk factor, primarily because of the high likelihood rating. Finally, the trip hazards from poorly hemmed costumes are important to consider - though they don't carry the critical risk that tampered candy or decreased visibility carry. 

Following these recommendations will help ensure that you have a fun and safe Halloween! 

Task Analysis Case Study: Cognitive Task Analysis

EUROCONTROL is an intergovernment organizational that helps its 41 member states to operate a safe and efficient air traffic management system throughout Europe.  Founded in 1960, EUROCONTROL works to create a commonly agreed upon air traffic management system by providing expertise in the operational and technical elements of air traffic control (www.eurocontrol.int).  In 2007, the European Air Traffic Management Programme under EUROCONTROL conducted a cognitive task analysis of the First Air Traffic Support Tools Implementation (FASTI) and published their results.


In 2007, the FASTI programme was being designed to co-ordinate the implementation of a common air traffic management system across Europe. Three tools were included in the concept:

  • Medium Term Conflict Detection (MTCD) - an automated algorithm that could assist the operator by searching for conflicts as far as 20 minutes in the future.
  • Monitoring Aids (MONA - a set of automated alerts and warnings to assist the operator in monitoring the progress of aircraft.
  • System-supported Co-ordination (SYSCO) - the ability to employ screen to screen dialog in the handing off of flights from one controller to another.

The deployment of FASTI has the following aims:

  • Increase sector capacity, improve flow rates, and reduce delays.
  • Increase potential for flexibility, changes in operational practices and changes in conditions specified in Letters of Agreement (LOAs).
  • Introduce the potential for cost savings through the automation of routine tasks, flexible staffing, system and airspace development, and controller training.
  • Support an improved quality of service to airspace users in the form of optimum profiles and routes, and less ATC interventions in flight.

The purpose of this case study was to understand the impact of implementing automated tools like FASTI into the human work system of air traffic management.

Tools like TaskArchitect are key to the development of a detailed cognitive task analysis.  As you can see in the image below, the first part of the analysis is the deconstruction of the air traffic management task into a hierarchical structure. 

The authors first established the overall goal of providing air traffic control services and then deconstructed this goal into 407 separate tasks.  Breaking out these tasks into subtasks aided the project for the capture of the data and served as a conduit to the other analysis tools.

Below shows an example of the authors breaking a task into subtasks:

Screen Shot 2018-07-18 at 3.34.24 PM.png

The TaskArchitect Team provided on-site support to the CMC team in order to assist with the application of TaskArchitect within the project. This included assistance in the development of the data structure to support the Hierarchical Goal Analysis, customized reports to clearly show the structure of the data collected (Perceptual Control Theory Control Loops), and export of the data to both the Linux based IPME Tool and FORTRAN based OSD drawing tool.

TaskArchitect was chosen as the data collection tool for the project because of the ease of configuring it to new analysis methods, the speed of data entry and data display, and the flexibility of output formats. The wide range of outputs helped with Subject Matter Expert Reviews and review of the project progress by the project sponsors. The ease of learning to use TaskArchitect meant that at times the Subject Matter Experts (SMEs) could re-work the data in TaskArchitect to show the required changes. Because of these benefits, it has become the central repository for the data, with easy export to IPME and CMC’s in-house OSD drawing tool. 

The export of Hierarchical Task Analysis data directly to IMPE, including perceptual and cognitive aspects of the tasks allowed the task networks to be automatically generated—saving time and increasing the ease of re-working the data set. Export of the data to CMS’s OSD drawing tool meant that SMEs could review the data in Operational Sequence Diagrams, and then, on the fly, the Hierarchical Goal Analysis data could be re-worked and re-presented for further review. 

TaskArchitect’s rapid data entry and display, compared to the tools previously used (ACCESS and Excel) reduced the project timelines substantially and allowed the team to produce powerful reports and diagrams that they could not have contemplated trying to produce before. By enabling the easy movement of data between other tools during and after the reviews, TaskArchitect has helped CMC and DRDC to create a very powerful tool suite.

When to Stop Breaking Down Tasks in an HTA


There comes a point in every task analysis where it is not worth redescribing particular tasks into any greater detail. With experience, you will be able to judge this point reasonably well. A stopping rule is a rule of thumb that you apply to your work in order to decide that more a detailed analysis of a task than the current level is not required in order to solve the current problem being studied.


A commonly quoted stopping rule is that you should only continue breaking down tasks as long as the consequences of undertaking an incorrect action were considered potentially critical, either because there was a very low probability that the action would be needed, or because the system cost of an error was very low. In general, the likelihood of something occurring times the severity is a description of risk.

In task analysis, we call this the P x C Rule. P is an estimate of the probability of inadequate performance at a task, and C is the cost of that inadequate performance including injury or commercial loss.   Redescription should stop at the point that the product of the probability of an error and its potential consequences fell below a particular criterion level.

While this is great in theory, it is often difficult to measure both the error probability and the error cost in reality. Therefore, it is seldom applied formally and is best treated as a guiding principle rather than an invariant rule.


As discussed in our blog series, 'The 7 Steps of Hierarchical Task Analysis', every task analysis has a goal or purpose.  You can make your stopping rule dependent on the purpose of your analysis. For instance, if it the purpose of your analysis is to describe the scope of a system to be designed, then an initial high-level analysis would be appropriate. The stopping rule might be 'Stop when sufficient level of detail has been discovered in order to understand the breadth and of the system.'


This is one of the most widely used stopping rules.  If you are designing a system, you continue to redescribe tasks until all the main interfaces or functional elements within the interface can be identified.


Workload is often measured by the amount of resources needed over a period of time.  Once you define the properties you are using to define workload, you would continue redescribing tasks until you are able to capture all the workload information you require.  This varies based upon the type of workload you are measuring.  If you are measuring the workload of many teams, you might stop when the measures for each team are know.  If you want to know how workload is distributed within teams, then you would keep redescribing tasks until the workload of each person can be assessed.


In planning manpower requirements, often described as job task analysis, you would continue to redescribe tasks until all the underlying knowledge and skills of the job description can be defined in sufficient detail.  For manpower planning purposes, you will only need to define skills and knowledge requirements at a relatively global level.


When you are developing a training program, you not only have to define the knowledge and skills needed to support task performance, but also you must review the information and decision-making necessary to support plans. This is the obvious stopping rule for Training Need Analyses (TNAs). 


What if you have more than one purpose in mind for your task analysis?  If your HTA is being used for more than one purpose, you should apply different stopping rules for the collection of different data. For example, if your HTA is to be used for both defining the training requirements and for assessing the interfaces, the data that are collected for a TNA could be obtained for higher-level tasks than that required to assess the interfaces.

Task Analysis Case Study: Error Analysis

Humansystems® was founded in 1982 to provide Human Factors & Ergonomics support to Canadian industry, government, and business.  HSI® consultants' expertise and experience cover most aspects of Human Factors and Ergonomics. The HSI® framework allows them to undertake a range of projects in Human Factors / Ergonomics from office layout to full-scale research promptly and cost effectively.


In two projects for a nuclear power provider, Humansystems® chose TaskArchitect because of its’ integration of a graphical hierarchy of the tasks with user definable data collection forms.  While other mixes of tools provided part of this functionality, none of them brought it together in a package to support Hierarchical Task Analysis.

The Humansystems® projects identified the potential for errors in existing standby generator and chlorine injection systems and provided design advice to eliminate those errors in the replacement systems.  Additionally, Humansystems® identified areas where errors would be reduced through features of the new designs (i.e. improvements that were independent of Human Factors issues).  A combination of the review of technical material, informal interview and equipment reviews allowed them to build a comprehensive list of tasks.


TaskArchitect’s ability to take the work out of moving tasks around, through automatic renumbering and adjustment of the hierarchy made the application of Hierarchical Task Analysis within the project both easier and faster.  Features such as support for the structuring of plans made it easier to adopt a consistent style of analysis.  The display of task data in columns next to the task list brought a level of familiarity to TaskArchitect, it looked like the kind of information they would traditionally collect using Excel.  Simple export to Excel helped them to review the data with their subject matter experts at a distance, and new features such as the export of task hierarchy diagrams are anticipated to make bridging that distance even easier.

The clarity of the task hierarchy diagrams and their ease of production helped the analyst to review and interpret the data more easily than they could with more text based tools.