Offer informative feedback

What it is

Informative feedback is more than showing that a click registered — it states which object the system received, what state it entered, what result followed, and what comes next. Feedback granularity should scale with the severity of the consequence, the length of the wait, and the risk of error, not use one template for every action.

Why it happens

Feedback exists to close the gap between an action and the user's judgement of whether it achieved what they intended: confirming the input was received, understanding why something changed, judging success, and deciding whether to keep waiting or correct course. An animation alone carries none of this — only text or structure can. There is also a timing constraint on this mechanism: feedback that arrives after the user's attention has already moved to the next task is functionally equivalent to no feedback, because the user is no longer in the judgement context that would make them look back and check. This is why "eventually shown" cannot substitute for "shown in time."

Where it stops holding

More informative does not mean more notifications. If every instance of a high-frequency action produces full feedback, users' response to that class of prompt drops with repeated exposure, and they become desensitised to that entire screen region — so a genuinely severe anomaly ends up buried under a pile of routine success messages in the same spot, a "cry wolf" failure. The workable split is: high-frequency, low-risk actions get lightweight peripheral feedback; detailed, potentially interruptive feedback is reserved for rare, high-risk, or irreversible cases. Feedback must also match the real state exactly — an optimistic message that later proves false does more damage to trust than no message at all — and sound, animation, and haptics need an off switch plus an equivalent channel for assistive technology.

Applying it

• Define four feedback layers for every action — receipt, processing, success/failure, and next step — and decide which layers are mandatory based on the action's risk level.
• Show the affected object, count, time, who else is affected, and an undo entry point for key results; show cause and an actionable fix for errors.
• Place feedback near where the action happened, no later than the point at which attention would shift away; keep focus order sensible for screen readers.
• Audit notification frequency against how the response rate to that class of prompt changes over time, to confirm critical errors are not being buried under frequent success messages.

Related

• Same group: B3.11.1 Strive for consistency · B3.11.2 Provide universal usability · B3.11.4 Design dialogs to yield closure · B3.11.5 Prevent errors · B3.11.6 Permit easy reversal of actions · B3.11.7 Keep users in control · B3.11.8 Reduce short-term memory load
• Nearby: B2.06 Feedback · B3.01 Visibility of System Status
• Search terms: informative feedback · operation result · feedback design