HTA Diagram Builder

Hierarchical Task Analysis (HTA) is one of the most widely used task analysis methods in human factors and ergonomics. Developed by John Annett and Keith Duncan in the 1960s, it describes how work is actually performed by breaking a high-level goal down into a hierarchy of sub-goals, operations and the plans that govern them.

Rather than modelling how people think, HTA focuses on what people do and in what order they do it to achieve a goal. That makes it the natural first step for almost any ergonomic, reliability or safety assessment, and the foundation that downstream methods such as SHERPA, HEART and THERP build on.

When to use HTA

• Understand the structure of a task before a risk or human-error assessment
• Identify training requirements and design procedures or checklists
• Support interface design by mapping user goals to system actions
• Provide structured input to methods such as SHERPA, HEART or THERP

When another method may fit better

• The task is purely cognitive with no observable actions
• You need to model dynamic, real-time decision making (consider GOMS or cognitive task analysis)
• The system does not yet exist and no analogous task is available to observe

An HTA is built from three elements. A goal is a desired end-state the operator is trying to reach, and sits at the root of the hierarchy. An operation is the lowest level of breakdown, a single action that does not need decomposing further for the purpose of the analysis. A plan describes how and when the sub-goals beneath a parent are carried out. Without plans the hierarchy is just a list; plans give it procedural meaning, so every parent node should have one.

Common plan types

Knowing when to stop

Decomposition should stop when further breakdown would not add value. A common guide is the P x C rule (Annett and Duncan, 1967): keep decomposing while the probability of inadequate performance multiplied by its cost stays above an acceptable threshold. Safety-critical tasks justify a lower threshold and therefore deeper analysis. Other practical stopping points are a single discrete action, a step that maps to one line in an existing procedure, or the analyst's judgement that more detail will not improve the assessment.

Tips for a clean hierarchy

• Completeness: the sub-goals at each level should fully account for their parent
• No overlap: sub-goals at the same level should not duplicate scope
• Consistent granularity: siblings should be roughly equal in complexity
• Action-oriented: start each sub-goal with a verb, for example "Check pressure" or "Secure hatch"