--- license: Apache-2.0 name: stanton-2006-hierarchical-task-analysis description: Hierarchical Task Analysis methodology for decomposing complex tasks into structured subtask hierarchies category: Cognitive Science & Decision Making tags: - hta - task-analysis - hierarchical - methodology - human-factors --- # 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?"