Focus on user needs and jobs, not the asks
A junior designer asked me recently how you’re supposed to make sense of user feedback when it’s all over the place. Ten users, ten opinions, none of them agreeing. How do you find the signal in that?
Ask what they need, not what they want. Wants are generous and specific and everywhere — a feature request, a button, a redesign. Needs take work to get to.
Think about a doctor’s visit. You don’t ask the patient what medication they want. You ask what they’re feeling, where it hurts, when it started. The patient prescribing their own fix isn’t a diagnosis, it’s a guess. The doctor’s job is to find what’s underneath it.
Design works the same way. “I want a button that does X” is a clue, not an answer. Ask what they’re actually trying to accomplish when they reach for it. What happens right before. What breaks without it.
Do that across enough users and the noise organizes itself. Ten requests trace back to three jobs. That’s the map you design against.
The pitfall is mistaking specificity for clarity. “Just add a filter” sounds more useful than “I can never find what I need when I’m in a hurry.” It isn’t. The second one is the actual problem — the first is just where the thinking stopped.
Don’t jump to solution space, yours or theirs. Stay in the problem longer than feels comfortable. Every request is a symptom. Go find out what it’s a symptom of.