Design Principles
Norman: Feedback Loops
Every action should produce an immediate, clear response confirming it registered.
Where it comes from
It's one of Don Norman's core design principles from The Design of Everyday Things. Norman framed feedback as a basic requirement of any interaction: the system must communicate the results of an action, immediately and unmistakably.
Why it matters for your website
Every action needs a reaction. Norman's principle of feedback says a system should immediately and clearly confirm that an action registered and what it did. Without that loop, users repeat actions, doubt the result, or assume the product is broken. (This is the interaction-level sibling of NN/G's visibility-of-system-status heuristic.)
Feedback closes the loop a user opens with every action. Press, click, submit — each is a question (*did that work?*), and an interface that doesn't answer leaves the user to guess, usually pessimistically. A button that doesn't visibly respond gets pressed again; a save with no confirmation leaves doubt that lingers.
Good feedback is immediate and proportionate: instant for direct actions, informative about what happened, and matched in prominence to the importance of the event. The point isn't to narrate everything, but to make sure no action ever vanishes into silence.
Wrong vs right
A submit button that gives no response while the request processes, so the user can't tell it worked and clicks again.
An immediate state change — a spinner, then a clear confirmation — so the action is visibly acknowledged.
A toggle that changes a setting silently, with no confirmation the change took effect.
A visible response — the toggle animating, a brief 'saved' note — confirming the change registered.
An action that fails silently, leaving the user believing it succeeded when it didn't.
Clear feedback for both success and failure, so the user always knows the real outcome.
Understanding Norman: Feedback Loops
Norman's principle of feedback states that every action a user takes should produce an immediate, perceptible response confirming that it registered and conveying what it did. Feedback is the conversational half of interaction: the user acts, and the system must reply. Without a reply, the user is left interpreting silence, and silence is almost always read as failure.
This is the interaction-level sibling of Nielsen Norman Group's visibility-of-system-status heuristic — the same idea applied to individual actions rather than overall system state. A click, a submission, a toggle each open a small loop that feedback closes. When the loop stays open, users repeat actions, doubt outcomes, or conclude the product is broken.
The craft is in timing and proportion. Feedback should be instant for direct actions, should say what actually happened rather than merely that *something* did, and should be as prominent as the event deserves — quiet for the routine, unmissable for the consequential. It connects to visibility of system status, design for closure, and the gulf of evaluation.
How Kweri checks it
Kweri can detect some absent or weak feedback from the page — for instance interactive elements that appear to give no visible response, or actions without an obvious acknowledgement. But feedback often reveals itself only in motion and over time, which a static review can't fully exercise: what happens at the moment of a click, during a wait, or on failure. So Kweri flags where a response looks missing and prompts you to confirm each action produces clear feedback, while noting that fully verifying it means exercising the live interactions.
FAQ
What is feedback in design?
Feedback is the immediate, perceptible response a system gives when a user acts — confirming the action registered and showing what it did. It's one of Don Norman's core design principles, ensuring users are never left guessing whether something worked.
Why is feedback important?
Because every action is an implicit question — did that work? Without a clear response, users repeat actions, doubt the result, or assume the product is broken. Feedback answers the question and lets them move on with confidence.
What makes good feedback?
It's immediate, it conveys what actually happened (not just that something did), and its prominence matches the event — subtle for routine actions, unmissable for important ones. Both success and failure should be communicated clearly.
How is feedback related to visibility of system status?
Feedback is the interaction-level version of the same idea. Visibility of system status is about the system keeping users informed overall; feedback is about each individual action producing a clear, immediate response.
What happens without feedback?
Users fill the silence with assumptions, usually pessimistic ones — they click again, abandon the task, or distrust the interface. A silent action is often experienced as a broken one, even when it succeeded.
Related principles
Always tell users what's happening, with clear feedback delivered in good time.
Every sequence of actions must have a clearly defined end state that tells users the task is complete — open-ended sequences create anxiety and uncertainty.
Every interaction has two potential failure points: the gulf of execution (user can't figure out how to do what they want) and the gulf of evaluation (user can't tell whether what happened was what they intended).
Attribution & sources
Identified by Don Norman. Catalogued from The Design of Everyday Things (Don Norman).
One of Norman's core design principles; the interaction-level companion to visibility of system status. There's no single canonical web source.
See Norman: Feedback Loops on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →