Receipt feedback should appear faster and be simpler than result feedback
Aliases: input acknowledgement · immediate feedback · lightweight feedback · result feedback
What it is
Fast acknowledgement feedback tells people by the shortest path that an input entered the system; it should arrive earlier and contain less information than final result feedback. A pressed state, temporarily locked control, nearby submitting mark, or queue entry can acknowledge receipt. The final result should carry success/failure, artifact location, actual impact, and next action. The distinction is not visual importance but timing: acknowledgement prevents retry, while result enables verification and onward decision.
Why it happens
Receipt can depend on local events or near-system state and need not wait for network, computation, or an outside service, making it suitable for fast local presentation. If it carries a full result explanation, long copy, confirmation dialog, or strong animation, it delays the causal evidence people need and can suggest that the flow ended. Result feedback needs more information precisely because it explains actual impact, verifiable output, or recovery. Separating complexity over time lowers initial attention cost without promising uncertain content too early.
Studying it
Log end-to-end time from input to acknowledgement and acknowledgement to outcome, then measure repeated action, stage judgment, and feedback recall under network, queue, and failure conditions. Comparing a single detailed success notice with immediate lightweight acknowledgement plus a later result should assess whether people stop retrying sooner and still find critical detail on completion. Do not assess animation delay alone: early information overload may make people pause to read, dismiss a notice, or mistake completion.
Where it stops holding
Lightweight does not mean vague. Receipt must identify the operation and cannot be an unsemantic spinner. For consequential input, fast feedback may include a needed safety state, such as “submitting, not yet charged,” but must not impersonate final transaction outcome. When an operation truly completes synchronously, merged feedback can be simpler if object change is explicit rather than merely omitting an intermediate state.
Applying it
- Separate asynchronous feedback into a quick, action-local receipt layer and a verifiable result layer with details and recovery.
- Keep receipt copy and visual weight restrained; avoid modal dialogs, long text, and attention-grabbing motion that interrupt continuous input.
- Pair concurrent operations correctly through request identity or object state so a later outcome cannot overwrite an earlier acknowledgement.
- Test slow networks and consecutive submissions: people should stop retrying immediately, distinguish pending from complete, and know when details become available.