2026-09-15
Nural Choudhury
Task analysis is the systematic study of how people currently perform a task, breaking it down into the steps, decisions and knowledge each one requires.
The redesign that keeps re-arguing what users need because nobody has watched them do the work, and the feature list with no way to tell which step is the hard one.
Decide which steps to simplify, where errors happen, and what guidance the interface has to carry. It feeds wireframes and prototypes, and tells you which parts of a redesign to prioritise first.
the observation record from watching people work the task, the hierarchical decomposition with its plan notation, goal, sub-goals, and operations, and the list of friction and error points against each step.
Hierarchical task analysis, the form most design teams mean when they say “task analysis”, comes from British occupational psychology. John Annett and Keith Duncan published the foundational method in “Task analysis and training design” in 1967, then developed it further with Rob Stammers and Mike Grey in a fuller HMSO training report in 1971. Neither paper mentions software: the original goal was to determine what a task demanded so training could be designed around its real complexity rather than a trainer’s assumptions.
Annett and Duncan’s method breaks a goal into sub-goals, and sub-goals into individual operations, with a plan attached at every level stating the order and conditions under which each part runs. Their own governing rule is the part most modern treatments drop: re-describe a step in more detail only when getting it wrong would cost more than the extra analysis. That rule, not the tree diagram itself, is what keeps the technique usable rather than endless.
Cognitive task analysis studies the reasoning behind an action, not the action alone: the decisions, knowledge retrieval, and judgement calls that an observable step alone does not show. It emerged in the 1980s from several converging fields, human factors, instructional design, and cognitive engineering among them, rather than from one author. Gary Klein’s research into naturalistic decision-making, and the Critical Decision Method he built with Beth Crandall at Klein Associates for eliciting how experts reason under pressure, are among its most cited contributions.
Jobs to be Done did not grow out of task analysis. It is a separate tradition, often conflated with task analysis because both aim to explain how people accomplish goals. Tony Ulwick developed the outcome-driven approach that became JTBD through the 1990s, first applying it commercially in 1992, and Clayton Christensen adopted the underlying idea and gave it the name in 2003.
The two ask different questions: task analysis documents how someone currently performs a sequence of actions, and JTBD asks what progress they are trying to make regardless of how they perform it today.
Journey mapping, not Jobs to Be Done, is the method gaining ground now, and it works at a different altitude rather than replacing this one. A journey map traces the arc of a relationship across touchpoints, and task analysis holds the step, decision, and knowledge detail no journey map carries.
CMSWire’s 2026 review of customer experience practice found most maps were out of date the moment they were approved, a case for treating the two as complementary, not for dropping either.
I reach for task analysis before a new product design, when a redesign needs to know how people use the current one, or when errors keep recurring, and nobody can say exactly where they start. I skip it when a handful of usability sessions would answer the same question faster.
MeasuringU’s 2024 survey of 444 UX professionals across 37 countries found a particularly sharp drop in task analysis use between 2022 and 2024, alongside requirements gathering and contextual inquiry. I read that as budget pressure, not the method losing its case, because it remains the most used form of task analysis, and the Interaction Design Foundation still teaches it as the standard starting point.
Expect to justify the time it takes now, so scope it to the decision it has to serve, the discipline Annett and Duncan’s stopping rule already asks for.
State the specific question before you observe anyone: which task, whose version of it, and what decision the findings will inform. I treat this as a planning conversation, not fieldwork time, and I don’t start observing until I can state the question in a single sentence.
Prioritise tasks that are frequent, critical, or already generating errors, and select participants who span the real range of skill and context rather than the most available ones. I would rather recruit for range than for convenience: a study built entirely from confident, experienced users tells me nothing about where the task breaks.
Watch people perform the task in its natural setting, and ask them to narrate their thinking as they go. I never trust a single session to show me a pattern rather than one person’s quirk, so I keep running sessions until the same friction shows up twice.
Break the goal into sub-goals, and the sub-goals into actions, writing a plan at each level that states the order and conditions governing it. I set my stopping rule, Annett and Duncan’s own test of whether the extra detail is worth its cost, before I start, not forty boxes into a diagram.
For every step, note what triggers it, what the person must already know, and where they hesitate or make a mistake. I turn each finding into a specific action: cut the step, merge it with another, add a default, or add a confirmation before anything irreversible.
Take renewing a car insurance policy online. The top-level goal, 0, is “renew the policy”, with a plan stating that steps 1 to 4 run in sequence unless step 2 triggers a call to a human agent, in which case control passes to step 5.
Two observation sessions were enough to show that step 2 is where people open a second tab to check a competitor’s price before deciding whether to continue or call. That branch condition, not just the sequence of five steps, is what the plan notation exists to capture, and it is the detail a flat, unbranched flowchart would have missed entirely.
I have watched a task analysis this thorough get read as a specification for the current workflow rather than a critique of it. Documenting a process in this much detail lends it an authority I do not think it deserves, and the redesign quietly inherits assumptions nobody chose to keep.
When I watch a skilled person work, I am usually watching a route they built around a flawed system, not the task as it was designed to work. If I record that route as “how the task is done”, I carry the workaround straight into the redesign, and the next version still needs one.
I can make task analysis precise about sequence and thorough about steps, but it never tells me why the person wants the outcome in the first place. That is exactly the gap Jobs to be Done exists to close, a genuinely different tool for a genuinely different question, not a missing subsection of this one.
Working a goal down to individual actions, with a plan written at every branch, takes real analysis time. I have seen that investment exceed the value of the insight on a simple product with one main task and few decision points, exactly what Annett and Duncan’s stopping rule was built to prevent.
it studies what people do to complete a task, not what they say they do or what a designer assumes, because tacit habits and workarounds rarely survive being described from memory.
John Annett and Keith Duncan published hierarchical task analysis in 1967 to identify industrial training needs, then developed it further with Rob Stammers and Mike Grey in a 1971 report.
task analysis documents how someone currently performs a sequence of actions. Jobs to be Done, a separate framework from Tony Ulwick and Clayton Christensen, asks what progress they are trying to make regardless of how they do it today.
hierarchical task analysis documents observable steps and their order. Cognitive task analysis studies the reasoning behind those steps, the decisions and knowledge an observer cannot see directly.
skip it for a simple product with one obvious task and few decision points, where a handful of usability sessions answer the same question without the cost of a full decomposition.
| Fact | Detail |
|---|---|
| Originators of hierarchical task analysis | John Annett and Keith Duncan |
| First publication | “Task analysis and training design”, Occupational Psychology, volume 41, 1967 |
| Fuller method | HMSO training report, Annett, Duncan, Stammers and Gray, 1971 |
| Original purpose | Working out training needs in industrial and military settings, not interface design |
| Core mechanism | A goal decomposed into a hierarchy of sub-goals and operations, governed by a plan stating the order and conditions for each step |
| Cognitive task analysis | Emerged in the 1980s from several converging fields rather than one author; Gary Klein’s naturalistic decision-making research and the Critical Decision Method are among its most cited contributions |
| Jobs to be Done | A separate framework, built by Tony Ulwick from the early 1990s and named by Clayton Christensen in 2003, not a branch of task analysis |
A content audit is a catalogue of every piece of content you own, scored against what it is supposed to do, so you can decide what to keep, fix, merge or kill.
Read it
Information architecture structures content so people can find it: choosing an organisation scheme, writing labels, building navigation and search, and testing whether the structure holds under a real task.
Read it
A wireframe shows a screen’s structure without visual design, and a prototype simulates its behaviour, so a team can test both before committing to development.
Read it
A diary study is a longitudinal research method in which participants record their behaviour and experience in their environment over days or weeks, revealing patterns that a single session cannot.
Read it
User research is the systematic study of what users do, need and struggle with, combining qualitative depth with quantitative scale to ground design in evidence.
Read it
An interface pattern is a solution to a recurring design problem, refined through enough use elsewhere that the person encountering it doesn’t have to figure out how to use it.
Read it