The same hierarchical breakdown can serve training materials and interface design

What it is

One goal-decomposed task tree can be used by a training author and by an interface designer, but they take different annotations. Dual use of hierarchical task analysis means a shared skeleton of goals and subgoals, with the training side marked for competence criteria, typical errors, and judgments that must be taught, and the interface side marked for information that must be seen or entered, feedback, and constraints. Handing both parties an uncommented tree yields “we have an analysis we cannot use.”

Why it happens

Training asks how a person acquires and keeps the ability to do the task right, including when not to act and how to recover. The interface asks what information and action channels the system supplies while that ability is present or being acquired. The same goal node therefore splits into two requirement lists. Written only for training, designers receive verbal commands and no state needs; written only for the interface, instructors receive field lists and none of the judgments that must be said out loud. The skeleton can be shared because the goal structure is relatively stable; the annotations cannot, because the two decisions are not the same sentence.

Studying it

Derive two views from one tree, with separate fields. Training view: satisfactory performance at the leaf, typical slips, judgments that need demonstration, prerequisite skills. Interface view: information needs, available actions, feedback, error states, dependencies on other goals. Ask a trainer and a designer each to draft one page from only their view, then compare: which nodes are critical in one view and blank in the other. Fill those blanks with annotation rather than drawing an unrelated second tree.

Where it stops holding

Some analyses serve one purpose from the start and need not be double-written. If the two uses have different stopping rules, the shared skeleton will fork at some level; mark the fork rather than pretend it is still one document. Treating the step order in a training manual as the interface flow is smuggling one annotation into the other.

Applying it

• Annotate the tree in two columns and hand out by column; do not issue a “generic” version for both sides to guess from.
• In design review ask “what information completes this goal on the interface”; in training review ask “what judgment counts as competence for this goal.”
• When the product changes, update goals on the shared skeleton first, then each column, so the interface draft does not move while training still teaches the old judgment.
• If one column stays empty, admit that use was not analyzed, and either fill it or narrow the claim.

Related

• Same group: Q4.13.1 Decomposition needs a stopping rule; deeper is not automatically better · Q4.13.2 Mark sequential, parallel, and conditional relations among subtasks · Q4.13.4 Uneven granularity makes complexity incomparable across tasks
• Adjacent: Q4.07 Task analysis · Q4.06 Scenarios and storyboards
• Search terms: dual-use HTA · training needs analysis · information requirements