Feedback Loops

A user clicks a button. Nothing happens visually. Did it work? Did they click in the wrong place? Is the system slow? Without feedback, there is no way to know — and the user clicks again.

What feedback is

Feedback is any signal the system returns to confirm that an input was received and to communicate the result. It closes the action loop: the user acts, the system acknowledges. Without feedback, interaction is a one-way broadcast into silence. Good feedback is immediate, specific, and appropriately matched to the weight of the action.

The four types

Acknowledgement confirms that input was received — the button depresses on click, the field highlights on focus. Status communicates what the system is doing — a loading indicator during a network request. Outcome communicates the result — a success message, an error, a changed state. Consequence communicates downstream effects — “your changes will affect 14 records.” Not every interaction requires all four, but every interaction requires at least acknowledgement and outcome.

Immediacy

Feedback must be immediate. Users expect a response within 100ms of input — at that latency, the response feels instantaneous. At 1 second, users notice the delay. Beyond 10 seconds without feedback, users assume the system has failed and take corrective action — often re-submitting, refreshing, or abandoning. Loading and progress states are feedback for slow operations; they do not replace immediate acknowledgement.

Feedback proximity

Feedback should appear close to the element it relates to. An error message at the top of the page that relates to a field at the bottom violates proximity — the connection is unclear and the user must search for the relevant field. Error messages belong adjacent to the fields they describe. Success confirmations belong where the action was taken.

The mistake

Treating feedback as an afterthought — designing the “happy path” in full detail and leaving error states, loading states, and empty states until the end of the project. These states are not edge cases — they are the majority of what users experience on any given interaction. Design them with the same care as the default state.

Voice feedback

Voice interaction — including voice commands and accessibility tools such as VoiceOver, TalkBack, and Dragon NaturallySpeaking — introduces feedback requirements that differ from pointer-based interaction. When a user speaks a command, the system must confirm what it heard before confirming what it did. The two-stage feedback (“I heard: delete file / File deleted”) is necessary because voice introduces a transcription layer that can fail.

Practical requirements: spoken confirmation before destructive actions; clear error recovery that states what was misunderstood and what the alternatives are; visual feedback that mirrors audio feedback for mixed voice/visual contexts; and explicitly named interactive elements. Voice control users navigate by saying element labels — “Click Save”, “Click Submit”. Unlabelled icons and generic labels (“Button”, “Button 2”) are inaccessible by voice.

Haptic feedback

Haptic feedback communicates through vibration on mobile and wearable devices — a feedback modality alongside, not instead of, visual and audio feedback. Users relying on haptics should receive the same information other users receive through visual or audio channels.

Established patterns:

• Light impact — confirmations, selection changes, small completions
• Medium impact — mode changes, significant actions
• Heavy impact — errors, destructive confirmations
• Custom patterns — repeated taps for notifications; avoid mimicking system-level patterns (notification buzz) to prevent confusion

On the web, the Vibration API (navigator.vibrate()) provides basic haptic access on Android. iOS restricts haptic access to native apps. Design haptic feedback as progressive enhancement — the interaction must be fully functional and communicative without it.

The takeaway

For every interactive element, design all feedback states before shipping: default, hover, active (pressed), focused, loading, success, error, and disabled. These states are not extras — they are the complete interaction.