curiositech/stanton-2006-hierarchical-task-analysis

Hierarchical Task Analysis (HTA) Skill

license: Apache-2.0

Metadata

• Skill Name: Hierarchical Task Analysis
• Source: Hierarchical Task Analysis: Developments, Applications and Extensions by Neville A. Stanton
• Domain: Systems analysis, human factors, design methodology
• Activation Triggers:
  • User mentions "task analysis," "goal decomposition," "system design," "error prediction"
  • Questions about breaking down complex work, designing training, or preventing failures
  • Requests for systematic analysis of human-system performance
  • Problems involving "how should this work?" vs. "how does this currently work?"

When to Use This Skill

Load this skill when facing:

• Complex system design challenges where you need to understand what must be achieved before specifying how
• Error-prone processes requiring systematic identification of failure modes
• Training design where you need to specify what competence looks like
• Interface design where you need to understand information requirements at each decision point
• Function allocation decisions about what humans vs. automation should do
• Team coordination problems requiring clarity on who does what when
• Over-specified processes where procedures are bloated but performance still fails
• "Why do people keep making this mistake?" questions that suggest missing context or poor feedback
• Analytical paralysis where you can't decide what level of detail is sufficient

Core Mental Models

1. Goal-Based vs. Task-Based Thinking

HTA describes what the system must achieve (goals), not what people currently do (tasks). A goal is measurable: "temperature maintained within 5°C of setpoint" not "operator monitors temperature." This distinction is profound:

• Goals are solution-neutral—multiple methods can achieve them
• Goals have success criteria—you can measure achievement
• Goals enable comparative analysis—current vs. proposed methods
• Goals reveal function—why this matters to the system

The shift: From "document what happens" to "specify what must be accomplished."

2. Plans as Coordination Intelligence

Plans are control structures, not sequences. They specify:

• Conditions for sub-goal activation (if X, then Y)
• Contingencies (if normal path blocked, alternative Z)
• Parallel operations (do A while monitoring B)
• Exit criteria (repeat until condition met)

Plans answer: "When does this matter? What triggers it? How do you know you're done?" They encode the contextual intelligence about goal relationships. Without plans, you just have a list. With plans, you have a control model.

3. The P×C Stopping Rule: Analytical Economy

Stop decomposing when (Probability of inadequate performance) × (Cost of inadequate performance) is acceptable. This principle:

• Directs analytical effort toward high-variance, high-consequence components
• Prevents over-specification of routine elements
• Maintains focus on system-critical goals
• Acknowledges that "adequate" is often sufficient

The discipline: Not "analyze everything to the same depth" but "analyze where failure matters most."

4. Three Governing Principles (The Theoretical Foundation)

1. Operations are defined by goals measured in real terms — not activities, but achievements with success criteria
2. Operations decompose into sub-operations — each with its own performance standard
3. Relationships are hierarchical inclusion — sub-goals contribute to superordinate goals; this is not mere temporal sequence

These principles prevent HTA from degenerating into procedural flowcharts. They maintain the discipline of goal-directed analysis.

5. HTA as Analytical Infrastructure

The sub-goal hierarchy is a substrate for multiple analyses, not an end product. Once you have the goal structure and plans:

• Add "information required" column → interface design
• Add "error modes" → SHERPA analysis
• Add "allocation" → human vs. automation decisions
• Add "training requirement" → curriculum design
• Add "coordination requirements" → team design

The leverage: Build the goal framework once, annotate it for many purposes.

Decision Frameworks

When analyzing a new system or process:

IF you're documenting how things currently work
THEN you're probably doing task analysis, not HTA—shift to specifying what must be achieved

IF your analysis reads like a procedure manual
THEN you've lost the goal-based perspective—reframe in terms of measurable achievements

IF you can't specify success criteria for a "sub-goal"
THEN it's probably an activity description, not a goal—ask "what does this accomplish?"

When deciding decomposition depth:

IF the sub-goal is routine and failure consequences are minor
THEN stop—mark as "adequate" and move to higher-variance components

IF the sub-goal has high error variance OR high failure cost
THEN continue decomposition until you understand failure modes

IF you're decomposing because "it feels incomplete"
THEN you're probably over-analyzing—apply the P×C rule explicitly

IF subject matter experts say "anyone can do that part"
THEN that's a signal to stop—focus on the non-obvious elements

When writing plans:

IF your plan is just a sequence (do 1, then 2, then 3)
THEN you're missing control logic—identify decision points and conditions

IF you can't specify what triggers each sub-goal
THEN you don't understand the coordination—interview experts about context

IF the plan has no contingencies
THEN you're describing the ideal case only—probe for "what if X goes wrong?"

IF experts disagree about the plan
THEN you've found important variance—document both strategies and conditions for each

When using HTA for downstream analysis:

IF designing training
THEN focus on high P×C sub-goals and complex plan structures (→ load hta-as-springboard-for-specialized-analysis.md)

IF predicting errors
THEN examine each sub-goal for failure modes and each plan for coordination breakdowns (→ load failure-modes-and-error-variance.md)

IF designing interfaces
THEN identify information requirements at each plan decision point (→ load the-gap-between-knowing-and-doing.md)

IF allocating functions
THEN examine which sub-goals require human judgment vs. algorithmic control

IF you're stuck choosing between abstraction levels
THEN consider multiple parallel analyses at different levels (→ load hierarchies-of-abstraction-enable-action.md)

Reference Documents

| Reference File | When to Load | Key Content | |----------------|--------------|-------------| | goal-decomposition-as-problem-solving-substrate.md | When you need to understand WHY goal-based analysis is fundamentally different from task description; when justifying HTA to stakeholders | The theoretical distinction between goals and activities; why solution-neutrality matters; how the same HTA supports multiple applications | | stopping-rule-and-analytical-economy.md | When deciding how detailed your analysis should be; when facing scope creep; when stakeholders want "complete" documentation | The P×C rule explanation; practical guidance on stopping criteria; why "adequacy" is the right standard; handling analytical effort strategically | | plans-as-coordination-intelligence.md | When writing plans; when sub-goals seem like a flat list; when analyzing decision-making or coordination | What plans actually are; how they encode control logic; examples of conditional, parallel, and iterative plans; why plans are where expertise lives | | hta-as-springboard-for-specialized-analysis.md | When moving from HTA to training design, error prediction, or interface design; when HTA feels like "just documentation" | How to extend HTA with additional columns; examples of tabular annotations; the framework pattern that makes HTA valuable | | three-governing-principles-of-goal-based-systems.md | When your analysis feels unprincipled; when teaching HTA; when someone challenges whether HTA is "theory" or just notation | The three principles; how they derive from control theory; why they prevent common degenerative patterns; theoretical grounding | | failure-modes-and-error-variance.md | When designing for reliability; when analyzing incidents; when applying SHERPA or similar error prediction methods | How to identify error modes systematically; the relationship between goals and failure; error variance as a design driver | | the-gap-between-knowing-and-doing.md | When designing interfaces, job aids, or information systems; when people "know what to do but don't do it" | Information requirements at each sub-goal; the distinction between knowledge and executable understanding; what information must be available when | | hierarchies-of-abstraction-enable-action.md | When struggling with the "right" level of analysis; when different stakeholders need different views; when detail obscures comprehension | How abstraction level affects usefulness; the problem of completeness vs. comprehensibility; strategies for multi-level analysis |

Anti-Patterns

The Procedural List Masquerading as HTA

Symptom: Your "HTA" is just numbered steps with no goal statements or success criteria
Why it fails: Loses solution-neutrality, can't support multiple applications, provides no basis for improvement
Antidote: For each "step," ask "what does this achieve?" and "how would you know if it succeeded?"

Over-Decomposition of Routine Elements

Symptom: Spending equal effort on high-variance critical sub-goals and routine trivial ones
Why it fails: Wastes analytical effort, obscures what matters, creates maintenance burden
Antidote: Apply P×C rule explicitly; mark adequate sub-goals and move on

Plans as Afterthoughts

Symptom: Writing plans as "do 1, 2, 3" after building the hierarchy
Why it fails: Misses the control intelligence; plans and goals should co-evolve
Antidote: When decomposing a goal, immediately ask "under what conditions does each sub-goal matter?"

Confusing Goals with Activities

Symptom: "Sub-goals" like "operator presses button" or "system displays screen"
Why it fails: These describe implementation, not achievement; no success criteria
Antidote: Reframe as "temperature setpoint updated" or "alarm condition communicated to operator"

HTA as Documentation Rather Than Analysis

Symptom: Producing the hierarchy diagram and calling it done
Why it fails: Misses the entire point—HTA is infrastructure for further analysis
Antidote: Always ask "what decision does this HTA support?" and extend it for that purpose

The Completion Fallacy

Symptom: Belief that HTA is "done" when every leaf node is equally detailed
Why it fails: Completeness is not the goal; analytical economy is
Antidote: Stopping is a principled decision, not a failure; document why you stopped at each node

Ignoring Error Variance

Symptom: Analyzing to arbitrary depth without considering where failures actually occur
Why it fails: Allocates effort uniformly rather than strategically
Antidote: Gather empirical data or expert judgment about error frequency and consequences

Shibboleths: Signs of Deep Understanding

Surface-Level Understanding Says:

• "HTA is a way to document tasks"
• "The stopping rule is subjective"
• "Plans are just the sequence of steps"
• "HTA tells you what people do"
• "Good HTA is complete and detailed throughout"

Deep Understanding Says:

• "HTA specifies goals with measurable success criteria—it's solution-neutral"
• "The P×C stopping rule is a principle of analytical economy—stop where failure doesn't matter enough to justify further analysis"
• "Plans encode control logic—they're the conditions and contingencies that trigger sub-goals, not just ordering"
• "HTA tells you what the system must achieve—current methods are just one possible solution"
• "Good HTA decomposes high-variance, high-consequence elements and marks low-criticality elements as adequate"

Green Flags (They've Internalized It):

• Distinguishes sharply between goals and activities
• Immediately asks "how would you measure success?" when discussing sub-goals
• Recognizes that plans contain the expert knowledge about context
• Treats HTA as infrastructure and automatically thinks about what to annotate it with
• Uses P×C reasoning explicitly when deciding scope
• Sees hierarchical decomposition as enabling analysis, not as documentation structure
• Understands that sub-goals can be achieved by multiple methods (solution-neutrality)

Red Flags (Superficial Application):

• Produces hierarchies that are just procedure manuals with indentation
• Can't explain when or why to stop decomposing
• Writes plans that are all "do 1, then 2, then 3" with no conditionals
• Treats HTA as a deliverable rather than an analytical tool
• Aims for "completeness" without considering what the analysis is for
• Can't distinguish between describing current practice and specifying required achievement
• Missing or trivial success criteria for goals

---

Remember: HTA is not notation—it's a theory of goal-directed performance grounded in control theory. The hierarchy describes what must be achieved. The plans describe how achievement is controlled. The P×C rule directs analytical effort. The three principles maintain discipline. The tabular extensions enable application-specific analysis. When you find yourself lost, return to the question: "What must be accomplished, and how will we know if it succeeded?"