The Feedback Loop That Actually Worked
Making feedback an interactive and critical component of the diagnostic process.
Alex is in the middle of a routine task when it happens. Not an epiphany — a small, specific thing. The step that used to require four form fields now requires one. Alex completes the task and then pauses, trying to remember when the change appeared, because it was not announced and it was not the subject of a release note and Alex only notices it now because the friction that used to be there is gone.
Somewhere in the background of that pause is a support call from eighteen months ago. Alex had reported exactly this — the unnecessary duplication in the form, the way the same information was asked for in three different places. It had taken fifteen minutes longer than it should have. Alex had said so. The call had ended with an apology and a reference number.
And now the form was different.
What usually happens to feedback
The standard experience of providing feedback to a technology product is an exercise in patience with diminishing returns. The survey that arrives after every interaction, rated one to five, with a final optional text box that almost no one fills in because nothing has ever clearly happened as a result of it. The support ticket that generates an automated acknowledgement, a reference number, and silence. The complaint that is logged, managed, and resolved — which means it is closed, not that the thing that caused it has been changed.
None of these are careless. They are systems doing what they were designed to do. The survey tracks satisfaction, the ticket resolves the case, the complaints process manages liability. None of them were designed to change the product. That distinction matters more than it sounds, because a system designed for one purpose will not accidentally perform another, however good its data.
The difference in Alex’s case was not that the organisation cared more. It was that the system had been designed for a different purpose: to move information from the person experiencing the product to the people building it, and to do something with what arrived.
The three conditions that make a loop
A genuine feedback loop breaks the moment any one of three conditions is missing.
Feedback that works has to be easy to give — not a survey sent after the fact, not a formal process initiated at a separate URL, but a mechanism present at the moment the friction is felt. Alex did not fill in a survey. Alex called to report something broken, while it was broken, with the specific detail of what had gone wrong. The signal was clean because it was immediate and unsolicited — the kind of feedback that surfaces the actual experience rather than a retrospective reconstruction of it.
Getting that signal to the people who can act on it is harder than it sounds. In most organisations, the path is long and obstructed: feedback arrives at customer service, which resolves individual cases and closes tickets, while patterns that would be visible to the product team — if they received the same data — never reach them. Alex’s organisation had a short path: a shared channel between support and engineering, a standing item in the sprint review for user-reported friction, a team that treated incoming complaints as product development input rather than cases to be managed. The information arrived with its context intact and at the people who could do something about it.
Visibility is what closes the loop. Not announced, not marketed — just present. The next time Alex used the service, the thing that had been difficult was different. Without that, the person who provided the feedback has no reason to believe the loop exists and no reason to provide the next signal honestly. A feedback system that receives, processes, and acts — but never demonstrates that it has done so — produces exactly the same user behaviour over time as one that does none of those things. Trust requires evidence, not intention.
All three conditions were present in Alex’s case. Remove any one and the loop would have broken.
What two years of listening produces
Over two years, the service Alex uses has changed in small, specific ways that trace directly back to what people who used it said.
The file upload failure message used to say “Error: upload rejected.” Alex had reported this after twenty minutes trying to diagnose which of five files was causing the problem. The message now says which file failed, why it failed, and what the accepted formats and size limits are. The change took a morning to implement. The information needed to make it had been sitting in the support queue for eight months.
The address entry flow used to require four separate fields in an order that did not match the way most people read their own address. The most common support call in one quarter was people unsure which field their flat number belonged in. The form now uses postcode lookup. Completion time for that step fell by two-thirds.
A third change is smaller and easy to miss. The notification sent when a request was submitted used to say “Your request has been received.” Alex had written, in a feedback form, asking whether anyone actually looked at these requests — because the notification contained no information about what would happen next, or when, or who to contact in the meantime. The notification now includes an expected response time and a named contact for queries. It took one line of copy and the answer to a question that no one on the product team had thought to ask, because no one on the product team had ever waited on the other side of the process they had built.
The cumulative effect is a service that feels attended to. Not perfect — attended to. That quality is not cosmetic. It is the specific evidence that someone received what was said and acted on it, and it is the foundation of whatever trust Alex now places in the service.
What the design is actually for
Think of a digital service you use regularly. Can you point to a specific change that service has made in the past year that you believe was a response to real user experience? If you cannot — what does that tell you about whether the feedback loop exists?
If you build or manage a technology product, how does feedback from real users reach the people who can act on it? Is the path direct and short, or does it pass through layers that filter, aggregate, and delay?
If you have ever provided feedback to a technology product — a support call, a complaint, a survey response — were you ever aware of a change that resulted from it? How did that experience affect your relationship with the product and the organisation?
Continuous improvement is standard practice in manufacturing and in software development. Why is continuous listening — treating user feedback as an ongoing product development input rather than a post-launch compliance exercise — still the exception in most technology organisations?
Most feedback systems are designed to manage the organisation’s relationship with feedback rather than to let feedback drive the product. The organisations that reverse that design — that make the path from user experience to product change as short and unobstructed as possible — build technology that improves in the direction that matters. Alex noticed. That noticing is rarer than it should be.
Authors Note
Alex is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.