The gulf appears as not knowing whether the action succeeded
Aliases: success uncertainty · duplicate submission · unclear result · causal evidence
What it is
A common Gulf of Evaluation is "Did I submit? Did it save? Who received it? Did it fail?" Users cannot tell from the interface whether the action took effect, how far it progressed, or whether the result is reversible. This causes duplicate submission, pointless waiting, or wrongly continuing. This card follows directly from "the gulf is the distance between system state and user understanding": that card gave the gulf's general definition; this one focuses on the specific scenario where it occurs most often and with the most direct consequences — after a submission-type action, where the user has no causal evidence to rely on at all.
Why it happens
A user judges "did it succeed" not by trusting that the system genuinely finished processing internally, but by the causal evidence the interface provides — some perceivable change that follows an action, which becomes, in the user's mind, proof that "my action actually took effect." The problem is that the real system state after submission often spans a request queue, server-side processing, cache synchronization, and a notification layer, and these layers do not finish at the same moment. If the interface's only feedback is "the dialog disappeared" or "the button spun and then stopped," that feedback establishes no reliable causal link to what is actually happening behind it — the dialog disappearing might only mean the front end received the request, not that back-end processing actually finished, yet the user will treat it as proof of completion. Optimistic updates, asynchronous approval, partial success, and delays from external systems further mean that "success" is no longer a single state but needs to be broken into stages such as received, processed, published, and synchronized; if the interface's status vocabulary does not distinguish these stages, the information a user gets stays permanently ambiguous, and they will instinctively act on the worst-case assumption — resubmitting, because the cost of a duplicate (a possible duplicate record) looks smaller to them than the cost of doing nothing when it actually did not go through.
Where it stops holding
Do not display a fake "success" just because the state is still uncertain. If a request genuinely has not been confirmed yet, the honest move is to show a status that clearly expresses that uncertainty — "sent, awaiting confirmation" — with an entry the user can revisit at any time, rather than showing a result that has not actually happened yet just to put the user at ease; once a prematurely displayed "success" gets overturned later, the trust damage is worse than honestly showing "processing" the whole time. Partial completion needs separate handling too: in a batch operation where some objects succeed, some fail, and some get skipped, the interface must list all three categories separately rather than reporting a blanket "done," which would permanently erase the failed and skipped items from the user's awareness. Conversely, a low-risk, near-instantaneous operation does not need a large, prominent confirmation screen repeatedly asserting "it worked" — but even without a prominent notice, the trace the action leaves must still be reviewable afterward; a small action is not an excuse to leave no status record at all.
Applying it
- For high-frequency actions like submit, save, send, and sync, define a clear result-state vocabulary and a corresponding timestamp for each, and do not let words like "done," "success," and "processed" get used interchangeably to mean different things.
- Include the specific object, count, recipient, or target location in a completion message, along with an entry the user can click into for detail, rather than a bare "action successful."
- Let asynchronous tasks be checked again after the user leaves and returns; on failure, give a specific reason and a retry entry.
- How to check: specifically test weak-network conditions and the "leave right after submitting, then come back" interruption scenario, and check whether the user can accurately judge, upon returning, whether their action actually took effect and whether they need to resubmit — if a user resubmits in this test, the current status feedback failed to provide sufficient causal evidence.