Analyze the task, not the interface

What it is

Follow the screen: open the menu, hit submit, wait for the spinner. That describes an interface. It does not analyze a task. The object of analysis is the task: the change in the world the person is trying to make (money filed, patient matched, a file becoming the external version) and the activities and conditions that must hold for it. The interface is one current means. Means change, the task remains. Treat the means as the object, and the analysis dies when the screens change, and steps that never entered a screen stay invisible.

Why it happens

Interfaces come with copyable steps; tasks have to be inferred from goals, which costs more. Copying the screen writes “what the system demands” as “what the person is trying to do,” so captchas, consent clauses, and converting a file into some format become the task itself. The real task may already have succeeded or failed off-screen: the paper invoice was never photographed, a verbal yes was given without permission. An interface object also fakes completeness—every button is analyzed, the queue outside and the hunt for a signature are not on the tree.

Studying it

Write a task statement that names no widget (what in the world changes), observe a completion, and only then hang interface steps under the matching activities. Compare a page-by-page walkthrough with hanging steps on a task tree: the former yields clicks with no task meaning, the latter yields activities with no interface. Outcomes: share of nodes that still hold without the current UI, and count of fake tasks that exist only in the interface.

Where it stops holding

When the research question is the operability of a given interface (can this dialog be understood), the object should be the interface; do not inflate it into an abstract task. Safety-critical HMI sometimes must align controls and actions step for step; that is procedure analysis and should be labeled so it is not mixed with “the job of filing expenses.” When no new interface exists yet, only the task can be analyzed; that is the right object, not a defect.

Applying it

• Node names on the task tree may not contain buttons, menus, or page titles; those are footnotes on how an activity is currently implemented.
• If a step exists only to satisfy the system and does not change the outside world, mark it as interface-imposed and ask whether it can die; do not write it as a user goal.
• When designing a replacement, cover the old UI and ask whether the tree is still complete. Incomplete nodes are what the new UI—or a non-UI means—must take on.
• Acceptance: retell the task to a non-participant in sentences with no widget words. If they cannot hear what is to be accomplished, the analysis is still on the screen.

Related

• Same group: Q4.07.1 Hierarchical breakdown reveals subtasks and preconditions · Q4.07.3 Breaking down the current flow freezes it
• Adjacent: Q4.13 Task analysis and hierarchical decomposition · Q2.08 Cognitive walkthrough
• Search terms: task not interface as analysis object · device-independent task · hierarchical task analysis