What Questions Should I Ask During User Interviews?

Building an app without talking to real users first is like trying to solve a puzzle with half the pieces missing. You think you know what people want, you've got this brilliant idea that keeps you excited, but then your app launches and... crickets. Downloads are low, engagement is terrible, and you're left wondering what went wrong.

I've seen this happen more times than I care to count. Developers and entrepreneurs who are so convinced their idea is perfect that they skip the most important step—actually talking to the people who'll use their app. They build based on assumptions, gut feelings, or what they personally think would be useful. But here's the thing: you are not your user. Neither am I, for that matter.

User interviews aren't just a nice-to-have checkbox in your development process; they're the foundation of every successful app I've ever built. They tell you what problems people actually face, how they currently solve those problems, and whether your app idea has any chance of succeeding in the real world. Without this insight, you're basically gambling with your time and money.

The biggest risk isn't building the wrong thing badly—it's building the wrong thing really well

That's why getting user interviews right matters so much. Ask the wrong questions and you'll get polite responses that don't help. Ask leading questions and people will tell you what they think you want to hear. But ask the right questions in the right way? That's when you discover the genuine insights that can make or break your app. The good news is that conducting effective user interviews isn't rocket science—it just requires knowing what to ask and how to ask it.

Understanding Your Users Before You Build

You know what? I've seen countless app projects fail not because the code was rubbish or the design looked terrible—but because nobody bothered to understand who they were actually building for. It's a bit mad really, spending months developing something without knowing if people actually want it.

When clients come to me with their app ideas, they're usually buzzing with excitement about features and functionality. But here's the thing—your users don't care about your features. They care about their problems getting solved. That person struggling to book a table at their favourite restaurant doesn't want "an innovative dining platform with AI-powered recommendations." They just want to eat somewhere nice without spending twenty minutes on hold.

Why Most Apps Miss the Mark

The mobile app graveyard is full of beautifully designed apps that nobody uses. Why? Because their creators built what they thought people wanted, not what people actually needed. I mean, it sounds obvious when you put it like that, but you'd be surprised how often this happens.

Your potential users have routines, frustrations, and workarounds that you probably haven't even considered. They might be using a combination of three different apps to accomplish something that could be done with one—but only if you know what that something actually is.

Getting Inside Their Heads

Understanding your users isn't about sending out surveys asking "would you use an app that does X?" People are terrible at predicting their own behaviour, and they'll often tell you what they think you want to hear. Instead, you need to dig into how they currently handle the problems your app might solve. What do they do now when they encounter that frustration? How much time does it waste them? What emotions come up?

This isn't just nice-to-have research—it's the foundation that determines whether your app succeeds or joins the millions gathering digital dust in the app stores.

Preparing for Successful User Interviews

Right, let's talk about setting yourself up for success before you even start asking questions. I've seen too many people jump straight into user interviews without proper preparation—and honestly, it shows in the quality of insights they get back.

First things first: you need to be crystal clear about what you're trying to learn. Are you validating a problem exists? Testing whether your solution makes sense? Understanding how people currently handle a task? Write down your key assumptions and what evidence would prove or disprove them. This isn't just busywork; it'll keep you focused when the conversation starts flowing.

Finding the Right People to Interview

Here's where many people go wrong—they interview their friends, colleagues, or anyone who'll give them five minutes. But here's the thing: you need to speak to people who actually represent your target users. If you're building a fitness app for busy parents, don't interview your single, gym-obsessed mate who has three hours a day to work out.

Aim for 5-8 interviews per user segment. More than that and you'll start hearing the same things repeated; fewer and you might miss important patterns. I usually recruit through social media, relevant online communities, or even approach people in coffee shops if that's where my target users hang out.

Always offer a small incentive for people's time—even a £10 gift card shows you value their input and dramatically improves your response rate.

Create a simple screening questionnaire to make sure you're talking to the right people. Keep it short—3-4 questions max. You're just checking they fit your target demographic and have experience with the problem you're exploring.

Finally, book interviews close together if possible. When you're hearing responses back-to-back, patterns become much clearer than if you spread them out over weeks.

The Right Questions to Ask About Problems

Right, let's talk about the meat and potatoes of user interviews—understanding the actual problems your users face. This is where most people get it wrong, and I mean really wrong. They ask leading questions or jump straight to solutions without digging into the real pain points.

The biggest mistake I see? People ask "Would you use an app that does X?" That's useless. Absolutely useless. Instead, you need to understand what problems exist right now, today, in your users' lives. Start with something like "Tell me about the last time you tried to [relevant task]—what was that like?" This gets them talking about real experiences, not hypothetical scenarios.

Digging Deeper Into Pain Points

Once they start describing a situation, that's when you pounce. "How did that make you feel?" sounds a bit touchy-feely, but emotions drive behaviour more than logic ever will. If someone says "It was frustrating," ask them to describe that frustration. What specifically made it frustrating? Was it time? Complexity? Uncertainty?

Here's a question that works brilliantly: "If you had a magic wand and could fix one thing about [this process], what would it be?" People open up when you frame it this way. They stop thinking about technical limitations and just tell you what they really want.

Understanding Problem Frequency

Don't forget to understand how often these problems occur. "How many times has this happened to you?" or "When was the last time this was an issue?" A problem that happens once a year isn't worth solving compared to something that bugs people weekly. You're looking for problems that are frequent enough to matter but painful enough to drive someone to seek a solution.

The key is staying curious and resisting the urge to jump to solutions. Keep asking "why" until you get to the root of what's really bothering people.

Exploring Current Solutions and Workarounds

Here's where things get really interesting—and honestly, this is one of my favourite parts of user interviews. You need to understand what people are already doing to solve the problem your app might address. Because trust me, they're doing something. They always are.

Start with the obvious: "How do you currently handle this?" But don't stop there. Dig deeper. What tools are they using? What websites? Are they cobbling together three different apps to get the job done? I've seen users create the most elaborate workarounds—spreadsheets that should be apps, photo albums used as inventory systems, notes apps turned into project management tools. It's actually quite mad what people will do when the right solution doesn't exist.

Ask them about the last time they dealt with this problem. Walk through it step by step. "What did you do first? Then what happened? How long did that take?" This reveals the current user journey—all the friction points, the moments where they get frustrated, the bits that work well enough that they stick with them.

The best app ideas often come from understanding why people's current solutions are just good enough to tolerate, but not good enough to love

Here's something crucial though—pay attention to what they're not telling you. If someone says "Oh, I just use a simple spreadsheet and it works fine," but then describes spending 20 minutes every day updating it... that's not fine, is it? That's a pain point they've just accepted. Those accepted pain points? That's where apps succeed. They solve problems people didn't even realise were problems until a better way existed.

Understanding User Behaviour and Habits

People are creatures of habit, whether they admit it or not. I mean, we all have our routines—checking our phone first thing in the morning, scrolling through social media whilst having coffee, or using specific apps at certain times of the day. When you're building an app, understanding these habits is absolutely critical because your app needs to fit into peoples existing routines, not force them to create new ones.

The trick is asking questions that reveal how people actually behave, not how they think they behave. There's a massive difference between the two, trust me. Start with: "Walk me through your typical day" or "What's the first thing you do when you wake up?" These open-ended questions uncover natural behaviour patterns without leading them towards any particular answer.

Digging Into Daily Routines

Ask about frequency: "How often do you find yourself dealing with this problem?" or "When was the last time this happened to you?" These questions help you understand whether you're solving a daily frustration or something that happens once in a blue moon. If its the latter, you might want to reconsider your app idea—unless the problem is so painful that infrequent use is still worth solving.

Context matters too. Ask "Where are you usually when this happens?" and "What else are you doing at the same time?" You'll discover whether your app needs to work on the go, at home, or in specific environments. This affects everything from your design choices to technical requirements.

Here's what I've learned after years of user interviews: people's habits are sticky, but they're not unchangeable. The key is understanding which habits you can work with and which ones you'll need to gently reshape. Your app has the best chance of success when it slots naturally into existing behaviour patterns rather than fighting against them.

Testing Ideas Without Building Anything

Right, so you've got all this feedback about problems users are facing—but here's where most people make a costly mistake. They jump straight into building something without actually testing whether their solution makes sense. I mean, why spend months and thousands of pounds developing an app when you can test your core concept in a few days?

The trick is to present your idea in the simplest way possible and see how people react. You don't need fancy prototypes or working code at this stage. Sometimes a simple sketch on paper or a basic mockup is enough to get honest reactions.

Concept Testing Questions

Start with the big picture: "If there was an app that could [describe your solution], how useful would that be for you?" Don't oversell it—just describe what it does in plain terms. Then dig deeper with "What would you expect an app like this to do?" This reveals whether your idea matches what people actually want.

Never ask "Would you use this app?" because people always say yes to be polite. Instead ask "How often would you realistically use something like this?" or "What would stop you from using this regularly?"

One of my favourite questions is "What's missing from this idea?" People are brilliant at spotting gaps you've overlooked. Follow up with "What would make this a must-have rather than a nice-to-have for you?"

Priority and Value Testing

Here's where it gets interesting—ask them to choose. "If you could only have three features in this app, which three would be most important?" This forces people to prioritise, which is much more valuable than general enthusiasm.

• How much would you expect to pay for something like this?
• What similar apps do you currently use for this problem?
• Would you recommend this to a friend if it existed?
• What would convince you to download this over existing options?

The goal isn't to get validation—it's to uncover flaws in your thinking before they become expensive mistakes. If people struggle to explain the value or can't see themselves using it regularly, that's incredibly valuable information. Better to learn that now than after you've built the whole thing.

Questions That Reveal What Users Won't Say

Here's the thing about user interviews—people lie. Not intentionally, mind you, but they do it anyway. They tell you what they think you want to hear, or what makes them sound like the ideal user. After years of conducting these sessions, I've learned that the most valuable insights come from what people don't say directly.

The trick is asking questions that bypass their conscious filters and get to the real behaviour patterns. Instead of asking "Would you use this feature?" try "Walk me through the last time you dealt with this problem." The difference is massive. One gets you hypothetical fluff; the other reveals actual behaviour.

Questions That Uncover Hidden Truths

• "What's the most frustrating part of your current process that you just accept as normal?"
• "If you had to explain this to your mum, how would you describe the problem?"
• "What do you do when the usual solution doesn't work?"
• "Show me the last three times you tried to solve this—what actually happened?"
• "What would need to happen for you to completely change how you do this?"

Pay attention to hesitations, contradictions, and when they suddenly get animated about something. Those moments are gold. Someone might say they're "fine" with their current solution, but then spend five minutes complaining about specific pain points—that's your real data right there.

The best insights often come from edge cases too. Ask about their worst day, their busiest period, or when they're stressed. That's when people's true priorities surface. You know what? Sometimes the most honest answers come after you've officially "finished" the interview and people relax.

Making Sense of What You've Learned

Right, so you've done your user interviews and now you're sitting there with pages of notes, voice recordings, and probably a bit of analysis paralysis. I get it—this is where a lot of people get stuck. You've got all this brilliant feedback but making sense of it all? That's the tricky bit.

Start by looking for patterns, not individual opinions. If three different people mention the same frustration, that's data. If one person suggests a feature that nobody else cares about, file it away but dont make it your priority. I always tell my clients to focus on what people do, not just what they say they do. Someone might claim they check their banking app daily, but their usage patterns tell a different story.

Spotting the Real Problems

The best insights usually come from reading between the lines. When users say "it would be nice to have X feature," what they're really telling you is that their current solution isn't working. Dig deeper into those moments. What are they actually trying to accomplish? What's making it difficult?

The most valuable insights often come from what users struggle to articulate, not from their direct feature requests

Here's something I've learned after years of user research—people are terrible at predicting what they'll actually use. But they're brilliant at describing their current pain points. Focus on those problems, not their suggested solutions. Your job is to solve the underlying issue, which might look completely different from what they initially described.

Turning Insights into Action

Create a simple priority matrix. List the problems you've identified, how many people mentioned each one, and how painful it seems to be for them. The problems that affect lots of people AND cause genuine frustration? Those are your goldmine. Build your app around solving those core issues first.

After eight years of building apps and conducting hundreds of user interviews, I can tell you this—the questions you ask will make or break your entire project. Sure, you could skip this step and build based on assumptions, but honestly? That's like throwing money into a black hole and hoping something good comes out.

The questions we've covered aren't just nice-to-haves; they're your insurance policy against building something nobody wants. I've seen too many brilliant developers create technically perfect apps that solve problems nobody actually has. It's heartbreaking, really—all that talent and effort wasted because they didn't ask the right questions upfront.

But here's what I find exciting about user interviews: they often reveal opportunities you never saw coming. That throwaway comment about how someone currently handles a task? That could be your app's killer feature. The frustration they mention almost casually? That might be worth millions in market opportunity.

Remember, you're not trying to validate your idea during these interviews—you're trying to understand reality. Big difference. Users will lie to be polite, forget important details, and tell you what they think you want to hear. That's why the specific questions and techniques we've discussed are so important; they cut through the noise to get to the truth.

Your next step is simple: pick five potential users and start asking these questions. Don't overthink it. Don't wait for the perfect setup. Just start talking to people. The insights you gain will save you months of development time and potentially thousands in wasted effort. Trust me on this one—I wish someone had told me this years ago.