State the specific object and irreversibility scope

What it is

Consequence scope in confirmation copy names the object, quantity, and related scope an action will affect before commitment, distinguishing permanent consequences from genuine recovery paths. “Delete these items?” cannot verify a namesake, changing selection, or spillover. “Move 12 files to Trash; they can be restored for 30 days” identifies action, count, scope, and recovery condition. Confirmation should not portray every consequence as irreversible; it should make the user's decision and the system's pending result refer to the same thing.

Why it happens

At confirmation, people may still reason from an earlier selection, an obscured background, or their customary meaning of “delete.” Name, type, and count identify the target; effects on descendants, collaborators, subscriptions, or automation establish scope; recovery location, window, and permission establish reversibility. A static sentence creates false certainty when selection changes in the background, authorization changes, or count is only estimated. Copy therefore depends on authoritative execution-time state. If a consequential action's scope cannot be established, commitment stops; uncertainty may be exposed and execution continue only when a safe upper bound supports the decision.

Studying it

Construct tasks with single and same-named objects, bulk selection, linked resources, collaboration, and state change. Before execution, ask participants to restate object, quantity, spillover, and recovery; then observe cancellation, continuation, regret, and recovery. Compare their account with the actual transaction and record scope errors, failed recovery, and completion time. Include narrow screens, zoom, keyboard, and screen readers. A lower confirmation rate alone is not proof of safety: accurate scope may also speed a correct commitment.

Where it stops holding

Low-consequence, frequent, readily reversible actions should not gain a modal confirmation merely to repeat context; undo or result feedback may be better. Bulk objects need not all be listed when an accurate count, representative names, and an expandable manifest suffice. An unstable count must not masquerade as exact. Security or privacy may prevent disclosure of the full name, but copy can still state a safe type, scope, and recovery outcome. Promise recovery only when the window, route, authorization, and technical capability actually exist.

Applying it

• Model object, action, count, scope, spillover, recoverability, recovery window, and authoritative state for each confirmed action; render the body from the latest pre-execution state.
• State the core target and quantity directly, placing effects on linked objects or other people in a separate sentence. Say when an action cannot be undone; for recoverable actions, name location, window, and limits.
• When the confirmation layer opens, make its visible heading and body and its programmatic name and description convey the same target and consequence. Update accessible description when dynamic scope changes and require renewed confirmation for a material change.
• Revalidate version and scope at execution. If state has drifted, do not enlarge the action previously authorized; stop, refresh the scope, and ask for a new decision while preserving work where safe.

Related

• Same group: T2.06.2 Buttons must restate the action, not say OK · T2.06.3 Warning intensity must match actual consequence
• Adjacent: T1.03.3 High-stakes situations favor completeness over brevity · T2.04.1 Say what happened, why, and what to do
• Search terms: confirmation scope · irreversibility disclosure · destructive action confirmation