Asynchronous states
Loading, retry and uncertain saves: test the waiting experience
UxerProof Editorial · · 3 min read
The difficult part of a save operation is sometimes the interval between clicking the button and knowing what happened. A spinner can show activity without explaining whether the work is saved, still pending or uncertain.
That uncertainty matters because the next click may repeat an operation or abandon work that already completed. Test the waiting experience as part of the task, not as a decorative loading state.
Distinguish the possible outcomes
An operation may still be processing, may have failed before completion or may have completed without the browser receiving confirmation. These are different states. The interface should not present all of them as “Try again.”
In an illustrative draft-saving flow, define the expected feedback and a way to inspect the saved result. Use a controlled environment to simulate delays or failures. Do not repeatedly trigger real purchases, invitations or approvals to see what happens.
Inspect the person's next decision
While the operation is pending, check what the interface allows and explains. Can the person leave? Is cancel supported? Does the button indicate that work is already in progress? Does the screen preserve enough context to understand the operation?
Avoid requiring a particular visual pattern for every product. A short action and a long-running export may need different feedback. What matters is whether the person can make the next decision without inventing an explanation for the system's state.
Test retry against the actual result
After a controlled failure, inspect the underlying task outcome through an authorized route. If the draft exists, the interface should not falsely imply that nothing was saved. If it does not exist, the recovery path should make the next attempt understandable.
Where repeat actions are possible, check for duplicate results in the safe test environment. A UX walkthrough can reveal duplicate creation, but technical guarantees about request handling need implementation-level tests too.
Record both the feedback and the persisted result. Either one alone can produce a misleading account of success.
Make status changes available to the intended users
Progress and completion messages need evaluation beyond their visual appearance. W3C's Status Messages guidance explains how relevant updates can be made available to assistive technologies without necessarily moving focus. Apply the appropriate techniques to the specific interface and verify them. W3C Status Messages guidance.
Report uncertainty honestly
If the test cannot establish whether an operation completed, record an uncertain outcome and the missing evidence. Do not convert a timeout into either a confirmed product failure or a successful save by assumption.
The final check is whether the person can tell what happened and continue safely. A faster animation is not a repair if the operation's actual state remains ambiguous.
Next step: Use before-and-after UX validation to compare feedback changes while preserving the same operation and success criteria.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.