L4.14.4plan abstraction must match judgementdesignresearch

The plan's abstraction level must match the user's capacity to judge; a too-fine plan cannot be reviewed

Aliases: reviewable plan · not a pre-run log · object-act nodes

What it is

A plan is for a person to review, so grain must stop at the layer where they can judge “should this step be done”: what to which object, whether outward. Listing every internal function, every retrieval, every format conversion as a node degrades review into nodding. Plan abstraction must match judgement: too fine and too coarse both fail review — too fine cannot be finished, too coarse cannot see outward.

Forty lines of “call tool X” is not a plan. It is a log that has not run yet.

Why it happens

Review is judgement on a clock. Working memory and reading speed cap the node count. Past the cap, people switch to a heuristic: looks about right, approve. Automation bias holds on the plan page too. Process-view density happens while it runs; plan density happens before it runs, and spends the pre-execution forward move. Editable also depends on reviewable: nodes too many to recognise, and deleting a step becomes a guess.

Outwardness, object, verb are the minimum fields judgement needs. Internal implementation detail is not.

Studying it

Hold the same task, compare three plans: object-act nodes (a handful to a dozen or so), full tool calls, one sentence of goal. Dependent variables: rate of taking off a wrong outward node, review time, whether people report “I had not finished reading.” Independent variables: node count, whether outward is marked, whether detail can be expanded.

Approving without finishing is grain failing. One sentence of goal makes the outward node invisible.

Where it stops holding

Expert debug needs expansion to call level; that is a secondary view, off by default. Mid-execution change notices at too-fine grain become a flush. The real path may be fine inside; what is shown for approval must be aggregated nodes; aggregation must not invent nodes that do not exist. A one-step task has no grain problem.

Applying it

  • Default plan node = one inward or outward world act + object. Internal retrieval and format conversion stay folded.
  • When node count passes the “still finishable” cap you have measured, force grouping rather than appending more rows.
  • Check: hide a wrong outward act inside the twentieth internal call. If it is almost never taken off, grain is still a log. Pull back to object-act and measure again — if it is then taken off, abstraction matches judgement. Ask “did you finish reading” — approved without finishing, and the cap still has to come down.

Related

  • Same group: L4.14.1 Showing the plan before execution moves correction cost from after to before · L4.14.2 The plan must be editable by the user, not only approved or rejected · L4.14.3 If the plan changes during execution, that change must be notified, or the prior approval no longer holds · L4.14.5 The plan the system shows must match the path it actually runs, or approval is empty
  • Nearby: L4.12 Task Progress and Intermediate-state Visibility · L5.05 The Moderation Principle of Transparency · L4.08 Visibility of Task Progress
  • Search terms: plan granularity · reviewability · abstraction

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L4.14.4