Start with what people described, not what you hope it means
An interview can leave a team with a vivid story and a strong urge to act. A customer may describe a difficult sign-up process, ask for a new feature or praise a competitor’s approach. Each comment is useful, but none is a decision on its own. Interviews are especially good at showing how people understand a situation, what they have tried and where they encountered friction. They are less reliable as predictions of what someone will do after a change is made.
Begin by separating observations from interpretations. “The participant checked three pages before contacting support” describes behavior. “The navigation is broken” is one possible explanation. “Add a prominent support button” is a proposed solution. Keeping these statements distinct makes it easier to consider other explanations, such as unclear wording or missing information on the first page.
For each interview, capture the situation, the person’s goal, the steps they took and the outcome. Preserve short, accurate notes about their reasoning, including moments when they were unsure. Avoid reducing the account to a label such as “wants convenience,” which may hide the specific difficulty a team could address.
Find patterns without flattening differences
After several interviews, group related observations around tasks or moments in the customer journey. You might notice that people struggle to compare options, hesitate before committing or seek reassurance after making a purchase. Look for the circumstances in which each difficulty appears. A problem that affects first-time customers may call for a different response from one that affects experienced customers handling an unusual case.
Record both supporting and conflicting examples. If some participants completed a task easily, ask what differed: their prior knowledge, the route they took or the information available to them. The aim is not to force every interview into one theme. It is to form a precise statement that could be wrong, such as: “People choosing between plans cannot tell which limits matter for their intended use.”
Note how much confidence the interviews warrant. A theme heard repeatedly may deserve attention, but a small or narrowly recruited set of interviews cannot establish how common it is across the whole audience. A single account can still reveal a serious or overlooked issue. Treat it as a reason to investigate, not proof of its prevalence.
Translate each insight into a decision and a hypothesis
A useful finding connects a customer difficulty to a choice the team can make. Write the choice plainly: simplify plan descriptions, change the order of onboarding steps or offer a clearer way to reach a person. Then state the hypothesis behind it. For example: “If we explain plan limits using common tasks, people comparing plans will select an appropriate option with less help.” This makes the expected effect visible instead of letting the proposed solution stand in for the problem.
Prioritize possible decisions by asking three questions. How consequential is the difficulty for the customer and the service? How directly do the interviews support your understanding of it? How easily could you learn whether a change helps? These questions do not require a complex scoring system. They help distinguish a promising next test from an interesting comment that is not yet actionable.
Keep alternative explanations nearby. If customers abandon a booking form, unclear instructions may be responsible, but the price, timing or need to gather information could also matter. Naming alternatives prevents a team from interpreting any later improvement as confirmation of its favorite theory.
Choose a test that matches the uncertainty
The smallest useful test depends on what you need to learn. If the uncertainty is whether people understand proposed wording, ask relevant participants to explain it in their own words. If it is whether they can complete a task, observe them trying a realistic prototype or revised flow. If it is whether a change affects behavior in use, a limited rollout with an appropriate comparison may be more informative. No single method answers every question.
Decide what evidence would count before running the test. For a revised plan comparison, this might include whether participants can explain key differences, choose a plan for a stated situation and identify information they still lack. Include signals of unintended effects: simpler wording might help newcomers while omitting details that experienced customers need. When a test uses a small group, focus on what it reveals about the design rather than treating the result as a population estimate.
Close the loop and keep a record of the reasoning
After testing, compare what happened with the original hypothesis. Did people behave as expected? Did the change solve the difficulty you observed, or merely move it to another step? A result that challenges the hypothesis is valuable because it narrows the next question. The team might revise the solution, investigate an alternative explanation or decide that the issue is less urgent than it first appeared.
Keep a brief decision record containing the interview pattern, the proposed change, the test, the outcome and any remaining uncertainty. This helps colleagues understand why a decision was made and prevents a memorable quote from becoming a permanent rule. The goal is not to remove judgment from product or service work. It is to make judgment more deliberate: listen carefully, describe the problem precisely, test a response and update the decision when new evidence appears.
