research methods
Task analysis
What is task analysis?
Task analysis is breaking a goal down into the actual steps and sub-steps people take to achieve it - the decisions, actions and information needed at each point. It replaces a vague sense of "they just book a flight" with the real, often surprising sequence, exposing where effort, confusion and errors actually live so you design for the task as it is, not as you imagine it.
Also known as: task analysis, hierarchical task analysis, task breakdown
Prefer to watch?
Watch the recap 0:49
The demo
“Book a flight.” Sounds like one action. Click to break it down, step by step - and watch how much is really hiding inside, and where it quietly goes wrong.
What this demo shows (text version)
A single goal, "book a flight", starts as one line and expands as you drill in: into sub-tasks (search flights, choose a flight, enter passenger details, pay) and then into the individual steps and decisions inside each (pick dates, compare prices and times, decide on bags, re-enter details the site forgot, choose a seat, handle a declined card). A counter tracks how the step count balloons, and a friction point - re-entering passenger details the form lost - is highlighted.
The point is that a simple-sounding goal hides a long, messy sequence, and the effort, confusion and errors live in steps you'd never list from memory - especially at the seams between sub-tasks. Task analysis makes that real sequence visible so you can cut needless steps, fix the spots where people lack information, and design for the task as people actually perform it rather than the tidy version you imagined.
Decompose the goal into real steps and you discover the task is bigger and messier than it looked - hidden sub-steps, decision points, and moments where errors and drop-off cluster. Map what users actually have to do (not the happy path you pictured), and you can see exactly where to simplify, prevent errors, or remove a step entirely. You can't streamline a task you haven't actually broken down.
"Book a flight" sounded like one thing - until you expanded it and a dozen hidden sub-steps and decisions tumbled out, with the friction sitting exactly where you'd never have guessed. That's task analysis: it turns an airy goal into the concrete sequence people really perform, so the pain points stop being invisible.
The common form is hierarchical: a top-level goal, broken into sub-tasks, broken again into individual actions and decisions, until you reach steps small enough to design for. The act of decomposing is where the insight lives - the steps you forgot, the decision that needs information the user doesn't have, the place two systems hand off and things fall through.
It pinpoints where to intervene. Counting the real steps reveals needless ones to cut; examining each decision shows where people lack the information to choose; and the seams between sub-tasks are where errors and abandonment concentrate. It's the groundwork for simplifying a flow, preventing errors, and deciding what to automate or remove.
Crucially, map the task as users actually do it, not the idealised happy path - including the workarounds, the back-and-forth, and the error-recovery loops. Build it from observation and interviews, not assumption, or you'll optimise a task nobody performs. It complements user flows and journey maps: those show the route; task analysis shows the work at each stop.