Design Principles That Improve User Interviews

Why user interviews are crucial for product success comes down to a simple truth: you cannot build great products based on assumptions alone. Guess what - your assumptions are wrong.

Traditional approaches to user interviews often fall short because they’re designed to confirm what you already believe rather than discover what you don’t know. Leading questions. Polite users who tell you what you want to hear. Confirmation bias masquerading as research.

Let me share principles that transform interviews from validation theatre into genuine learning.

Implementation Approach

Best Practices

Principles that improve interview quality dramatically:

Ask about the past, not the future. “Would you use this feature?” gets you speculation. “Tell me about the last time you faced this problem” gets you reality. Past behaviour predicts future behaviour far better than hypothetical preferences.

Follow the emotion. When users express frustration, excitement, or confusion, dig deeper. “You mentioned that was frustrating—tell me more.” Emotional moments reveal what truly matters.

Stay curious, not confirmatory. Your job isn’t to validate your ideas. It’s to understand user reality. If you’re excited when users agree with you and disappointed when they don’t, you’re doing it wrong.

Listen more than you talk. A good interview has the user speaking 80% of the time. If you’re explaining, pitching, or filling silence, you’re losing signal.

Ask “why” repeatedly. Surface answers rarely reveal true motivations. Keep asking “why” until you reach something fundamental. Five levels of “why” often gets to the real insight.

Embrace uncomfortable silence. Silence after a question feels awkward. It also prompts deeper thought. Resist the urge to fill it.

Tooling and Process

Practical recommendations for interview execution:

Interview in pairs. One person leads the conversation; one takes notes. It’s nearly impossible to do both well simultaneously.

Record with permission. Recordings let you focus on the conversation and review details later. Always get explicit consent.

Use a consistent structure. Start with context (who they are, what they do). Move to behaviour (what they actually do today). End with reactions (responses to concepts or prototypes).

Limit discussion guides. A few key themes are helpful. Rigid question lists prevent following interesting threads. Stay flexible.

Debrief immediately. Right after each interview, capture key insights while fresh. What surprised you? What confirmed your thinking? What requires follow-up?

“The goal of user interviews isn’t to gather quotes that support your roadmap. It’s to understand reality well enough to challenge your roadmap.”

Scaling What Works

Growth Considerations

As interview practices mature, consider these evolutions:

Build a research repository. Individual interviews have value. Accumulated interviews across time have much more. Create searchable archives of insights, not just recordings.

Develop interview capability broadly. Don’t concentrate interviewing skill in one person. Train product managers, designers, and even engineers to conduct quality interviews.

Create participant panels. Finding interview participants is often the bottleneck. Build ongoing relationships with users willing to provide feedback. Maintain diverse representation.

Connect to decision processes. Interviews should influence roadmaps, designs, and priorities. If they don’t, you’re collecting data for its own sake. Create explicit links between research and decisions.

Maintaining Quality

As interviewing scales, quality risks emerge:

Interviewer bias compounds. More interviewers means more potential for leading questions and confirmation bias. Invest in training and peer review.

Selection bias creeps in. It’s easier to interview engaged, articulate users. They’re not representative. Actively seek hard-to-reach segments.

Synthesis suffers. More interviews mean more data to process. Build synthesis practices that keep insights actionable rather than overwhelming.

Ritual replaces learning. “We did our interviews” can become a checkbox rather than a source of insight. Keep asking: what did we learn? How did it change our thinking?

The Development Context

Technical Considerations

User interviews inform technical decisions in several ways:

Workflow discovery reveals integration requirements. Users describe how your product fits into their broader tooling. This informs API design, import/export features, and interoperability priorities.

Performance expectations emerge through conversation. What speed do users consider acceptable? Where do delays cause frustration? This informs performance targets and optimisation priorities.

Mental models shape interface design. How do users conceptualise the problem domain? Misalignment between user mental models and system architecture creates confusion.

Edge cases surface. Users describe scenarios you hadn’t considered. These inform error handling, validation logic, and edge case support.

Team Dynamics

Interviews affect team dynamics in important ways:

Shared exposure builds empathy. When engineers hear users struggling directly, they care differently about usability than when hearing secondhand summaries. Include the whole team in research, at least occasionally.

Evidence reduces conflict. Debates about user needs become more productive when grounded in interview evidence. “Users told us X” carries more weight than “I think users want Y.”

Different perspectives notice different things. A designer notices usability signals. An engineer notices technical workflow. Cross-functional interview participation enriches insights.

Key Takeaways

Ask about past behaviour rather than future intentions - “Tell me about the last time” beats “Would you use this”
Follow emotional signals by digging deeper when users express frustration, excitement, or confusion
Listen more than you talk; aim for the user speaking 80% of the time
Interview in pairs with one person leading and one taking notes
Build a research repository and connect insights to decision processes

Call to Action

Here’s your challenge: schedule two user interviews this week.

Don’t wait for a formal research project. Don’t build an elaborate discussion guide. Just find two users and have conversations about their experience with the problem your product addresses.

Ask about their current behaviour. Listen for emotional cues. Dig into the “why” behind their answers.

What you learn may surprise you. That’s the point.

Have questions or thoughts? Get in touch - I’d love to hear from you!