A product may call an activity “submit an expense”, but the person doing it has to find a receipt, establish which budget applies, check a policy and perhaps ask someone for approval before the form becomes useful. Task analysis examines the work required to achieve a goal, including the parts that happen outside the interface.
It produces a structured account of actions, decisions, information and dependencies. The purpose is to understand what the person is trying to accomplish and where support is needed, rather than assuming that the product’s current sequence is the natural shape of the task.
Choose a goal with a clear boundary
Begin with a person and an outcome. “Use the dashboard” describes interaction with a tool; “work out which deliveries need attention before the afternoon dispatch” describes a goal. The latter leaves room to discover whether the dashboard is useful, incomplete or only one part of the work.
The boundary determines how much context to include. Too narrow, and the analysis omits the preparation that causes difficulty. Too broad, and it becomes an account of an entire role. Nielsen Norman Group’s introduction to task analysis describes collecting and structuring information about the actions people take to achieve their goals.
Distinguish the current activity from a proposed future version. If the team sketches the ideal process before observing the existing one, it may overlook responsibilities that the proposal has no way to support.
Collect the sequence and the reasoning
Observation through contextual inquiry or shadowing can reveal steps that are difficult to reconstruct from memory. Interviews can explain decisions, rare exceptions and actions that cannot be observed safely or within the available time. Use the sources together where possible rather than assuming one provides a complete account.
For a fictional delivery operation, watch how a dispatcher distinguishes a genuinely late parcel from a tracking update that has not arrived. The important work may involve comparing timestamps, contacting a driver and judging whether to reassure a customer. A list of clicks would omit much of the task’s difficulty.
Record the information required at each step, the tools used and any handoffs. Ask about exceptions: missing information, unavailable colleagues, interrupted work and situations in which the normal route is inappropriate. Verify the account with people who perform the work, while recognising that their routines may differ across roles and locations.
Use a representation that fits the complexity
A simple sequence may be enough for a short routine. Hierarchical task analysis breaks a goal into subgoals and operations, with plans describing their order and conditions. Cognitive task analysis pays closer attention to judgement, knowledge and other mental demands, particularly in expert work.
Choose the level of detail that could change the design decision. Recording every keystroke can obscure an important handoff; recording only broad stages can conceal the information needed to make a decision. A useful account is detailed where the uncertainty lives.
Turn the analysis into questions for the design
The delivery example might show that the dispatcher needs a reliable way to distinguish old information from a current exception. That could lead to a change in status presentation, an escalation process or a data-quality investigation. The analysis identifies the need and its context without requiring every problem to become a new interface feature.
Use the findings to inform user flows, realistic task scenarios and requirements. Then test the proposed support with the relevant people. A task diagram is an account to examine and revise, not proof that the resulting product will work simply because it follows the same boxes.