Closure requires explicit start and end markers for a task, a concern the other rules do not cover

What it is

Closure requires that a task's boundary be recognizable: the user knows when a request was accepted, what stage processing has reached, when it is done, how it ends on failure, and how to resume after a pause. Consistency, feedback, and control can support closure, but none of them substitutes for defining the start and end states — which is exactly this rule's distinct place among the eight: consistency asks "is the same thing ever said two different ways," feedback asks "can the user see what happened," control asks "can the user intervene," but satisfying all three still does not necessarily answer "is this thing actually over." Closure is the only rule that watches the task boundary itself.

Why it happens

The other seven rules (consistency, feedback, universal usability, error prevention, reversibility, control, memory load) all describe how some property should be maintained inside the interaction process, and none of them presupposes the concept of "this is a bounded task" — consistency can operate continuously across a product's whole lifecycle, feedback can be given for any single isolated action, a sense of control can hold equally well in an open-ended monitoring scenario with no clear start or end. Closure is the only rule that treats "the task" itself as a unit that needs to be recognized, and it asks two questions none of the other seven ask: at what moment does this count as having started (the commitment point — which user action made the system formally accept the request), and at what moment does it count as finished. The start marker is easy to overlook because it often hides inside an unremarkable button click — but if a user is unsure whether their action was formally accepted by the system (the submit button was clicked but nothing visibly changed), they will click again and suspect failure, which is the same class of uncertainty as "not knowing whether it's done," just occurring at the other end of the task. Only with both markers in place can a user treat the interaction as a complete unit they can unload from their attention — something none of the other seven rules, however well executed, can provide on their own.

Where it stops holding

Not every task should be forced into a "complete loop." Ongoing monitoring, collaborative editing, and projects spanning weeks are inherently open-ended — the start may be clear but there is no natural endpoint — and the right move is not to fabricate a "wrapped up" end marker at the close of every session, but to provide milestones, a clear current owner, and an inspectable open state, honestly acknowledging that it is not over. Another boundary sits at the start: if the system's acceptance is not instantaneous (queued for manual review, say), showing an "accepted" start marker too early creates the same kind of trust gap later — the user plans subsequent actions on the assumption that processing has already begun, and if the review queue is long, that assumption was wrong from the start. The credibility requirement on a start marker is symmetric with the one on an end marker; honesty cannot be reserved for only the end.

Applying it

• Explicitly define, for each key task, the start condition, stage breakdown, completion evidence, failure state, cancellation path, and resume-after-pause behavior — all six exit states are required, and the start condition should separately verify that the system has genuinely accepted the request, rather than assuming a button click equals a start.
• Show the completion screen only once completion evidence is actually in hand, including a result summary, timestamp, affected object count, next step, and an undo/continue entry; for flows depending on asynchronous background confirmation, wait for the confirmation signal before displaying it, not before.
• Use one shared set of state names across roles and pages in a cross-role flow, and spell out what each role can see and do at the same state, so "done" does not mean different things to different roles.
• How to check: walk through interruption-and-return paths, and when a user re-enters a task they left earlier, ask them "what step are you at now, and what's left" — an answer they cannot give, or get wrong, means the current closure signal is missing, or appeared too early and too vaguely.

Related

• Same group: B3.17.1 The eight rules contain tensions; universal usability and expert accelerators pull against each other · B3.17.2 The rules support generative design self-checks, not an evaluation scoring sheet · B3.17.4 The rules are more abstract than specific criteria and must be translated into product-checkable clauses before use
• Nearby: B3.11 Golden Rules · H1 Interaction Patterns and Flows
• Search terms: task closure · completion state · process boundary · commitment point