How Do You Research Users When Your App Doesn't Exist Yet?

Building an app when you don't know if anyone actually wants it is like throwing darts in the dark—you might hit something, but probably not what you're aiming for. I've watched countless startups burn through their entire budget building beautiful apps that nobody downloads, uses, or cares about. It's honestly heartbreaking when you see passionate founders pour everything into a product that misses the mark completely.

The thing is, most people think user research only happens after you've got something to show users. Wrong! Actually, some of the most valuable research happens before you write a single line of code or design your first screen. This is where early stage research and concept validation become absolutely crucial—and where most app projects either set themselves up for success or failure.

You know what? The best apps I've helped build started with months of pre-launch research, not months of development. We spent time understanding real problems, talking to potential users, and validating ideas before anyone touched Figma or opened Xcode. Sure, it feels like you're moving slowly at first, but you're actually moving in the right direction.

The biggest risk isn't building the wrong features—it's building the right features for the wrong people, or worse, building anything for people who don't actually exist.

This guide will show you exactly how to research users when your app is still just an idea bouncing around in your head. We'll cover everything from finding your future users to testing concepts that don't exist yet. Because honestly, spending time on startup UX research now could save you from rebuilding everything later—or worse, building nothing that matters at all.

Right, let's get this straight from the start—user research before building an app isn't about fancy surveys or focus groups in glass conference rooms. It's about understanding real people's actual problems before you spend months building something nobody wants.

I've watched countless entrepreneurs skip this step because they think their idea is so brilliant it doesn't need validation. Spoiler alert: it usually does. User research at this stage is detective work, not data collection. You're trying to figure out if the problem you think exists actually bothers people enough that they'd change their behaviour to solve it.

The Real Questions You Need Answers To

Before you write a single line of code, you need to know: Does this problem actually exist? How are people solving it right now? And here's the big one—are they frustrated enough with their current solution to try something new?

Most people think user research means asking "Would you use an app that does X?" But that's useless. People lie. They don't mean to, but they do. They'll tell you they'd definitely use your fitness app whilst eating a packet of crisps on their sofa.

What you're really looking for is evidence of the problem in people's current behaviour. Are they using weird workarounds? Complaining about existing solutions? Paying for something that doesn't quite fit their needs?

Starting With What You Can Observe

The best user research happens when people don't know they're being researched. Watch how they currently solve the problem you think you can fix. Look at the tools they use, the complaints they make online, the questions they ask in forums. That's your real user research—not what they say they want, but what they actually do when nobody's watching.

Finding Your Future Users Without an App Store

Right, so you want to find people who might use your app, but here's the thing—your app doesn't exist yet. No app store listing, no download button, nothing. It's a bit mad really, trying to research something that's just an idea in your head, but this is where the real work happens.

The trick is to stop thinking about finding "app users" and start thinking about finding people with problems. Your future users are out there right now, struggling with something, using workarounds, or just accepting that certain things are difficult. They might not even realise they need a solution yet.

Where Real People Hang Out Online

Social media groups are goldmines for this kind of research. Facebook groups, Reddit communities, LinkedIn groups—wherever people gather to complain, ask questions, or share experiences related to your problem space. I mean, people love to moan online, and that's exactly what you need to hear.

Forums are still alive and kicking too. Industry-specific forums, hobby communities, support groups. These places are where people have real conversations about real problems, not the polished stuff you see in marketing surveys.

• Facebook groups related to your target industry or problem area
• Reddit subreddits where your audience discusses challenges
• Professional forums and community sites
• Local meetup groups and networking events
• Customer support sections of existing competitor websites
• Review sites where people complain about current solutions

Look for the comments and replies, not just the main posts. That's where people reveal their real frustrations and workarounds.

The key is to lurk first, then engage. Don't jump in immediately trying to validate your idea—just observe what people are actually talking about, what keeps coming up repeatedly, and how they describe their problems in their own words.

Talking to Strangers About Problems They Might Not Know They Have

Right, this is where things get a bit tricky. You need to have conversations with complete strangers about problems they might not even realise they have. Sounds mental when you put it like that, doesn't it?

The thing is, most people are terrible at articulating their pain points. They'll tell you everything's fine when actually they're doing workarounds and manual processes every single day. I've lost count of how many times I've watched someone demonstrate their current solution and thought "bloody hell, there's got to be a better way to do this."

Start with open-ended questions about their daily routines instead of asking directly about problems. "Walk me through how you handle your morning emails" tells you so much more than "do you have email problems?" People will show you the real mess—the three different apps they use, the sticky notes everywhere, the manual copying and pasting between systems.

Getting People to Open Up

Here's what works: find them where they already gather. Online communities, LinkedIn groups, local meetups. Don't pitch your app idea; just ask genuine questions about their experiences. "I'm trying to understand how small business owners manage their inventory" gets better responses than "would you use my inventory app?"

Pay attention to the frustration in their voice when they describe certain tasks. That's where your app opportunity lives. The sighs, the "it's just how we've always done it" comments, the workarounds they've built—these are all signals pointing to problems worth solving.

And honestly? Most people quite like talking about their work challenges once you show genuine interest. They're not used to someone actually listening to understand rather than trying to sell them something.

Testing Ideas With Paper and Pixels

Right, so you've talked to people and you think you understand their problems. Now comes the fun part—testing your actual solution before you spend months building something nobody wants. I mean, that would be proper devastating, wouldn't it?

Paper prototypes are honestly one of the most underrated tools in early stage research. You literally sketch your app screens on paper and walk people through them. Its crude, sure, but that's the point. People focus on the concept rather than getting distracted by colours and fancy animations. I've watched potential users completely tear apart ideas in 20 minutes that would have taken months to build properly.

From Sketches to Clickable Mockups

Once your paper tests show promise, you can move to digital mockups using tools like Figma or even PowerPoint—honestly, PowerPoint works brilliantly for basic prototypes. The key is keeping things rough enough that people know its not finished, but detailed enough to test your core assumptions about user behaviour.

The biggest mistake I see founders make is falling in love with their solution before they've properly tested the problem it solves

What you're really testing here isn't whether people like your design; you're testing whether your solution actually matches how they think about their problem. Do they understand what your app does within the first few screens? Can they complete the main task without getting confused? These are the questions that matter for concept validation, not whether they prefer blue buttons or green ones.

Getting Honest Feedback

Here's the thing about testing prototypes—people will lie to you, but not on purpose. They'll say they love your idea because they want to be helpful. Watch their faces, their hesitation, the questions they ask. That's where the real insights live for your startup UX decisions.

Understanding What People Do vs What They Say

Here's something I've learned the hard way after years of building apps—people are terrible at telling you what they actually want. Not because they're lying, but because they genuinely don't know. It's a bit mad really, but we're all guilty of it.

Ask someone if they'd use a fitness app that tracks their daily steps and they'll probably say "absolutely, I need to get more active." But look at their phone and you'll see three unused fitness apps already downloaded. What people say they want and what they actually do are two completely different things.

This is why observation beats conversation every single time when you're researching users. Instead of asking "would you use an app that does X?" watch how they currently handle the problem you're trying to solve. Do they use spreadsheets? Sticky notes? Nothing at all?

Actions Speak Louder Than Surveys

I once worked on a food delivery app where users kept telling us they wanted healthier options. The surveys were crystal clear—everyone wanted salads and smoothies. But when we dug into the actual ordering data from competitor apps, pizza and burgers dominated. Every single time.

The lesson? People want to be the type of person who orders salads, but they actually order pizza. And that's completely normal! We're all aspirational in surveys and realistic in our behaviour.

• Watch what tools people currently use to solve their problems
• Look at their phone's home screen—what apps do they actually use daily?
• Ask about yesterday, not tomorrow ("What did you do when this happened yesterday?")
• Notice the workarounds they've created for existing solutions
• Pay attention to what they complain about, not what they claim to want

The key is becoming a detective of human behaviour rather than a surveyor of human opinions. Because behaviour doesn't lie, but our best intentions definitely do.

Building Your First Real Prototype for Research

Right, so you've done your interviews, sketched out your ideas, and now comes the fun bit—building something people can actually touch and play with. I'm not talking about a full app here (that would be bonkers at this stage), but something real enough that people can experience your core idea.

The prototype you build for early stage research doesn't need to be pretty. It just needs to work well enough to test your main assumptions. I usually recommend starting with what we call a "functional prototype"—something that lets users complete the key tasks you're designing for, even if half the buttons don't work yet.

Tools like Figma or InVision can create clickable prototypes that feel surprisingly real on a phone screen. But here's the thing—sometimes the simplest approach works best. I've seen brilliant concept validation happen with basic WordPress sites that simulate an app experience, or even clever combinations of existing tools that fake your core functionality.

What Your Research Prototype Needs

Your prototype should focus on testing specific assumptions about user behaviour. Can people understand what your app does within 10 seconds? Can they complete your main user flow without getting confused? These are the questions that matter for startup UX research.

• Core user journey from start to finish
• Real-ish content (not lorem ipsum)
• Mobile-friendly interface if it's a mobile app
• One or two key features working properly
• Clear calls to action

The goal isn't to impress people with fancy animations—it's to see if your idea actually makes sense when people try to use it. Keep it simple, make it testable, and prepare to learn things that might surprise you.

Build your prototype with real content from day one. Lorem ipsum text and placeholder images won't tell you if people understand what your app actually does or whether your value proposition makes sense to them.

When Your Research Tells You to Change Everything

Right, let's talk about the elephant in the room. Sometimes your research comes back and basically tells you that your brilliant app idea is... well, not so brilliant after all. I've been there more times than I care to admit, and honestly? It never gets easier to hear.

But here's the thing—this is actually the best possible outcome. I know it doesn't feel like it when you've spent weeks getting excited about your concept, but finding out your idea needs major changes during research is infinitely better than discovering it after you've built the whole bloody thing.

I remember working with a client who was convinced they needed a complex fitness tracking app with social features. Three weeks of user interviews later, we discovered people just wanted a simple way to log their water intake. Complete 180-degree turn from the original idea, but the final app was much more successful because of it.

Common Research Revelations That Change Everything

There are certain patterns I see again and again when research forces major pivots:

• Your target users aren't who you thought they were
• The problem you're solving isn't the real problem
• People already have a solution they're happy with
• Your proposed solution is too complex for the actual need
• The timing isn't right for your idea

The key is not to see this as failure—it's success disguised as disappointment. You've just saved yourself months of development time and thousands of pounds by learning what won't work. Now you can pivot towards something that will actually resonate with real people.

Sure, it means going back to the drawing board. But armed with proper research, your second attempt is going to be so much stronger than your first.

Turning Research Into Features That Matter

Right, so you've done all this research—you've talked to potential users, tested prototypes, and gathered feedback. Now comes the tricky bit: deciding what to actually build. This is where I see loads of founders go wrong; they try to solve every problem they've discovered instead of focusing on the ones that really matter.

The secret is learning to prioritise ruthlessly. I usually tell my clients to make a simple list of all the problems their research uncovered, then rank them by two things: how often people mentioned it and how frustrated they seemed when talking about it. The features that address frequent, painful problems? Those go to the top of your list. Everything else can wait.

Start Small, Think Big

Your first version doesn't need to be perfect—it needs to be useful. I've seen too many apps fail because they tried to do everything from day one. Pick the top three problems from your research and build features that solve those specific issues really well. The rest can come later.

The biggest mistake we see is founders building features for edge cases instead of focusing on what 80% of users actually need every day

Here's something that might help: for each feature you're considering, ask yourself "would someone pay for this app if it only did this one thing?" If the answer is no, you probably shouldn't build it yet. Your early users will tell you what they need next—and they'll be much more specific once they're actually using your app rather than just talking about hypothetical problems.

Remember, your research isn't a to-do list. It's a compass. Use it to point you in the right direction, but don't feel obligated to implement every single insight you gathered.

Conclusion

User research before building an app isn't some mystical art form that requires years of training—it's basically detective work mixed with a healthy dose of curiosity. You're trying to solve a puzzle where the pieces are scattered across conversations, observations, and those little moments when people mutter "there has to be a better way to do this."

The truth is, most app failures aren't because of bad code or ugly designs. They fail because someone built something nobody actually wanted; they just thought they did. By talking to real people, watching how they behave, and testing your ideas before you write a single line of code, you're already ahead of about 80% of app projects out there.

Sure, some of your assumptions will be wrong. That prototype you thought was brilliant? People might look at it like you've handed them a calculator and asked them to make a phone call. But that's exactly the point—better to find out when you can still change direction without losing months of development time.

The research process I've outlined isn't just about reducing risk (though it does that). Its about building confidence in your decisions. When you launch your app, you won't be crossing your fingers and hoping people get it. You'll know they get it because you've already watched them use it, heard them talk about the problem it solves, and seen their faces light up when they realise how much easier their lives just became.

That's worth more than any amount of clever marketing or flashy features. Start with people, not pixels.