Sequential, parallel, and conditional relations among subtasks must be marked

What it is

A tree of subtask names is not yet a task analysis. How those subtasks compose the parent is given by plans in hierarchical task analysis: what comes first, what may run together, which step depends on which condition, where to jump on failure. Leave those relations unmarked and readers will assume a top-to-bottom line, reading waits that could be parallel, branches that could be skipped, and preconditions that must all be present as if they were sequential steps.

Why it happens

Completing a parent is not the sum of a bag of children. The same three subtasks, done in a fixed order, in any order, only when a condition holds, or watched simultaneously, impose different loads on working memory, different state the interface must supply, and different recovery paths. A linear list draws “wait for the other party, then submit” as just another step and hides the time dependency; it also draws “fill three fields in any order” as a forced 1-2-3 and invites a fake mandatory flow in the UI. Plans are the temporal and logical layer of the hierarchy; without them the tree describes blocks, not how the blocks interlock.

Studying it

Write a plan sentence under every parent that has children, using a small set of relation words: then, in any order, at the same time, if…then, iterate until. Check against observation or think-aloud whether actual performance contains waits, insertions, or abandonments the plan omitted. For each condition in a plan, record its visibility—how a person knows it is satisfied. Code plan errors (reversed order, premature parallelism, missed condition) separately from “omitted step.”

Where it stops holding

Some cognitive tasks have unstable internal order; writing a rigid plan will fake determinacy. Mark “order not fixed” or give common variants rather than omitting the plan. Highly flexible expert strategies may need several plans, not one “standard path.” An over-fine plan also slides into a flowchart and loses hierarchical task analysis’s goal-as-node structure.

Applying it

• Write a plan beside every non-leaf; do not paste subtask names alone.
• Check interface drafts against the plan: do conditions have visible state, do parallel steps block each other, is a forced order actually required?
• Teach “when you may proceed without waiting, when you must wait” from the plan, not only the step names.
• In walkthroughs, hunt conflicts between plan and actual performance; change the plan or the design, and do not scold the user for leaving the flow.

Related

• Same group: Q4.13.1 Decomposition needs a stopping rule; deeper is not automatically better · Q4.13.3 The same hierarchy can serve training materials and interface design · Q4.13.4 Uneven granularity makes complexity incomparable across tasks
• Adjacent: Q4.07 Task analysis · Q4.04 User journey maps
• Search terms: HTA plans · sequential parallel conditional · task dependencies