A6.21.4Offload before commitment, not throughout the flowdesign

Interfaces should allow offloading before a critical action rather than requiring state to be held internally throughout

Aliases: offload-before-commit · cost of sustained retention

What it is

Many flows require users to keep something in mind for the entire duration, only using it at the very last step — a price seen on an earlier screen, an option picked several steps back, a goal set at the start of a task. Requiring that kind of sustained internal retention forces the user to keep paying a maintenance cost throughout the whole process, even though the information could just as easily be externalized at any point. A better approach is to bring that information back in front of the user right before the critical action happens, as a confirmation offload, rather than defaulting to the assumption that it should stay held in mind the whole time.

Why it happens

Keeping a piece of information in a readily usable state takes ongoing resources, and that investment competes with whatever new information shows up in later steps; the more steps and the longer the gap, the greater the risk that the content someone was supposed to be holding gets crowded out or decays. The usual result is that the user arrives at the final decision carrying an internal version that is already blurred or wrong. Re-presenting the key information right before the action turns "whether to keep remembering this" from a burden sustained across the whole flow into a one-time, low-cost check — the user no longer has to divide attention to maintain it at every intermediate step, only to re-confirm it at the moment it's actually needed.

Where it stops holding

This principle only applies when the information doesn't need to be actively used partway through the flow. If the user genuinely needs to keep comparing against it at each intermediate step to make a series of judgments (continually checking choices against a budget across several rounds, say), pushing it to a final reveal instead creates extra round trips — in that case the information should stay visible throughout rather than being hidden and offloaded only at the critical point. The deciding factor is whether the information is actually used mid-flow, not how important it is on its own.

Applying it

  • Identify information in the flow that the user needs to remember but only actually uses at the final step (a price, an earlier choice, the original goal), and re-present it in full via a summary or confirmation screen right before the critical action (submit, pay, confirm) — don't assume the user still remembers it from the start of the flow.
  • For information that genuinely needs repeated reference partway through, don't wait until the end to offload it — keep it persistently visible throughout the flow (a fixed bar, a side summary); the right offload point for this kind of information is "visible any time," not "shown once at the end."
  • How to check: walk through every step of the flow and flag information that appeared in an earlier step, was never shown again, and is implicitly required for the final decision — those are exactly the points that need a confirmation-offload added.

Related

  • Same group: A6.21.1 When information is known to be retrievable on demand, people invest less internal memory in it · A6.21.2 Cognitive offloading reduces memory burden but also reduces deep processing of the information · A6.21.3 The reliability and availability of the external memory tool itself determines whether an offloading strategy is safe
  • Nearby: A6.02 Working memory capacity · A9.16 Cognitive offloading and external representation
  • Search terms: offload before commit · confirmation summary · working memory retention cost

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/A6.21.4