Task Analysis¶

Method — instantiates Tacit Knowledge Elicitation

Maps the visible structure of the work — its steps, sub-tasks, actors, tools, and constraints — into an explicit skeleton that shows what happens, providing the scaffold onto which the hidden judgment can later be hung.

Before you can elicit the tacit judgment inside a task, you often need to know the shape of the task itself. Task Analysis maps the observable work: the sequence of steps and sub-tasks, who does what, which tools and inputs are involved, the hand-offs, and the constraints the work runs under. Its defining move is that it stays on the visible surface — it documents what is done and in what order, deliberately not (yet) how the expert decides. This is a feature, not a shortfall: the explicit work skeleton it produces is the scaffold that deeper elicitation hangs its findings on, and it is often the cheapest, fastest way to see where the cognition-heavy decision points even are. It is the "here is the whole process, laid out" mechanism — the map of the terrain before anyone charts the hidden trails.

Example¶

Before studying how veteran ramp crews turn an aircraft around fast, an analyst first does a task analysis of the turnaround itself. The output is an explicit decomposition: the parallel and sequential steps (chocks, ground power, catering, fueling, baggage, lav/water, boarding), which crew or vendor owns each, the tools and inputs each needs, the hand-off points, and the hard constraints — fueling can't overlap boarding beyond a limit, pushback needs the tug staged, the gate has a slot.

Laid out, the map immediately shows where the judgment lives: the critical-path decisions about which steps to compress when the inbound arrives late, and who gets sequenced first. The task analysis itself doesn't capture that judgment — it captures the structure that makes the judgment legible. A veteran's tacit "when we're twenty minutes down, I hold catering and pull baggage forward" is invisible to this method; but the method reveals that the catering-vs-baggage sequencing is a decision point worth a deeper probe. It hands a clean skeleton to the cognitive methods that come next.

How it works¶

Decompose into observable steps. Break the work into its sub-tasks and sequence, capturing what is done, in what order, and in parallel where relevant — the visible structure, not the reasoning.
Map actors, tools, and hand-offs. Record who performs each step, what they use, and where control passes between people or systems, since the seams are where coordination and constraints bite.
Note the constraints. Capture the hard rules, dependencies, and limits the work operates under — the boundaries any judgment must respect.
Produce an explicit skeleton. Render the result as a task hierarchy, flow, or swimlane — a shareable representation of the process that later, deeper elicitation can annotate.

Tuning parameters¶

Decomposition depth — how finely to break the task down. Finer decomposition exposes more potential decision points but risks drowning the structure in trivial detail; stop where the steps stop being judgment-relevant.
Breadth of scope — one narrow procedure or an end-to-end process. Wide scope shows coordination and hand-off structure; narrow scope details one segment thoroughly.
Source mix — documents and SOPs, direct observation, or practitioner walkthrough. Documents give the official process; observation gives the real one, including undocumented steps and workarounds.
Representation form — hierarchy, flowchart, or swimlane. Each foregrounds something different (nesting, sequence, or ownership); pick the view that makes the coming decision points legible.

When it helps, and when it misleads¶

Its strength is being the fast, cheap orienting map: it makes the whole process visible, exposes where the cognition-heavy decision points and hand-offs are, and gives every deeper elicitation method a shared skeleton to build on.^[1] For coordination-heavy or unfamiliar work, it is the sensible first move.

Its central risk is being mistaken for the whole story. Task Analysis captures the visible structure and none of the tacit judgment, so a team that stops here has an org-chart of the work with the expertise removed — and worse, the explicit steps can look so complete that no one thinks to ask what the veterans actually decide. Documented-only task analyses compound this by capturing the official process while missing the real one, with its workarounds and informal sequencing. The classic misuse is to hand the resulting map to a novice as if following the steps equals doing the job — which is precisely the failure that motivates going deeper. The discipline that keeps it honest is to treat the analysis as a scaffold, explicitly incomplete, ground it in observation rather than only documents, and flag the decision points it exposes as targets for a cognitive method rather than as solved.

How it implements the components¶

Task Analysis fills the two components a surface-structure map produces:

expert_practice_observation — documents the observable steps, actors, tools, and constraints of the real work (especially when grounded in watching, not just reading the SOP).
provisional_articulation — renders that structure as an explicit, shareable skeleton (hierarchy, flow, or swimlane) — a provisional map of what happens, onto which the how-they-decide is later added.

It deliberately stops at the visible surface: it does not capture the cues, strategies, or reasoning inside the steps (cue_elicitation, decision_rationale_probe — Cognitive Task Analysis), and it does not test or validate the mapped work (replication_probe, contextual_validation — Simulation Replay).

Instantiates: Tacit Knowledge Elicitation — Task Analysis supplies the explicit work skeleton that orients and scaffolds the archetype's deeper elicitation.
Sibling mechanisms: Cognitive Task Analysis · Shadowing Session · Think-Aloud Protocol · Apprenticeship Observation · Cognitive Interview · Critical Incident Technique · Decision Trace Review · Expert Debrief · Simulation Replay · Case Library Capture · Judgment Aid

Notes¶

Task Analysis is the shallow, structural complement to Cognitive Task Analysis, and the two are frequently run in sequence: map the visible work first, then use that skeleton to locate and probe the hidden judgment inside it. Their names invite confusion — Task Analysis maps what is done; Cognitive Task Analysis maps how it is decided — and treating them as interchangeable is the single most common error, because it lets a project claim it "analyzed the task" while capturing none of the expertise.

References¶

[1] Decomposing work into a nested hierarchy of goals, sub-tasks, and operations is the core of hierarchical task analysis (Annett & Duncan, 1967), a foundational human-factors method. Its focus on observable task structure — rather than the operator's cognition — is exactly why it serves here as a scaffold for, not a substitute for, cognitive elicitation. ↩