When Users Don't Know What They Want: The Art of Interpreting Feedback

Understanding why users can’t always express what they want helps you interpret feedback more effectively.

– They lack design vocabulary

Most people don’t have language for design concepts. They can’t say “the visual hierarchy is unclear” or “the information architecture doesn’t match my mental model.” Instead they say “it’s confusing” or “I can’t find anything.” Your job is translating vague descriptions into specific design problems.

– They confuse symptoms with root causes

A user might request a search feature when the real problem is poor navigation. They might ask for more options when they’re actually overwhelmed by how choices are presented. They’re describing the pain point, not diagnosing the underlying issue.

– They’re bounded by current solutions

People imagine improvements as incremental changes to what exists, not radical reimagining. They ask for features from competitor products rather than expressing the underlying needs those features address.

– They prioritise recent experiences

Feedback is disproportionately influenced by whatever happened most recently. A frustrating interaction five minutes ago dominates their assessment more than dozens of successful interactions. Recency bias skews perception.

– They’re influenced by social desirability

In research settings, people want to be helpful, appear smart, and avoid seeming critical. This shapes what they say. They might soften criticism, agree with perceived expectations, or claim to want features they think they should want.

– They can’t predict future behaviour

People are terrible at predicting their own future actions. They say they’d use a feature regularly, but when it’s built, they ignore it. Stated preferences don’t match revealed preferences — what people say differs from what they do.

– Context is invisible to them

Users experience your product in specific contexts they don’t necessarily recognise or articulate. Feedback about “the interface is too small” might really mean “I use this on my phone while commuting, and the tapping targets are hard to hit with one hand on a moving train.” They describe symptoms without context.

The Gap Between Stated and Revealed Preferences

The most critical insight about user feedback: what people say they want and what they actually respond to are often different things.

– The feature request paradox

Users confidently request features they’ll never use. They imagine scenarios where these features would be valuable, but those scenarios rarely materialise in actual use. Feature bloat often starts with well-intentioned attempts to give users what they asked for.

I’ve watched teams build highly-requested customisation options that analytics later showed less than 5% of users ever touched. The requests were genuine — users thought they wanted control. But in practice, they preferred good defaults and didn’t want to invest time in customisation.

– The simplicity contradiction

Users say they want simplicity, but they also want power and control. They want fewer options, but they don’t want to lose any specific option. Everyone supports simplification in principle but objects to any particular feature being removed.

The solution isn’t giving users everything or ruthlessly cutting features. It’s understanding that “simplicity” really means “make it easy for me to do what I need without obstacles” and “power” means “give me control over things that matter to me.” These aren’t actually opposed.

– The aesthetic judgment trap

When users say a design is “ugly” or “not professional,” they’re often expressing something else entirely. Maybe it lacks visual hierarchy, so they perceive chaos. Maybe it violates their expectations, so they perceive incorrectness. Maybe it’s actually fine, but one small element triggers negative associations.

Dig deeper. What specifically bothers them? Where do their eyes go first? What expectations does this violate? “Make it look better” isn’t actionable. Understanding what “better” means to them is.

Interpreting Feedback: Practical Techniques

Translating user feedback into actionable insights requires structured approaches:

1. Ask “Why” Repeatedly

When users make requests or express preferences, ask why. Then ask why again. And again. The “Five Whys” technique from root cause analysis works brilliantly for understanding feedback.

User says: “The dashboard needs more customisation options.”  

You ask: “What would you customise?”  

User: “The widgets. I want to rearrange them.”  

You ask: “What about the current arrangement doesn’t work for you?”  

User: “The things I use most are at the bottom.”  

You ask: “Which things do you use most?”  

User: “The activity feed and recent items.”

Now you understand: the problem isn’t lack of customisation. It’s that important information is deprioritised in the default layout. The solution might be reordering defaults, not building customisation infrastructure.

2. Observe Behaviour, Not Just Words

Watch what people do, not just what they say. This is why usability testing is more valuable than interviews alone. Behaviour reveals truth that words obscure.

They say: “This is intuitive.”  

They do: Click the wrong button three times before finding the right one.

They say: “I never use search.”  

Analytics show: 40% of their sessions start with search.

They say: “Too many steps.”  

Session recordings show: They complete the flow smoothly without hesitation.

Observation provides ground truth. Words provide interpretation and context. You need both, but prioritise behaviour when they conflict.

3. Look for Patterns Across Users

Individual feedback is anecdotal. Patterns across multiple users reveal real issues. But don’t just count mentions — understand contexts.

If five users mention the same problem, that’s significant. If those five users are all from the same use case or persona, it might be a niche issue. If they represent diverse backgrounds and use cases, it’s likely fundamental.

Also notice what people don’t mention. If you suspect a feature is confusing but no one complains, maybe it’s actually fine. Or maybe it’s so broken people don’t even try to use it. Context determines interpretation.

4. Distinguish Between Problems and Solutions

Users are excellent at identifying problems. They’re less reliable at proposing solutions. When users suggest solutions, extract the problem they’re trying to solve.

User says: “Add a dark mode.”  

This is a solution. The problem might be: eye strain from bright interfaces, desire for aesthetic customisation, or following current design trends.

User says: “The font is too small.”  

This is closer to a problem, but still might be a symptom. The root issue might be: poor visual hierarchy making them scrutinise text, inadequate contrast reducing legibility, or content density making scanning difficult.

Your job is finding the actual problem so you can determine the best solution — which might not be what users suggested.

5. Categorise Feedback by Type

Not all feedback deserves equal weight. Categorising helps you prioritise:

Usability issues — users can’t accomplish tasks or struggle significantly. These are high priority because they directly impede value delivery.

Preference statements — users express taste or desire for alternatives that work equally well. These are lower priority unless patterns emerge showing preferences that affect adoption or satisfaction.

Feature requests — users want additional capabilities. Evaluate against product strategy and actual demonstrated need, not just stated desire.

Emotional reactions — users express how something makes them feel. These reveal important perception issues even if not directly actionable.

Technical reports — bugs, errors, performance problems. These are usually straightforward to triage and address.

6. Context Questions Reveal Needs

When users give feedback, ask about context:

– When does this problem occur?

– What are you trying to accomplish when this happens?

– How often does this affect you?

– What do you do to work around it?

– Who else experiences this issue?

– What would change if this was fixed?

Context transforms vague complaints into specific requirements. “The app is slow” becomes “When I’m uploading files over cellular data during my commute, progress isn’t clear and uploads fail without notification.” Now you can design solutions.

7. Separate “Nice to Have” from “Must Have”

Users often present everything as equally important. Your job is triaging actual priority.

The Kano model helps: some features create satisfaction when present but don’t cause dissatisfaction when absent (delighters). Some features cause dissatisfaction when absent but don’t increase satisfaction when present (basics). Some features increase satisfaction proportionally (performance features).

Ask: “If we couldn’t include this, how would that affect your use of the product?” Answers reveal whether something is essential, valuable, or just nice.

Common Misinterpretations and How to Avoid Them

Even experienced designers fall into traps when interpreting feedback:

– The Vocal Minority Trap

A small number of power users provide most feedback, but they don’t represent most users. Their needs are real but might not be universal.

Power users want complexity, customisation, and advanced features. Casual users want simplicity and clarity. If you only listen to vocal power users, you’ll optimise for the wrong audience.

Solution: Actively seek feedback from quiet majority through observation, analytics, and proactive research with representative users.

– The Recency Bias

Whatever users experienced most recently dominates their feedback. A frustrating interaction colours their entire perception, even if most interactions are fine.

Solution: Look at longitudinal data, not just immediate reactions. Track satisfaction over time. Observe multiple sessions, not just moments after problems occur.

– The Feature Parity Fallacy

Users see competitor features and request equivalent capabilities. But competitors might have those features because of different strategies, constraints, or user bases.

Solution: Understand why competitors made those choices and whether the underlying needs exist in your user base. Don’t chase feature parity; address actual needs.

– The Expert Blind Spot

As you become expert in your product, you lose ability to see it through novice eyes. User feedback that seems obviously wrong might reveal legitimate confusion you’re too expert to perceive.

Solution: Regularly watch completely new users interact with your product. Their “ignorance” is actually fresh perspective revealing real usability issues.

– The ‘Build It and They’ll Come’ Mistake

Users enthusiastically request features they imagine using. But imagination doesn’t equal usage. The effort to build rarely justifies adoption if need isn’t demonstrated.

Solution: Validate demand before building. Create prototypes or mockups and watch whether users actually engage. Track expressed interest against demonstrated behaviour.

– Advanced Interpretation: Reading Between the Lines

Skilled interpretation goes beyond surface feedback to understand deeper needs:

– Emotional Subtext

How users describe problems reveals underlying emotions and priorities. Listen to language intensity, frustration levels, and what they emphasise.

“This is annoying” signals different priority than “This is absolutely infuriating and makes me want to switch products.” Both are problems, but urgency and impact differ dramatically.

– Workarounds as Innovation Signals

Pay attention to how users work around limitations. Their workarounds reveal both the severity of problems and potential solutions.

If users maintain external spreadsheets to track information your product should handle, that’s a strong signal. If they’ve developed elaborate processes to compensate for missing features, you’ve found high-value improvement opportunities.

– Silence as Signal

What users don’t mention can be as revealing as what they do. If you expect certain features to be problematic but no one complains, investigate. Maybe they’re fine. Maybe they’re so broken users gave up.

Similarly, features you’re proud of that generate no comments might be invisible, irrelevant, or perfectly adequate and therefore unremarkable.

– Competitive Context

How users compare your product to alternatives reveals priorities and expectations. “Competitor X has this feature” tells you about competitive pressure and user expectations.

But dig deeper: Do they actually use competitor products? What do they prefer about competitors? What brings them back to your product despite missing features?

– Temporal Patterns

Feedback timing matters. Immediate reactions differ from long-term impressions. New user feedback reveals onboarding friction. Long-time user feedback reveals feature depth and power user needs.

Track how feedback changes as users gain experience. Issues that frustrate new users might be non-issues for experienced ones, and vice versa.

– Balancing User Feedback with Vision

Interpreting feedback doesn’t mean blindly implementing everything users request. It means understanding needs so you can make informed product decisions.

– When to Listen

User feedback should drive decisions when:

– Multiple users independently identify the same problem

– The feedback aligns with product strategy and vision

– Behaviour data confirms stated needs

– The issue affects core user journeys

– Fixing the problem doesn’t compromise other important goals

– When to Resist

You should question or override feedback when:

– Requests conflict with long-term vision

– Vocal minority dominates silent majority needs

– Stated preferences conflict with observed behaviour

– Solutions would add complexity disproportionate to benefit

– Requests would serve one persona at expense of others

– You have insight into future needs users don’t see yet

Steve Jobs famously said people don’t know what they want until you show it to them. This isn’t dismissing user feedback — it’s recognising that innovation often requires seeing beyond current mental models.

Finding the Balance

The art is holding vision while remaining responsive to real needs. Vision without user grounding produces beautiful products no one can use. User feedback without vision produces feature bloat and lack of coherence.

Best practice: Let user feedback reveal problems, but don’t let it dictate solutions. Users tell you what hurts. You determine how to heal.

– Creating Systems for Better Feedback

Rather than just interpreting feedback reactively, create systems that generate better feedback proactively:

– Ask better questions

Instead of “What do you think?” ask “Show me how you’d accomplish [specific task].” Instead of “Do you like this?” ask “When would you use this?” Task-oriented questions reveal more than opinion questions.

– Create multiple feedback channels.

In-app feedback captures immediate reactions. Scheduled interviews provide depth. Analytics show actual behaviour. Social media reveals unsolicited opinions. Each channel provides different signal.

– Segment feedback by user type.

New users, power users, churned users, and potential users all provide valuable but different feedback. Don’t aggregate everything together — segment so you can understand each perspective.

– Close the feedback loop

Tell users what you did with their feedback. This encourages better feedback because they see it matters. It also helps you validate whether your interpretation was correct.

– Build feedback into workflow

Don’t make users go to separate forms or surveys. Capture feedback where they experience problems, when context is fresh and specific.

The Continuous Practice

Interpreting user feedback is a skill developed through practice, not a checklist to follow. The more you observe users, analyse feedback, implement changes, and measure results, the better you become at translation.

You start recognising patterns. You develop intuition about when stated needs mask deeper issues. You learn which users represent broader populations and which are outliers. You become fluent in the language of needs that users speak imperfectly.

This doesn’t make you better than users or give you permission to ignore them. It makes you a better advocate for them — someone who can understand what they need even when they can’t fully articulate it themselves.

The best designers are interpreters, translators, and sometimes psychologists. They hear “make it blue” and understand “make it feel trustworthy.” They hear “add more features” and understand “help me accomplish my goals more efficiently.” They hear “this is confusing” and understand “this violates my expectations.”

This is the craft: not just listening to users, but truly hearing what they need.

Further Reading

1. ”The Mom Test” by Rob Fitzpatrick  

Fitzpatrick’s guide to customer conversations teaches how to extract truth from people who want to be nice to you. His techniques for getting past polite feedback to actual needs are essential for any designer conducting user research.

2. ”Interviewing Users” by Steve Portigal

Portigal’s comprehensive guide to user interviews covers not just asking questions but interpreting responses. His emphasis on listening deeply and reading between the lines makes this invaluable for understanding stated vs. actual needs.

3. ”Observing the User Experience” by Elizabeth Goodman, Mike Kuniavsky, and Andrea Moed  

This comprehensive research guide emphasises observation over asking, showing how to discover needs users can’t articulate. The methods for combining different research approaches are particularly valuable.

4. ”Thinking, Fast and Slow” by Daniel Kahneman  

Kahneman’s exploration of cognitive biases and decision-making reveals why people can’t always articulate what they want. Understanding these psychological foundations helps designers interpret feedback more accurately.

5. ”Don’t Make Me Think” by Steve Krug 

While focused on usability, Krug’s emphasis on observing users struggling reveals how behaviour trumps stated preferences. His testing methodology helps separate real problems from imagined ones.