After the interviews
Conversion is falling. The team runs five user interviews to understand why. The sessions go well.
Then the team meets to talk about what they found. Someone reads from the transcript and says: “that’s it right there.”
“The onboarding is confusing. I didn’t know why I was being asked for all that information.”
Within an hour, a plan forms. Cut two steps from the onboarding. Rewrite the copy. Fix the message. By the end of the day, there is a ticket open.
The problem is not that the team acted. The problem is that they acted before they understood what the evidence really meant.
The quote felt final. It was not. It was a signal — the start of an analysis, not the end of one.
The mistake most teams make
In our work with product teams, the problem is rarely a lack of user signals. Most teams have quotes, session recordings, drop-off data, and feedback. The problem is that teams often turn those signals into decisions before they fully understand what the signals mean.
This happens at all kinds of companies — small teams running their first interviews and large teams with full research departments.
It usually sounds like this:
- “Users said the onboarding is confusing, so we should reduce the number of steps.”
- “Users said the price feels high, so pricing is the problem.”
- “Drop-off is highest on the plans page, so that page is the issue.”
Each of these statements has a real signal in it. But each one jumps straight from what users said to what the team should do — without the analysis in between.
The quote is the starting point. The recommendation is the end point. What should happen in between — looking at evidence, finding patterns, building interpretations — gets skipped.
The final decision may be in the right direction. But it is not really based on the meaning behind the spoken words or behavior. Most of the time, it is based on what the team was inclined to perceive.
The same problem can have five different causes
When a user says “the onboarding is confusing,” they are describing an experience. That experience has a cause. But the cause is not in the quote. The quote is what came out. Finding the cause requires more work.
The same symptom — “I didn’t understand what to do” — can come from five very different places:
- Cognitive clarity: the words or instructions are not clear enough.
- Usability: the interface creates friction that interrupts what the user is trying to do.
- Value proposition: the user understands the steps but does not see why they matter at that point.
- Psychological safety: the user understands what is being asked but feels the request is too risky or too early.
- Context of use: the user is in a situation where the product does not fit how they actually work.
Each cause leads to a different solution. Better copy helps with the first. A redesigned flow helps with the second. Showing value earlier helps with the third. Adding reassurance helps with the fourth. Adapting to different entry points helps with the fifth.
If the team treats all five as one problem and decides to “reduce onboarding steps,” they may end up with a shorter onboarding that is still just as confusing.
A fix based on the wrong cause is not bad execution. It is a natural result of skipping the analysis. The team did the work. They just worked on the wrong thing.
Understanding the symptom is not the same as understanding the cause. Research that skips this step does not move faster. It costs the same and tells you less.
Building a clear path from signal to decision
The solution is not to do more research or create longer reports. It is to keep a clear connection between the question you are trying to answer and the decision you need to make.
Think of it as a path. The context and the decision shape how the research is set up. The setup determines what questions to ask. The questions determine which method to use. The method produces raw data. The data is turned into clear units of evidence. Evidence is grouped into clusters. Clusters become patterns. Patterns lead to interpretations. Interpretations lead to product decisions.
Each step depends on the step before it. And each step limits what you can claim in the next one.
When you skip a step, the path breaks — and the break is often hard to see. A recommendation without a clear interpretation behind it is just a guess with research language around it. An interpretation without supporting patterns is just an impression. A pattern without real evidence is just a memory of how the sessions felt.
This is the part Soreon protects most carefully: the space between what users say and what product teams decide. Not because the steps are valuable in themselves, but because skipping them leads to decisions that have a weak foundation in the real user experience.
What each step does
These steps do not have to follow a rigid process. They can be done with more or less structure, depending on the size of the project. What matters is that none of them are completely skipped.
Setting up the right question
Before choosing a method, you need a clear question. Not “what do users think of the onboarding” — but something more focused: what is stopping users from finishing the activation, and what exactly needs to be better understood?
A clear question separates the symptom from the hypothesis. The symptom is what you can already observe — a metric, a complaint, a drop-off point. The hypothesis is a possible explanation. Research is meant to test and refine hypotheses, not just confirm what you already suspected.
Choosing the right method
The method should follow the question, not habit. Depth interviews work well for understanding motivation and hidden reasons. Usability tests show where people get stuck. Contextual observation shows the gap between how a product was designed to be used and how it is actually used.
If a team always uses the same method for every question, they will eventually use the wrong tool for a problem they cannot see clearly.
Pulling out the evidence
Raw data from interviews is not evidence yet. It is material that could become evidence. To turn it into evidence, you need to pull out specific units: a specific statement, a specific action, a moment when the user paused, a contradiction between what they said and what they did.
This step requires separating four things: what the user said, what the user did, what the researcher observed, and what the analysis suggests. These are not the same thing. Mixing them up is one of the most common — and hardest to catch — mistakes in qualitative research.
Grouping by real similarity
Evidence is grouped based on what it actually means, not just how it sounds. Two users who said different things may be describing the same experience. Two users who used the same words may be describing very different problems.
Good grouping does not force evidence into categories the team already had in mind. The groups should come from the data, not from assumptions that existed before the research started.
Finding patterns
Groups of evidence become patterns when you can say what they mean. A pattern is not “users had trouble with step three.” It is a statement about what the group suggests: users are being asked to commit before they have enough information to understand why.
Patterns are early interpretations. They represent the best reading the available evidence can support — not a final claim about what users think or feel. This difference matters.
Turning patterns into decisions
Patterns become useful when they connect to product decisions. A product implication is not a recommendation in disguise. It is a statement about what the evidence suggests the team should think about — and what it cannot yet support.
“The evidence suggests that showing value before asking for setup may reduce how much effort users feel” is a statement you can trace and test. “You should restructure the onboarding this way” is a recommendation that needs more validation first. One opens a conversation. The other tends to close it.
The onboarding example, step by step
Go back to the quote from the opening.
“The onboarding is confusing. I didn’t know why I was being asked for all that information.”
The quick reading: reduce the number of steps.
The more careful reading starts differently. When you look at evidence from several sessions, a pattern appears. Users are not confused by the steps themselves. They understand each step on its own. What they cannot figure out is why each piece of information is being asked for before they have seen any real value from the product.
The group of evidence is not “confusing steps.” It is more specific: “users do not understand why they need to give certain information before they see what the product can do for them.”
The pattern: the onboarding asks users to commit before giving them enough reason to do so. The effort feels too large compared to what they have received so far.
The implication is not “remove steps.” It is a set of questions worth exploring: can you show something useful before asking for setup? Can you explain why each piece of information is needed at that moment? Can you separate what is required from what is optional? Where in the flow do users feel the most risk?
Each of these is based on the evidence. Each can be tested. None requires the team to guess which version of “simplify the onboarding” will actually fix the problem.
Five questions to ask before drawing a conclusion
When a user stops, drops off, or says they are confused, the cause is rarely clear from the symptom alone. Before deciding what it means, it is worth asking which of five areas the evidence points to.
The first is cognitive clarity: can the user understand what the product is asking, what it offers, and what they need to do? If not, the problem may be in the words, the structure, or the way information is presented.
The second is usability: can the user move through the product without hitting problems? This is the first area most teams look at — and it is often not the main issue.
The third is value proposition: does the user understand what they will get, and does it feel worth the effort or cost? Confusion about value is often mistaken for a usability problem. This leads to interface changes that do not fix the real experience.
The fourth is psychological safety: does the user feel safe to continue? Do they feel the data they share will be used well? Does the commitment feel reasonable? Does it feel reversible? This kind of hesitation is hard to see in a transcript. It does not show up as “I don’t trust this.” It shows up as a pause, a vague answer, or a session that ends without a clear reason.
The fifth is context of use: is the user in the situation the product was designed for? The device, the environment, what they expected before starting, and how they arrived all shape what the product means to them in that moment.
These five areas are not a checklist. They are a way to keep the analysis open long enough to find the real cause — instead of stopping at the most familiar explanation.
Why this matters for product teams
This is not about following a method perfectly. It is practical. Teams that jump from quote to recommendation are not moving faster. They are working with less information than they think they have. And that gap usually appears later, when the redesign is live and the numbers do not change.
The effects build up in ways teams recognize:
- Decisions are shaped by the most memorable session, not the most consistent pattern across sessions.
- Fixes address how a problem was described, not what caused it — and the real cause stays untouched.
- Teams make change after change without moving the metrics, because they are working on the wrong area.
- Confidence in research slowly drops: it keeps producing recommendations that do not lead to results, so the team stops asking for it.
This last point deserves attention. Research that does not deliver does not just waste time and money. It reduces the team’s belief that understanding users is worth the effort. That makes every future decision harder to base on real evidence.
Research that keeps the full path produces something different: decisions that can be traced back to the evidence, recommendations that can be explained, and a shared understanding of why the team is doing what it is doing.
Good research does not remove uncertainty. It helps you understand it. It tells you which questions have been answered, which ones are still open, and which ones need more work before it is safe to act.
From signal to decision
A user quote is a signal. A metric is a signal. A pattern of drop-off is a signal. Signals are the raw material of research — not the result.
The result is a clear path: from the question that needed to be answered, to the evidence collected, to the patterns found, to the interpretation those patterns support, to the decisions that interpretation can guide.
Good UX Research does not jump from quote to recommendation. It builds that path carefully — and it is honest about where the path ends and where guessing begins.
Every step — setting up the question, collecting data, pulling out evidence, grouping it, finding patterns, drawing implications — exists to protect the final decision from the noise at the beginning. Skipping steps does not make research faster. It makes the decisions more vague and the results harder to learn from.
Better product decisions do not come from faster conclusions. They come from clearer interpretation.
Soreon · soreon.io · Boutique UX Research consultancy with psychological depth for clearer product decisions.
