Long processing needs a progress cue so people do not resubmit

What it is

If submit then waits more than a second (upload, risk checks, minting a number), a blank wait is read as dead. A progress cue shows that this submit is still running: an indeterminate activity state, or segments with a remaining estimate. Its job is to block the “press again” judgment, not to say success. Disabling the button is a lock at the control. This is the process layer before success or failure is revealed. The confirmation sentence after, the next actions, and partial failure are the other three steps.

Why it happens

After about a second with no new evidence, people recode “in progress” as “never started.” The longer the blank, the stronger the urge to resubmit, especially on uploads where no bytes are seen to move. Progress recodes waiting as work. A second layer: indeterminate and estimable are different. When duration is unknown, activity plus “processing your submit; do not close” is enough. When there are segments (upload → validate → number), stage names let people judge whether it is stuck. A fake bar that sits at 99% spends patience on the last cell, then triggers refresh—and refresh during unfinished processing can become a second submit. The cue must bind to real stages, not a uniform animation pretending to know the end.

Studying it

Set processing to 2 s, 8 s, 30 s. Compare no cue, a spinner, a fake bar, and real stage names. Watch resubmit, refresh, close.

Independent variables: processing duration, cue type (none / activity / fake bar / stage names), whether the control is also disabled. Dependent variables: resubmit or refresh while waiting, close rate, treating a stuck fake bar as failure.

Lab participants told to wait suppress resubmit. Change the instruction to “do what you would normally do if it seems stuck.” Button disabled is not a substitute for progress—people still refresh the page.

Where it stops holding

Submits under a second make progress a flicker of noise; the button’s waiting state is enough. Processing that becomes minutes (human review) should become “accepted; we will notify you,” not a bar that never finishes. Payments in unknown state must not use progress to pretend a charge is still running; query instead. Offline, progress should read “will send when back online”; a spinner is a lie. Screen readers need a live region for stage changes, or progress exists only for sighted users.

Applying it

• For submits expected to take more than a second, show activity or real stages until the result, and write “do not close / refresh.”
• Use stage names when stages are real; otherwise indeterminate wait. Do not run a uniform bar to 99%.
• Keep the control disabled during the process. Refresh or back should say “still processing,” not send again.
• Verify by delaying the API to 8 seconds and watching for refresh or a second click. Run a fake bar stuck at 99% and count refreshes. With a reader, confirm stage changes are announced. Payment unknown state must not show fake “charging” progress.

Related

• Within the group: H1.16.1 Successful submit needs an explicit confirmation, not a silent redirect · H1.16.3 The result page must name the next actions that can be taken · H1.16.4 When some fields fail to submit, distinguish the success and failure scopes
• Adjacent: H1.07 Preventing duplicate submit · I2.02 Predictable progress · D1.08 Visual expression of loading and progress
• Search terms: processing · progress indicator · resubmit while waiting