Some users know exactly what they want. Most wouldn't be able to articulate it clearly if you gave them a whiteboard and an hour. Neither group matters as much as you'd think. Great design comes from watching what people actually do, not transcribing what they say they'd like.

Everyone adapts and tolerates and in the absence of something better, it will be accepted. Everyone has probably at some point invented a workaround for something that should just work. The three-click detour that should take one click. The feature buried three levels deep that nobody uses because nobody can find it. What this should tell you is that the product needs attention and consideration to figure out that which most people sometimes cannot put into words.

The better question to be asking isn't "what do users want?" It's "what sucks enough that someone would actually pay money for a better solution?" A good designer curious enough will live and breathe the problem, try it, recreate it.

The faster horse quote is usually misattributed to Henry Ford, but the point holds regardless. If Ford had surveyed customers, they'd have asked for a horse that didn't tire out. They couldn't picture a car because they'd never seen one. This is just how we work and this is also why we are the product designers to do the wild, innovative thinking. You can't want what you can't picture. Which is why asking is often the wrong tool for the job.

The real opportunity is being the person in the room who noticed what everyone else stopped seeing years ago. The clunky flow the team has explained away for two years. The workaround half the users have independently invented. That stuff is gold, and it's often hiding in plain sight and the difference is in caring about it.

Watch behaviours instead of collecting opinions. Sit with users in their actual environment, not a sterile usability lab where everyone performs competence. Watch what they skip. Watch what they Google mid-task. The answer is almost always more interesting than the feature they think they'd need.

Prototype early and put it in front of real people before it's polished. A rough prototype in week two teaches you more than a beautiful one shown to stakeholders in week twelve. And when the reaction is lukewarm ("yeah, that could work, maybe"), walk away. Lukewarm isn't a good sign and often means you've conveyed your idea poorly or the solution hasn't been specified correctly. The things worth building get a very specific response: either "I've been waiting for this" or "why doesn't this already exist?"