Your Job Isn't to Give Users What They Want

Henry Ford never asked people what they wanted.

If he had, they would have said "faster horses."

Yet somehow, the design industry has convinced itself that user feedback is sacred. That every request deserves consideration. That saying "no" to users makes you a bad designer.

Here's what no one wants to admit: Most user feedback is actively harmful to your product.

Not because users are wrong about their problems. But because they're catastrophically bad at designing solutions.

I've watched talented teams destroy elegant products by treating user requests like religious commandments. I've seen startups die from feature bloat because they couldn't distinguish between what users say they want and what would actually solve their problems.

After leading design at three different marketplaces and watching this pattern repeat, I'm done being polite about it: Your job isn't to give users what they want. It's to give them what they can't even articulate they need.

The Graveyard of Literal Interpretations

Microsoft Clippy existed because users said they wanted help. What they actually wanted was software that didn't need help.

Google Wave had everything users asked for: real-time collaboration, email integration, document sharing. It died because users didn't actually want everything in one place; they wanted their existing tools to talk to each other.

Snapchat's 2018 redesign gave users what they said they wanted: cleaner separation between friends and brands. They lost 3 million daily active users because what users actually wanted was not to think about organization at all.

Every one of these failures started with taking user feedback literally.

The pattern is always the same: Users describe symptoms. Companies build band-aids. Products become Frankenstein monsters of accumulated quick fixes. Everyone wonders why the experience feels so broken.

Why Users Can't Tell You What They Need

There's a cognitive psychology principle called the Dunning-Kruger effect. People with limited knowledge in a domain overestimate their competence in that domain.

Users are experiencing a design problem through the lens of their immediate frustration, not system thinking. They're solving for their momentary pain, not the holistic experience.

Three psychological barriers make users terrible designers:

The Curse of Knowledge Reversal

Users don't know what they don't know about your technical constraints, business model, or other user segments. They make suggestions from a sample size of one: themselves.

Real example from my marketplace work: Sellers constantly request "automatic pricing" features. What they actually need is confidence that their prices are competitive. The solution isn't AI pricing. It's better market visibility and comparison tools. But they don't know that's possible, so they ask for what seems logical to them.

Solution Aversion Bias

Users avoid suggesting changes that feel like "more work" for them, even if it would solve their problem better. They'll ask for shortcuts that actually make their journey longer.

Case in point: Users requested a "duplicate order" button to avoid re-entering information. Analytics showed 78% of "duplicated" orders were then heavily edited. The real solution was better order templates and smart defaults, not duplication. But templates felt like "setup work," so users never asked for them.

The Articulation Gap

Users experience problems emotionally but communicate them functionally. "This is confusing" becomes "Add more explanations." "I'm worried" becomes "Show me more data." The emotion is valid; the prescription is wrong.

They're not lying to you. They literally cannot articulate what they need because they're too close to their own frustration.

The DECODE Method for Translating User Requests

After years of misinterpreting user feedback, I developed a framework that actually works:

D - Dig into the trigger What specific moment triggered this request? Not the general experience but the exact second frustration hit. "I needed to add a discount" is vague. "I couldn't find where to add a discount after creating the listing" is actionable.

E - Explore adjacent behaviors What were they doing right before and after? The context reveals more than the complaint. A user asking for "better search" might actually be struggling with category navigation.

C - Challenge the prescription "If we solved it differently than your suggestion, what would success look like?" This question separates the need from the assumed solution.

O - Observe the contradiction Watch for the gap between what they say and what they do. That gap is where truth lives. Users say they want simplicity but consistently choose feature-rich options when given the choice.

D - Diagnose the root Is this a navigation problem disguised as a feature request? A trust issue masquerading as a functionality gap? Most "feature requests" are actually existing features that are invisible or workflows that are broken.

E - Execute on insights, not instructions Design for the diagnosis, not the symptom. This is where your expertise matters most.

When Numbers Expose the Lie

At my previous company, we tracked every feature request for six months, then compared them against actual usage patterns:

• 87% of requested features were used less than once a month when built

• The loudest 10% of users represented less than 2% of revenue

• Features users "couldn't live without" had a 6% adoption rate

• Silent majority behavior contradicted vocal minority requests 9 out of 10 times

But here's the killer insight: When we solved the underlying problem (not the requested feature), satisfaction scores increased by 34%.

The Microsoft Office Ribbon study found similar patterns. Users hated it vocally. Usage data showed they were finding functions 40% faster. The complaint wasn't about the ribbon. It was about change.

Your analytics dashboard isn't lying. Your users aren't lying either. They're just speaking different languages.

The Power of Strategic Disobedience

Some of the best design decisions I've made involved explicitly not doing what users asked for.

Users asked for more filters. We reduced them and improved search intelligence. Engagement went up 40%.

Users asked for a dashboard showing "everything." We created focused views for specific tasks. Task completion improved by 60%.

Users asked for email notifications for every action. We built a smart digest. Unsubscribe rates dropped 70%.

Each time, the initial reaction was resistance. Each time, the long-term result was delight.

Because we solved what they needed, not what they requested.

When to Actually Listen Literally

Nuance matters. There are times to take requests at face value:

Accessibility needs. When someone says "I can't read this," believe them. Don't interpret. Fix it.

Data requests. When users ask for specific information visibility, they usually know what they need to see. A financial dashboard user asking for P&L data knows their requirements.

Integration requests. Users know their tool stack better than you do. If they're asking for Slack integration, they need Slack integration.

Compliance requirements. Legal and regulatory needs are non-negotiable. When someone says "we need audit logs for SOC 2," that's not a suggestion.

The skill is knowing the difference between a preference, a problem, and a requirement.

Communicating This Without Sounding Like an Asshole

The biggest challenge isn't understanding this principle. It's getting buy-in from stakeholders who think "customer-centric" means "customer-commanded."

Try these reframes:

Instead of "Users don't know what they want," say "Users are excellent at identifying problems but we're better positioned to design solutions."

Instead of "We're not building that," say "Let's understand the job they're trying to accomplish first."

Instead of "That's a bad idea," say "What outcome would that create for them?"

Small language shifts that transform confrontation into collaboration.

The Uncomfortable Truth

The next time someone says "users are asking for...", stop them.

Ask instead:

• What problem are users trying to solve?

• What does their current workaround tell us?

• What would they do if we said no?

Because here's the uncomfortable truth our industry needs to accept:

Users hired you for your expertise, not your obedience.

They can tell you where it hurts. They can show you their frustration. They can share their context.

But they can't design the solution.

That's your job.

And if you're just implementing whatever users ask for, you're not a designer. You're a very expensive pair of hands.

The best products in the world, the ones users actually love, were created by designers who had the courage to interpret, not just implement. Who understood that giving users what they need often means not giving them what they want.

Your users don't need a yes-person.

They need a translator.

Be one.