What is Task Analysis?

Task analysis is the systematic study of what users do to achieve a goal: the sequence of actions and sub-tasks, the decisions made along the way, the information and tools required at each step, the conditions and interruptions that shape the path, and the goals that sit above the task. The output is a structured description (often a hierarchy or a flow) that shows the work at a level of detail the team could not have guessed and users could not have recited. The method descends from human factors and ergonomics, where it was developed to design equipment and procedures around operators' real actions, and it entered UX as the foundation for designing flows, writing task scenarios, and understanding where products fit into larger workflows. Its defining insight is that tasks are rarely what the product's feature list implies: "submit an expense" is one button in the app and a forty-minute job involving receipts, a spreadsheet, a manager, and a policy PDF in the user's life.

The Main Forms

Hierarchical task analysis (HTA). The classic: the goal at the top, decomposed into sub-goals and then into operations, with plans specifying the order and conditions ("do 1, then 2 and 3 in any order; do 4 only if..."). Rigorous, thorough, and heavy; well suited to complex professional workflows.

Cognitive task analysis. Focuses on the thinking inside the task: what the user needs to know, decide, remember, and judge at each step, and where the mental demands (cognitive load) concentrate. Essential for expert work, where the hard part is invisible.

Workflow and sequence analysis. Lighter, linear descriptions of the steps, actors, artifacts, and handoffs, the everyday product-team form, feeding directly into user flows and journey maps.

Conducting One

1. Pick the goal and the user.
One goal, one type of user, stated in their terms ("get reimbursed for a trip"), because tasks decompose differently for a novice and an expert, and for different roles.

2. Gather from observation first, interviews second.
People cannot recite their own tasks accurately; they skip steps they've automated and forget the workaround. Contextual inquiry, shadowing, and recorded walkthroughs of the real task (a participant-recorded screen and voice session, the kind a Ballpark study collects) capture the actual sequence; interviews then fill in the reasoning and the exceptions.

3. Decompose to the level the decision needs.
Stop when further detail wouldn't change the design; a task analysis can descend to keystrokes and rarely should.

4. Capture conditions, errors, and variants.
What happens when the receipt is missing, when the manager is away, when the total exceeds the limit; the branches are where products break.

5. Validate with users.
Walk the analysis back through the people who do the task; the corrections are usually the most valuable data.

What It Feeds

Task analysis is the foundation beneath several other artifacts. Realistic scenarios for usability tests come from it. User flows that include the unhappy paths come from it. Requirements that reflect real work, help content that matches actual steps, and structures organized by task rather than by department all draw on it. And it locates opportunity: the step that takes longest, the handoff that fails, the information users need and don't have, each a candidate for design to remove or support.

The Short Version

Task analysis decomposes a goal into the steps, decisions, inputs, and conditions of the real work, discovered by watching people do it and confirmed by asking them. Choose one goal and one user, observe before interviewing, decompose only as far as the decision needs, capture the branches, and validate. It replaces the team's assumption about how a task works with the user's reality, which is usually longer, messier, and more interesting.