Feedback

Physical objects came with their answers built in. Flip a light switch and the click arrives with the light. Turn a door handle and your fingers feel it catch. Nobody had to be taught whether the thing had registered, because the object said so in the same motion.

A button on a screen has none of that. No sound, no resistance, no weight. Unless a designer deliberately builds a response, pressing it looks identical to not pressing it. The most common accident of the early web came straight out of this gap: someone clicks a payment button, the page doesn't change, they click again, and the charge goes through twice — the first click had been working the whole time, silently.

The same scene still plays daily in gentler forms. Someone saves a document, sees nothing, and saves again. Someone uploads a file and waits three minutes without knowing whether it's climbing or already dead. Someone submits an application form, gets no confirmation, and calls the next morning to ask. In all three the action finished; it's the news of it that never reached the person. The cost lands as duplicate records, abandoned tasks, and support conversations that exist only because the screen stayed quiet.

After acting, a person wants to know four things, and they want them in this order.

1. Did it register? This one has to be answered before the finger lifts. The button briefly changing shape — a shift in UI state, the set of appearances one element takes in different situations — carries this job. Mockups that draw only the resting state drop this step entirely, which leaves it to whoever writes the code.
2. Is it running? Needed whenever the result won't be instant. A spinner, a progress bar, or a skeleton UI that sketches the shape of the content in grey before the content arrives all express this loading state.
3. Did it finish? Say what happened. Sometimes a toast that appears and fades on its own is enough; sometimes the result has to stay on screen where the person can come back to it.
4. Why did it fail? When something goes wrong, the fact of failure isn't enough on its own. What broke and what to do about it belong in the same place. Say only that the upload failed and the person sends the same file again; say that it exceeded the 20 MB limit and they come back with a smaller one.

There's one timing rule worth knowing. The Doherty threshold says that a response arriving within 0.4 seconds keeps a person's train of thought intact. Anything likely to run longer needs step 2, and anything past ten seconds needs a sense of how much is left, not just motion.

Match the loudness of the response to how reversible the action is. Autosave, which nobody needs to undo, can say so in small grey text in a corner. Permanently deleting a document asks once more in the middle of the screen. Swap the two and trivial actions grow confirmation dialogs while the dangerous ones slip by in silence. Frequent dialogs also train people to click through without reading, and that habit shows up again at exactly the wrong moment.

Within interaction design, feedback owns a specific stretch of time. Affordance and signifiers work before the click, suggesting that a thing can be pressed at all; feedback works after it, confirming that it was. Without the first pair people never try. Without feedback they try and then stand there wondering.

In practice the places it attaches cluster into four kinds: instant controls like buttons and toggles, form validation that reacts as a field loses focus, slow operations like uploads and saves, and irreversible actions like deletion and payment. The further down that list, the larger and longer-lived the response should be, because the further down that list, the worse it is to be wrong about what happened. Flipping a toggle is finished when the color changes; pressing a payment button leaves a sentence on the screen and a receipt behind it.

The short responses on small controls get their own name — micro-interactions. The heart that swells slightly when you tap it, over about two tenths of a second, looks decorative, but the work it does is reporting that the tap landed.

"Saving works, there's just no sign that it saved. People assume it failed and click again."

The behavior is correct; the news of it isn't reaching the user.

"Don't use a toast here — leave it on the screen. It'll be gone before anyone reads it."

A notice that disappears after a few seconds isn't enough for a result the user may need to check again.

"This goes past 0.4 seconds, so let's put a loading indicator on it."

The response is slow enough that the person needs a signal that something is still running.

Pagedeck's document save button is where this comes up most. Noa handed over a mockup with only the resting state drawn, so Theo made his own calls about what to show right after the click, during the save, and on failure. The result was one product where some screens raised a toast after saving and others showed nothing at all.

Now all four states ship in the mockup together, and the handoff notes say when the in-progress indicator appears. The number of drawings went up; the number of items bouncing back from design QA went down.

The most common mistake is treating feedback as a synonym for notifications. Toasts are the most visible form it takes, so the two collapse into one idea easily. But a notification is the product speaking first, while feedback is the product answering something the user said. Lose that distinction and you end up with a product that stays silent about what the user did while interrupting constantly about what the user didn't. The save button says nothing, and a bubble introducing a new feature appears every third day.

The other mistake is assuming more is better. Some response beats no response, so every action gets a marker. But once ten things are competing on screen, people ignore all ten. In an interface that announces a save every time a character is deleted, the failed-payment message appears in the same corner in the same shape and gets skipped with everything else. Answer quietly for things the user already expects, and save the room for the things they don't know and the things that went wrong. Volume is a budget, and spending it on routine successes means having none left when a charge actually fails.