The Singularity #188 by SingularityDot
Designers are taught early that good design comes from listening to users. Ask questions. Seek feedback. Test early, test often, and act on what you hear.
It's hard to disagree with any of that (and I generally don't). Understanding the people who use what we make is fundamental to building the right things in the right way. Feedback exposes blind spots, challenges assumptions and surfaces problems and opportunities a team might never discover on its own.
But the advice rarely comes with an equally strong reminder to think critically about what comes back. "Get feedback" is taught as a ritual, not a method. We're told to ask, but talk less about what to do next. That's where products can get hurt.
The problem isn't asking users for feedback. It's assuming every opinion, however common, deserves attention, every request deserves action, and more feedback automatically leads to better decisions.
(None of what you're about to read is an argument for listening less)
Feedback isn't inherently valuable.
Its value depends on who gives it, the circumstances in which it's collected, what you're trying to learn and, above all, your ability to interpret it. Without that context, feedback becomes a heavy distraction.
Bad feedback can pull a product in conflicting directions, dilute its purpose and eat more time than a team can afford. Worse, it can give people false confidence that they're making user-centred decisions simply because they're "listening to users".
The problem starts with a deceptively simple question.
The worst question of all.
"What do you think?"
Show someone something you've made and invite their opinion, and you'll get a mixture of preferences, criticisms, feature requests and suggestions. Some might reveal genuine problems. Others might reflect personal taste, misunderstandings or expectations that have little to do with the problem you're trying to solve.
None of that makes the feedback wrong.
But without knowing what you're trying to learn, it's difficult to judge what any of it means, which parts matter or what to do about them.
—
Say you're building an early-stage product to help freelancers manage their finances. You have a first version, something close to an MVP. You invite a handful of people to try it and ask "What do you think?".
It's rough. Problem-solution fit is loose and unproven. Usability has gaps. The brand barely exists. It's a sketch. It's a chalk outline on the ground. It's a building site.
But your testers don't experience a building site. They experience an app, and they judge it against the polished, more-mature apps they use every day, and the idealistic visions they have in their heads.
So the feedback comes in.
One person wants more detailed reporting. Another wants automated invoicing. Someone else asks for integration with their accounting software. A fourth thinks it should look more like their banking app.
All reasonable requests. All might reflect genuine needs. But what have you actually learned about whether the product solves the problem it was designed for?
Perhaps very little.
Feedback isn't insight
Users have experiences, knowledge and perspectives a product team can't replicate. They use the product in contexts you never considered. They build workarounds, misread labels, abandon tasks and find value in unexpected places. One of the most useful things feedback can do is revealing what you don't know you don't know.
But feedback and insight aren't the same thing.
Feedback is information. Insight comes from interpreting that information in context.
Someone says they want a dashboard with more information. Why? Are they struggling to find something important? Do they lack confidence in the decisions they're making? Are they trying to monitor something the product doesn't support
The dashboard is one interpretation of the problem. It might be a good one, but it's a hypothesis, not an instruction.
People are often better at describing their problems than prescribing the fix.
That's not to say users never have good ideas. They do. But solving a problem well is an expertise in its own right. Living with a problem doesn't automatically make you an expert in designing its solution. The reverse is also true: the person living with the problem usually understands it better than I do. My job as a designer is to understand their problem, not assume I already do.
To interpret feedback, you need something to hold it against.
I think of it as an anchor: what you know about your users' goals and needs, what's getting in their way, and the behaviours and expectations surrounding those problems. The specific problem you're solving, for specific people, is the yardstick. Product vision gives you direction, but it's often too broad to judge an individual observation against.
Without an anchor, every note can feel equally important or urgent.
Three ways feedback leads you astray
It answers a different question
The freelancer feedback isn't necessarily wrong. It may simply answer a different question from the one you need answered.
Your testers have different levels of financial knowledge, ways of working and expectations. Some are your intended audience; others aren't. Some are responding to the idea; others are reacting to the limitations of an unfinished prototype.
A note can be true and still irrelevant to the behaviours you're designing for. Feedback from the wrong people can be perfectly accurate about the wrong problems.
Vague questions make this worse.
"What do you think?" invites almost anything: preferences, assumptions, feature requests, aesthetic opinions and speculation. It hands the participant the job of deciding what's relevant.
Ask them to complete a task instead. Watch where they hesitate, what they misunderstand and how they approach the problem. Then ask why.
What people say matters. What they do often tells you something different.
Accommodating everyone dilutes the product
Now the team starts adding features to accommodate the requests. More reports, more integrations, more settings, more customisation. Each addition seems reasonable in isolation. After all, somebody asked for it.
Maybe even many people asked for it.
Over time, the product gets harder to understand. Its core purpose is buried under a growing pile of features. The team has stopped making deliberate decisions about the experience and started accumulating responses to individual requests.
A product can easily get worse by accommodating too many reasonable requests.
Users aren't responsible for the coherence of your product. They're describing their own experiences and needs, usually through the lens of what they already know. They can't see all the constraints and trade-offs behind the changes they suggest.
That's not a criticism, but it isn't their job to design your product.
This bites hardest early on. Before a product has found its direction, every new opinion can feel like a reason to change course. But early feedback is often a reaction to something incomplete.
Change direction when someone questions an unfinished idea and you risk losing sight of the problem before you've properly understood it. Chase parity with mature competitors and you can abandon your core proposition before it's had a chance to prove itself.
Being open to challenge is essential. Being directionless isn't.
Feedback creates work
Feedback is expensive, even when collecting it is cheap.
Someone has to recruit participants, run sessions, observe, document, find patterns, discuss implications and decide what to change. Then someone has to build those changes and check whether they helped.
It helps to separate three kinds of capacity:
Collection: how much feedback can you realistically gather?
Interpretation: how much can you properly analyse and understand?
Action: how much can you actually change?
They're rarely equal. Gathering hundreds of survey responses or a dozen stakeholder opinions in a week is easy. Interpreting them well, separating patterns from isolated observations and acting without derailing everything else is another matter.
Small teams will feel this hardest.
If you're a solo designer, every hour of synthesis competes with time spent designing and delivering. In a team of three to five, there's rarely a dedicated researcher, so processing feedback competes directly with delivery. Larger organisations have more resources, but also more stakeholders, more channels and more opinions. Sometimes feedback even becomes ammunition for winning arguments.
Opportunity costs exist everywhere.
Volume can tempt us to confuse repetition with evidence. If ten people make the same suggestion, it's worth investigating. But repetition alone doesn't tell you how widespread the problem is, how much it matters or whether the suggested fix is right. And one key observation can outweigh a hundred opinions. A single user revealing a fundamental misunderstanding of a critical flow may expose your most serious design problem.
Counting feedback is easy. Judging its significance is harder.
More isn't automatically better, either. Jakob Nielsen's well-known guideline is that around five comparable participants will reveal most usability problems in a qualitative test, and that you're better off fixing those and testing again than adding people to one round.
It's a guideline for a specific kind of iterative test, not a universal sample size, and Nielsen is clear that quantitative research needs far more. But the principle holds: past a point, each extra person tells you less and costs just as much to listen to.
Never treat feedback as instruction
Here's the part I don't think gets said enough.
You can always ignore feedback.
It's just information, and you don't always have to act on it.
That isn't permission to dismiss people or assume designers know what users need better than users do. It's recognising that understanding an experience and deciding how to respond to it are two different activities.
We interpret feedback; we don't just pass it on. That takes the confidence to question a suggestion and the discipline to explain why we're acting on it, investigating it or leaving it alone.
A good team listens carefully, questions its assumptions and takes users seriously. It also accepts responsibility for making decisions. With experience comes a certain steadiness: you hear a note, weigh it against the anchor and decide, without feeling obliged to please everyone.
What to do instead
Not less feedback. More intention, before and after.
Know what you're trying to learn.
Name the assumption you're testing or the decision the feedback will inform. Do people understand the concept? Can they complete the task? Does the need exist at all? If there's no question worth answering, don't ask yet.
Be deliberate about who you ask.
Your intended audience, or a credible proxy, is usually more relevant than people with little connection to the problem. Stakeholders, experts and end users can all be useful, but they aren't interchangeable.
Give people something to respond to.
Set tasks rather than asking "What do you think?". Explain what's unfinished and what to ignore. Watch what people do, explore the reasons behind their reactions and be careful not to lead them towards the answer you want.
Ask for no more than you can process.
Budget interpretation time into the sprint, just as you would build time. Smaller, repeated rounds are often more useful than one big exercise. Make sure someone owns the synthesis.
Triage against your anchors.
For each note, ask:
- 1.
Does it map to a goal, blocker or behaviour we're designing for?
- 2.
Is it describing a problem or prescribing a solution? If it's a solution, what's the need underneath?
- 3.
Is it a reaction to unfinished work we already know about?
- 4.
Who said it, and does other evidence point the same way?
Make conscious decisions and be able to explain them.
Each note gets one of four outcomes: act on it, investigate it, defer it to a named milestone or reject it. Set your criteria before the round, so rejecting a suggestion applies a principle rather than a whim. Record the decision and close the loop with the people who gave you their time.
Take the freelancer who asked for automated invoicing. It points to a potentially real problem: getting paid on time. But it's solution-shaped. You don't yet know whether the pain is creating invoices, remembering to send them or chasing late payments.
It isn't an act. It isn't a reject. It's an investigate.
Listening is not the same as leading
Feedback should make us better informed, not less decisive.
Users should influence the direction of a product, but that doesn't mean every request should shape it. A product team needs to understand what feedback reveals, judge its relevance and decide what the product should become.
That takes a clear sense of purpose, the confidence to challenge assumptions (including your own), and a willingness to say no.
Treat every opinion as a requirement and the product becomes a collection of compromises, shaped by whoever has an opinion and the influence to get it heard.
Listening to users doesn't mean handing them the steering wheel.
Feedback should challenge your assumptions and inform your decisions, but it shouldn't make those decisions for you. Without a clear problem to measure it against, you're not responding to users; you're reacting to requests.
Feedback is an input to good decisions, not a substitute for making them.