Challenges with user interviews

I conducted a fair number of user interviews in my first couple of months.

I had a vague sense of what I was supposed to do: understand user pain points, identify opportunities, and design solutions that addressed real problems. But the more interviews I sat in on, the more I realized I did not actually know how to conduct interviews that uncovered those problems.

A lot of the interviews I saw felt more like feedback collection than research. Users would point out that a small interaction felt off, a color was confusing, or they could not find a feature or button. Those findings often led to the same conclusion: “We need more onboarding.”

But onboarding is rarely the real answer. If people cannot understand or discover something, the problem is often deeper than a missing video. Unless the onboarding flow is designed with clear intent, it can easily become another layer of friction instead of a solution.

So I had to teach myself how to do user interviews the right way. Here are some of the challenges I ran into.

Extrapolation is always hard

With user interviews, you are reading clues from a small sample and trying to draw conclusions for the product. That is inherently risky. A small misread can lead to a very different product decision.

That does not mean interviews are not useful. It means the insights need to be treated as directional, then risk-adjusted through quick iteration, prototype testing, and follow-up research.

Asking the right questions is an art

Users often say things like “this is confusing” or “I like it,” but they do not always explain why.

As the interviewer, you almost have to assume that the first answer will be vague. The real work is in the follow-up: asking better questions, listening for contradictions, and getting specific without leading the participant.

That is probably why interviews cannot be fully replaced by surveys. A survey can tell you what someone selected. An interview can help you understand what they meant.

To avoid getting lost in the weeds, I started creating more structured interview plans. I broke questions into five-minute sections, recorded the sessions with transcripts, used AI to help with synthesis, and shared artifacts with the team so the interpretation was not just sitting in my own head.

I thought my interview plans were getting pretty solid. But the bigger pain point turned out to be less about the interview itself and more about logistics.

Recruiting the right people

I kept wondering whether we were talking to the right people.

Recruiting is not just about finding participants. It is about finding people who match the behavior, segment, or mindset you actually need — without over-filtering so much that recruitment becomes impossible.

Scheduling is a mess

Time zones, work schedules, childcare, reschedules, cancellations, and last-minute conflicts can slow everything down.

Even when people are willing to participate, getting them into the right session at the right time takes more effort than I expected.

No-shows and drop-offs

Even with confirmed sessions, people forget, ghost, or show up late.

You need buffers. You need backups. And you usually need to recruit more people than the number of interviews you actually plan to run.

This was only the beginning. I was not able to scale up as much as I wanted because I got frustrated by no-shows and drop-offs, and I still had design work to do. I was not even thinking much about tooling yet, which I later realized could help a lot. I am excited to set up UserTesting myself and see how much of this process can become smoother.

With AI, the cost of prototyping is getting closer to zero. Designers can generate, test, and iterate on ideas much faster than before.

But if someone can also reduce the cost of recruiting users, running interviews, and testing prototypes, that feels like a huge business opportunity too.