Why the Most Useful Research Insights Aren't Always the Most Obvious Answers
User interviews aren’t about asking people to design the product for us. They’re about understanding how people think, what they’re trying to accomplish, where they struggle, and how their real experiences compare with what the team believes to be true. The most useful insight is rarely a single answer. It usually appears as patterns begin emerging across conversations.
There’s an interesting thing that happens when you tell someone you’re conducting user interviews. They often assume you’re going to ask users what they want and then design whatever they tell you. It would certainly make research easier if it worked that way.
In reality, users rarely hand us the solution, and that’s not really what we’re listening for. Someone might tell us they want another dashboard, a new filter, fewer steps, or a completely different feature. Those requests are useful, but the request itself is only the beginning of the conversation.
What we’re really trying to understand is what sits underneath it. What is this person trying to accomplish? Where does the current experience make that difficult? What have they learned to work around? What language do they naturally use to describe the problem? And perhaps most importantly, are we hearing something that challenges what the product team believed going into the conversation? Those are the moments that make user interviews valuable.
“Users rarely hand you the solution. That’s not really what we’re listening for.”
We Listen to What People Say, but We Pay Attention to What They Do
People are usually very good at describing what they believe they do. Their actual behavior can tell a slightly different story.
A user might tell us a particular process is straightforward and then spend several minutes explaining the spreadsheet they’ve created to manage it. They might say they use a feature regularly but struggle to remember where it lives. Someone may describe a workflow as “fine” while also mentioning three separate steps they’ve added outside the product just to make it work for them.
None of that means the user is being inconsistent or giving us bad information. People adapt incredibly well to frustrating experiences. Once a workaround becomes part of someone’s routine, they may stop thinking of it as a problem at all.
That’s why we’re listening to the entire story rather than simply recording individual answers. Sometimes the most useful insight isn’t what someone tells us is difficult. It’s what they’ve quietly learned to do because the product isn’t supporting them well enough.
Workarounds Are Usually Worth Paying Attention To
Workarounds are one of our favorite things to uncover during research because they can reveal needs that the existing product isn’t meeting.
Maybe users export information into a spreadsheet because they can’t compare it easily inside the platform. Perhaps they keep notes somewhere else because the product doesn’t give them enough context. They may repeatedly copy information between systems, create their own naming conventions, or develop a sequence of steps that nobody on the product team realized was happening.
One workaround doesn’t necessarily mean the product needs to change. When the same frustration or behavior starts appearing across multiple conversations, however, it becomes much more interesting.
Patterns help us separate individual preferences from broader experience problems. They give the team something more substantial to investigate and help us understand where design changes could create meaningful value rather than simply responding to the loudest request.
The Words Users Choose Matter Too
We’re not only listening for problems. We’re listening to how people naturally talk about them.
Product teams spend so much time inside their own software that internal terminology can start to feel universal. Feature names, categories, and industry language become familiar because the team uses them every day. Users may describe the exact same things very differently. Those differences can influence more than copy.
The language people use gives us clues about their mental model of the product. It can help us understand how they group information, what they expect certain actions to do, and which concepts make sense to them without explanation. Sometimes a word that feels completely obvious internally creates confusion for the people actually using the product.
Capturing that language during interviews gives designers and product teams another source of context when we begin thinking about navigation, labels, content, workflows, and information architecture.
We're Especially Interested When Something Doesn't Match Our Assumptions
Going into research, every team has assumptions. We do too.
We might believe we understand why users are abandoning a workflow, which features matter most, or what is causing a particular frustration. Stakeholders may have theories based on support requests, analytics, sales conversations, or years of experience with customers.
Research gives us an opportunity to see whether those assumptions hold up. Sometimes they do, and that’s useful because the team gains greater confidence in the direction. Other times, a few conversations begin telling a completely different story. The problem users describe isn’t the one everyone expected, or something the team believed was important barely comes up at all.
Those contradictions aren’t inconvenient findings to work around. They’re often some of the most valuable things we can learn because they give us a chance to adjust our thinking before that assumption becomes a design decision, a development ticket, or a shipped feature.
One Interview Is a Story. Patterns Create Direction.
A single user conversation can be incredibly insightful, but we have to be careful not to redesign an entire product around one person’s experience.
After interviews, much of the work happens in synthesis. We review notes, compare conversations, group related observations, and look for themes that appear across participants. We start seeing repeated frustrations, similar behaviors, shared language, and moments where different users are trying to accomplish the same thing in slightly different ways.
This part of the research process can look considerably less exciting than the interview itself. There may be a lot of notes, sticky notes, spreadsheets, transcripts, or a FigJam board that makes perfect sense to the research team and looks mildly alarming to everyone else.
But synthesis is where individual conversations begin becoming useful product knowledge. Instead of reacting to isolated comments, we can start asking what the patterns are telling us about the experience as a whole.
Then the Research Has to Become a Decision
Research isn’t valuable simply because interviews were conducted. Eventually, what we learn needs to influence what gets built.
A repeated frustration might lead us to reconsider a workflow. A common workaround could reveal an opportunity to simplify a task. The language users naturally use might change how information is organized or labeled. An assumption that doesn’t hold up may cause the team to rethink a feature before investing further in it.
Not every observation becomes a design change, and it shouldn’t. Product decisions still have to consider business goals, technical constraints, priorities, and the broader experience. Research adds the user perspective to those conversations so teams aren’t making decisions based entirely on what they think people need.
The goal isn’t to turn every interview quote into a feature. It’s to use what we’ve learned to make better-informed choices.
What This Looks Like at Pepperplane
At Pepperplane, user interviews are less about following a rigid list of questions and more about creating enough space for people to tell us how they actually experience a product or problem.
We come into interviews knowing what we want to learn, but we’re also listening for the unexpected. We ask follow-up questions when someone mentions an interesting workaround. We dig deeper when an answer contradicts something we’ve heard internally. We pay attention to repeated language, moments of hesitation, and details that might seem small until they start appearing across several conversations.
Afterward, we bring those conversations together through research synthesis. We look for patterns, discuss what surprised us, connect what we’re hearing back to the business and product context, and determine which insights should influence the work moving forward.
The interview is only one part of the process. The real value comes from understanding what all those conversations are telling us together.
Final Thought
Good user research requires curiosity, but it also requires restraint. It’s tempting to hear one compelling idea and immediately start designing around it. It’s tempting to take every feature request literally or treat every interview answer as a requirement. But that’s not really the job.
Our job is to listen carefully enough to understand what people are experiencing beneath the individual requests. We look for the frustrations that keep appearing, the workarounds users have normalized, the language they naturally use, and the moments where reality doesn’t quite match what the team expected.
Then we connect those patterns back to the product decisions in front of us.Users don’t need to hand us the solution.They give us something much more valuable: a clearer understanding of the problem. And that’s where better design begins.
Ready to Build Better Products Together?
Looking for a UX partner who can bring clarity to your next project? We’d love to chat.
Book a discovery call and let’s build something remarkable together.
