
Feedback
Every action asks a silent question, did that work? Here is how good systems answer it, and what happens when they answer wrongly.
Feedback
A light that told half the truth
At four in the morning on 28 March 1979, the pumps feeding water to the steam generators of Unit 2 at the Three Mile Island nuclear plant, near Harrisburg in Pennsylvania, stopped. The reactor shut itself down, as designed. Pressure inside the reactor's cooling system rose, and a relief valve on top of the system, called the pilot-operated relief valve, opened to let some of it out. Seconds later, the control system sent the signal for the valve to close. The valve didn't close. It stuck open, and cooling water began to escape.
In the control room, a light on the panel went out. The operators read that as the valve closing. But the light didn't report the valve's position. It reported whether the valve's solenoid, the electrical part that tells it to move, was being powered. The light was telling the operators what the system had been instructed to do, not what had actually happened. For more than two hours, as water kept pouring out of a valve everyone believed was shut, the operators made decisions based on that answer. Some of them made things worse.

By many accounts, more than a hundred alarms sounded within the first few minutes, and the printer logging them fell far behind. A temperature reading that hinted at the stuck valve was behind a tall instrument panel, on a gauge the operators weren't trained to use. It took the arrival of the next shift, around six o'clock, for someone to notice the high temperatures downstream of the valve and close a backup valve. By then, about half the reactor core had melted. The containment held, and studies have found no clear long-term health effects, but it remains the most serious accident in the history of American commercial nuclear power.
The presidential commission that investigated, chaired by John Kemeny, reported in October 1979 that the control room "was greatly inadequate for managing an accident". Among its problems were poor alarms and no clear indication of the valve's position. In the post on signifiers, I wrote about cues that tell people what they can do. This post is about the other half of the conversation: how a system tells people what just happened.
From a ferry crossing to the steersman
The idea of feedback came from engineering long before it reached design. In August 1927, a young Bell Labs engineer called Harold Black was crossing the Hudson on the Lackawanna ferry when he worked out how feeding part of an amplifier's output back into its input could cancel distortion. He sketched it on a blank page of the New York Times he had with him. Negative feedback helped make long-distance telephone lines practical. In 1948, the mathematician Norbert Wiener published Cybernetics, a book about control and communication in animals and machines, and argued that feedback was how living things, not just circuits, steered themselves. He took his title from the Greek word for a steersman.
Don Norman brought the idea into everyday design. In The Design of Everyday Things, he describes feedback as communicating the results of an action, and he's specific about what good feedback needs. It must be immediate: he writes that even a delay of a tenth of a second can be disconcerting. It must be informative, telling people what happened and ideally what to do next, rather than a beep that could mean anything. And it must be in proportion. He also asks why people keep jabbing at a lift button, or at the button at a pedestrian crossing. Usually it's because nothing tells them the request was received.
A common misunderstanding is that feedback means a confirmation message at the end of a task. That's only one kind. Feedback is everything a system shows about its state as you act: a key that moves under your finger, a slider that follows your thumb, a progress bar, a field that turns red while you're still typing. The most important feedback is often continuous and so ordinary that we only notice it when it's missing.
Speaking into a quarter-second echo
Why does feedback matter so much? Because our bodies and minds run on it. In 1950, the engineer Bernard Lee found something strange while working with tape recorders. If people heard their own voices through headphones with a slight delay, their speech fell apart. In his published results, a delay of about a quarter of a second could make people slow right down or, if they kept their normal pace, stammer, repeating syllables as though they had a stutter. The effect, now called delayed auditory feedback, shows how tightly we depend on hearing ourselves in real time. Interestingly, later research found that some people who stutter speak more fluently with it, which shows how individual these loops can be.

A related finding concerns our sense of being in control. In 2002, Patrick Haggard and his colleagues at University College London asked people to press a key, which was followed a quarter of a second later by a tone, and to judge when each happened using a fast-moving clock hand. When people pressed the key by choice, they perceived the press as happening slightly later and the tone slightly earlier, as if the two were pulled together in time. When an involuntary twitch was caused by magnetic stimulation of the brain, that pull vanished and reversed. Researchers call this intentional binding, and many treat it as one marker of the feeling that we caused something.
I should be careful about how far this evidence goes. Delayed auditory feedback is a robust, often repeated effect. Intentional binding is well replicated in the lab, but what it means is still debated. What both suggest is that a quick, clear response to an action isn't decoration. It's part of how we feel that our actions are ours. A button that answers instantly feels like an extension of your hand. One that answers late, or not at all, feels like asking a stranger for a favour.
Three whistles for dal
In many Indian kitchens, the most famous piece of interaction design makes a sound you can hear through two walls. The pressure cooker's whistle is a weight sitting on a narrow vent in the lid. As the cooker heats, steam pressure builds until it's strong enough to lift the weight, and a jet of steam escapes with the shriek so many of us grew up with. The weight drops back, pressure builds again, and the cycle repeats. The idea goes back a long way. In 1679, the French physicist Denis Papin showed the Royal Society in London his "digester", a pressure vessel with a weighted valve to release excess steam, often described as the first safety valve.

As feedback, the whistle is remarkable. It's immediate and impossible to miss, it works while your back is turned and your hands are busy, and it needs no screen, no electricity and no literacy. It turns an invisible state, the pressure inside a sealed pot, into something the whole household can follow. It's also a lesson in what feedback actually measures. A whistle reports pressure, not doneness. Generations of cooks have turned it into a timer, "three whistles for dal", but the number of whistles depends on the flame, the quantity and the cooker, which is why many cooking guides suggest timing from the first whistle instead. People will always stretch feedback to answer the question they care about, so it pays to know which question your feedback really answers.
The cooker has a quieter layer of feedback too. If the vent gets blocked, a separate safety device is there to release pressure, a backstop for when the main signal fails.
Picture a school fee portal
Picture a school's fee payment page, opened on a phone by a parent paying ₹18,500 for the new term. They tap "Pay". For five long seconds nothing changes, while the page quietly contacts the payment gateway. Wondering whether the tap registered, the parent taps again. Two payment requests go out. Eventually a page appears with a transaction number and nothing else, no child's name, no term, no amount. The parent screenshots it, just in case, and calls the school office the next morning.
Every gap here is a feedback gap. Let's redesign it, moment by moment.

Within a tenth of a second of the tap, the button responds. It darkens, its label changes to "Paying ₹18,500" with a small spinner, and it becomes disabled so a second tap can't start a second payment. On phones that support it, a light vibration confirms the touch. If the gateway takes longer than a second or so, a line of status text appears below: "Waiting for your bank". If the parent is sent to a UPI app and back, the page remembers where they were and says so.
When the payment succeeds, the result page answers the questions the parent actually has. A large tick, then the amount, the child's name, class and term, the date and a line saying a receipt has been sent by SMS and email, with a button to download it. When the payment fails, the page says what happened to the money, whether it was deducted and when it will return, and offers one clear next step. None of this changes what the system does. It changes what the parent knows.
Backseat drivers and placebo buttons
Feedback can go wrong in the opposite direction. Norman warns that too much feedback can be even more annoying than too little, and compares chatty machines to backseat drivers, often right and impossible to listen to. His own dishwasher beeped at three in the morning to announce it had finished, defeating the point of running it at night. Three Mile Island showed the dangerous version: when a hundred alarms sound at once, each one means less, and people miss the one that matters.
Feedback can also lie. In 2004, the New York Times reported that most of New York City's pedestrian crossing buttons, more than 2,500 of roughly 3,250, no longer did anything, left in place after the signals were computerised. Progress bars that move at a steady pace regardless of the real work, or "Saved" messages shown before anything has saved, are the screen versions. They may calm people in the moment, but when the truth comes out, trust goes with it. The Three Mile Island light was worse than no light, because it looked like an answer.
And feedback has to reach the senses people actually use. A sound means nothing to someone who is Deaf, or to anyone with their phone on silent. A colour flash can be missed by someone with low vision or colour blindness. A status message that appears on screen but isn't announced is invisible to a screen reader user. Good systems say the important things in more than one way.
How I listen for silence
When I review a flow, I go through it action by action and ask three questions. What changes within a tenth of a second, so the person knows they were heard? What do they see while the system is working, if it takes longer than a moment? And what do they know afterwards, in their own terms rather than the system's? Anywhere the answer is "nothing", I've found a silence. I also check that the feedback reports what really happened, not what the system asked for, which is the Three Mile Island question, and I try every flow once with the sound off and once with a screen reader.
Here's an exercise for this week. Watch people at a lift, a ticket machine, an ATM or a card reader in a shop, and count how often someone presses something twice. Each repeat press is a small vote of no confidence in the feedback. Then pick one app you use and find the slowest action in it. What does it show you while you wait?
Feedback closes the loop after an action. In the next post, on mapping, I'll look at the relationship between controls and what they control, which decides whether people press the right thing in the first place. The Kemeny commission found problems of that kind at Three Mile Island too, with instruments and controls arranged in ways that made them hard to use.
Further reading: Don Norman, The Design of Everyday Things (revised edition, 2013) · John G. Kemeny and others, Report of the President's Commission on the Accident at Three Mile Island (1979) · Norbert Wiener, Cybernetics (1948) · Charles Perrow, Normal Accidents (1984)
The testAfter every action on your screen, does something change within a tenth of a second, and does it report what actually happened?