How Do I Research What Features Users Actually Want?

A major travel booking platform spent eighteen months and £2.3 million building what they thought was the perfect mobile app. They packed it with features like 360-degree hotel room previews, AI-powered weather forecasts for destinations, and an elaborate social sharing system. When it launched, users ignored most of these bells and whistles—they just wanted to quickly compare prices and book flights without the app crashing. The company had built what sounded good in boardroom meetings, not what travellers actually needed when they were frantically trying to book a last-minute trip at the airport.

This is the problem with feature research in mobile app development. Everyone thinks they know what users want, but the reality is often completely different. I've seen it happen countless times over my years in this industry—teams get excited about flashy features without actually talking to the people who'll use their app. The result? Apps that nobody wants to use, no matter how technically impressive they might be.

Here's the thing about users: they're brilliant at telling you when something's wrong, but they're terrible at predicting what they'll actually want before they see it. That's why proper feature research isn't about asking people what they want (they'll usually say "everything") but about understanding their real problems and frustrations.

The most successful apps aren't built by guessing what users might want—they're built by obsessively understanding what users actually do and why they struggle to do it

Feature research is basically detective work. You're looking for clues about user behaviour, pain points, and unspoken needs. Its about finding the gap between what people say they want and what they actually need when they're using your app in the real world.

Understanding Your Users Before You Build

I see it all the time—someone gets an app idea and immediately starts thinking about features, design, and tech stacks. But here's what I've learned after building hundreds of apps: you can't create something people want if you don't understand who those people are. And I mean really understand them, not just guess based on your own assumptions.

The biggest mistake I see clients make? They assume their users think exactly like they do. A fintech startup founder might love detailed analytics and complex charts, but their actual users just want to know if they can afford that coffee without checking their balance. Its that simple disconnect that kills so many potentially great apps.

Before you write a single line of code or sketch your first wireframe, you need to get inside your users heads. What are they actually doing when they encounter the problem your app solves? Where are they? What device are they using? Are they stressed, bored, or focused? These details matter more than you might think.

Who Are Your Real Users?

Start by defining your user groups properly. Don't just say "busy professionals"—that tells you nothing useful. Instead, think about specific types of people with specific needs. A project manager juggling deadlines has different app requirements than a consultant travelling between client sites, even though both might be "busy professionals."

Here are the key user characteristics you need to identify before building anything:

• Age range and tech comfort level
• When and where they'd use your app
• What other apps they already use daily
• Their biggest frustrations with current solutions
• How much time they're willing to spend learning something new

Once you've got these basics sorted, you can start researching what features would actually solve their problems rather than just adding bells and whistles that sound clever but don't help anyone.

Methods for Direct User Feedback

Getting direct feedback from users is like having a conversation with the people who'll actually use your app. I mean, they're the ones who matter most, right? Over the years I've found that the most successful apps come from teams who regularly chat with their users—not just at the beginning, but throughout the entire development process.

The trick is making it easy for people to share their thoughts. In-app feedback tools work brilliantly for this; users can report issues or suggest features without leaving your app. Simple rating prompts after key actions can tell you loads about which features people love and which ones... well, which ones they dont. But here's the thing—timing matters. Ask for feedback right after someone completes a task, when the experience is fresh in their mind.

One-on-One User Interviews

Nothing beats sitting down with actual users and asking them direct questions. I always recommend doing these interviews regularly, not just once. User needs change, and what people wanted six months ago might be completely different now. Ask open-ended questions like "What frustrates you most about this process?" rather than leading questions that push people towards specific answers.

Beta testing groups are another goldmine for direct feedback. These are your most engaged users—they've volunteered their time to help improve your app. Create a simple way for beta testers to share thoughts, whether thats through a dedicated Slack channel, email, or even a basic feedback form.

Set up a simple feedback widget that appears after users complete key actions in your app. You'll get responses when the experience is still fresh in their minds, leading to more honest and detailed insights.

Analysing Competitor Apps and Features

Right, let's talk about something I do religiously before starting any project—stalking the competition. And I mean properly analysing what they're doing, not just downloading their app and having a quick scroll through it whilst watching telly.

Here's the thing about competitor analysis: most people get it completely wrong. They focus on what features competitors have rather than understanding why those features exist and how well they actually work for users. I've seen clients come to me saying "we need exactly what they have but better" without understanding whether "what they have" is even working.

What to Look for Beyond the Obvious

When I'm dissecting competitor apps, I'm not just looking at their main features—I'm paying attention to their onboarding flow, how they handle error states, what their empty screens look like, and crucially, how they're trying to keep users engaged. The devil really is in the details here.

Check their app store reviews religiously. Users are brutally honest about what's broken, what's missing, and what they actually want. It's like having thousands of people do user research for you, completely free. Sort by most recent reviews to see current pain points—these are your opportunities.

Tools and Methods That Actually Work

Here's my go-to process for competitor analysis:

• Download their app and use it properly for at least a week
• Screenshot every single screen and flow
• Read their recent app store reviews (both 1-star and 5-star)
• Check their social media for user complaints and feature requests
• Look at their app store screenshots to see what they're highlighting as key features
• Monitor their app updates to see what they're prioritising

But here's what most people miss: don't just analyse direct competitors. Look at apps in completely different industries that serve similar user needs. Some of the best feature ideas I've implemented came from observing how banking apps handle security flows or how gaming apps create engaging onboarding experiences.

Using Analytics to Spot Feature Gaps

Right, so you've got your app out there in the wild and people are actually using it—brilliant! But here's where things get really interesting. Your analytics data isn't just telling you how many people downloaded your app or where they're dropping off. It's basically a goldmine for spotting exactly what features your users are crying out for, even when they haven't directly told you.

I mean, users vote with their fingers, don't they? When I dig into analytics for client apps, I'm looking for the weird stuff first. Where are people spending way more time than expected? What buttons are they tapping that don't actually do anything yet? These are your feature gaps staring you right in the face.

Reading Between the Data Lines

Heat maps are absolutely gold for this kind of detective work. I've seen users frantically tapping on images thinking they should open something, or trying to swipe on elements that aren't swipeable. That's not user error—that's your app telling you what it wants to become next.

The most valuable insights come from watching what users try to do, not just what they actually accomplish

User flow data tells you another story entirely. If people are taking bizarre, roundabout paths to complete simple tasks, you're probably missing a shortcut feature. Or if they're constantly jumping between two specific screens, maybe those functions should live closer together. It's like watching someone walk across your house—if they keep taking the same weird route, maybe you need to move some furniture around, you know?

Spotting the Patterns That Matter

Session recordings are where the real magic happens though. Watching actual users navigate your app is both fascinating and slightly terrifying! You'll spot feature gaps you never even considered, and honestly, some of the solutions will seem dead obvious once you see them in action.

Testing Ideas with Prototypes and Wireframes

Right, so you've got some ideas about what features users might want. That's brilliant—but here's the thing, ideas on paper and ideas in practice can be completely different beasts. This is where prototyping comes in, and honestly, it's one of the most valuable steps that gets skipped way too often.

I've seen clients spend months building features that seemed perfect in their heads, only to watch users completely ignore them or—worse—get confused by them. A simple prototype could have saved them thousands of pounds and weeks of development time. It's a bit mad really, but we often get so attached to our ideas that we forget to check if they actually make sense to real people.

Wireframes are your starting point. Think of them as the skeleton of your app—no fancy colours or graphics, just the basic structure and flow. You can sketch these on paper or use tools like Figma or Sketch. The key is to map out how users will move through your app and where each feature lives. Don't worry about making them pretty; that comes later.

Prototyping Tools That Actually Work

Once you've got your wireframes sorted, it's time to create interactive prototypes. These let users tap through your app idea without writing a single line of code. Here are the tools I recommend to my clients:

• Figma - Free and perfect for beginners, works in your browser
• InVision - Great for adding clickable hotspots to static designs
• Marvel - Simple drag-and-drop interface, good for quick tests
• Adobe XD - More advanced features if you're comfortable with Adobe products
• Principle - Excellent for testing animations and micro-interactions

The magic happens when you put these prototypes in front of real users. Watch them navigate through your app flow—where do they get stuck? What confuses them? What feels natural? You'll be surprised how quickly you spot problems that weren't obvious on paper. And fixing them now costs pennies compared to fixing them after development.

Social Media and Community Research

Right, let's talk about one of my favourite ways to understand what users actually want—social media and community research. I mean, where else can you find people complaining, praising, and discussing apps with complete honesty? It's like having access to thousands of focus groups that are already happening without you having to pay for them.

The thing is, people are constantly sharing their frustrations and wishes about apps on Twitter, Reddit, Facebook groups, and specialist forums. They're not being polite or trying to spare your feelings like they might in a formal survey. They're just... real. And that's exactly what you need for proper feature research.

Where to Look for User Conversations

Start with the obvious places—Twitter searches using your app's name or your competitors names. But don't stop there. Reddit is absolutely brilliant for this kind of research because people really get into detailed discussions about what they love and hate about different apps. LinkedIn groups in your industry can be goldmines too, especially for B2B apps.

Here's what I typically look for when I'm doing this kind of research:

• Common complaints that appear across multiple platforms
• Feature requests that users are actively asking for
• Workarounds people have created because existing apps don't meet their needs
• Conversations about switching between apps and why
• Reviews and comments on app store listings

Set up Google Alerts for your app name and your main competitors. You'll get notified whenever they're mentioned online, which means you won't miss important conversations about user preferences and feature gaps.

The best part about social media research? It's completely free, and you get to see what people really think when they don't know you're listening. Just remember to take notes and look for patterns—one person complaining might be an outlier, but ten people asking for the same feature? That's worth investigating.

Surveys and Interviews That Actually Work

Right, let's talk about surveys and interviews—because honestly, most of the ones I see are absolutely rubbish. People send out these massive 20-question surveys asking things like "Would you use an app that makes your life better?" Of course they bloody would! That tells you nothing useful.

The trick with surveys is keeping them short and asking about specific behaviours, not hypothetical situations. Instead of "Would you pay for premium features?" ask "How much did you spend on apps last month?" People lie about future intentions but they're pretty honest about what they've actually done. I usually stick to 5-7 questions max—any more and people start clicking random answers just to finish.

Questions That Actually Get Results

Here's what works: ask about their current process, not your brilliant idea. "How do you currently track your expenses?" gives you real insight into their pain points. Then follow up with "What's the most frustrating part of that process?" Now you're getting somewhere useful.

For interviews, I've learned to shut up and listen. Seriously. Ask one good question then let them talk. The best insights come from those rambling tangents where people complain about stuff they didn't even know was bothering them.

• Keep surveys under 5 minutes
• Ask about current behaviour, not future intentions
• Use specific scenarios instead of general questions
• In interviews, ask "why" at least three times
• Record everything (with permission) because you'll miss important details

The golden rule? If someone gives you a one-word answer, your question was probably pants. Good questions make people think and share stories. That's where the real feature ideas live.

Turning Research into Actionable Features

Right, so you've done all this research—you've interviewed users, analysed competitors, run surveys, and tested prototypes. You're sitting there with pages of notes, feedback forms, and analytics data. Now what? This is where many app projects hit a wall because turning research into actual features is harder than it looks.

First thing I do is create what I call a "feature value matrix." Sounds fancy, but it's basically a simple grid where I plot every potential feature against two things: how much users actually want it (based on your research) and how difficult it'll be to build. The sweet spot? High demand, low complexity. Those are your quick wins.

Prioritising Based on Real Impact

Here's where experience matters—users will often ask for features they think they want, but won't actually use. I had a client whose users kept requesting a complex calendar integration. The research showed 80% wanted it. But when we dug deeper into their actual behaviour patterns, most users only needed simple date reminders. We built that instead and saved months of development time.

The best features solve problems users have, not problems they think they have

Building Your Feature Roadmap

Once you've identified your priority features, map them across three releases: core features for launch, nice-to-haves for version two, and future possibilities for version three. Your core features should address the primary user need that sparked your app idea in the first place. Everything else can wait—seriously.

Don't try to build everything at once. I've seen too many apps fail because they tried to be everything to everyone from day one. Start small, nail the basics, then expand based on how users actually behave with your app in the wild.

So there you have it—everything I've learned about researching user needs over years of building apps that people actually want to use. It's not rocket science, but it does require patience and a genuine willingness to listen. Most app failures I've seen happen because someone skipped these steps, not because the technology wasn't good enough.

The thing is, users often can't tell you exactly what they want. They might say they want more features when what they really need is for the existing ones to work better. They'll ask for complicated solutions to simple problems. That's why combining different research methods—direct feedback, competitor analysis, analytics, prototyping—gives you a much clearer picture than relying on just one approach.

I've watched too many brilliant developers build apps based on their own assumptions, then wonder why downloads stay flat. Your users aren't you. They don't think like you, they don't use technology the way you do, and they definitely don't have your technical knowledge. That's not a bad thing—it's just reality.

Start small with your research. Pick two or three methods that feel manageable for your current situation. A few user interviews and some competitor analysis will take you much further than building features based on guesswork. Remember, every hour you spend understanding your users before you build saves you weeks of rebuilding later.

The mobile app world moves fast, but good research principles don't change. Listen to your users, watch what they actually do (not just what they say), and test your ideas before committing serious development time. Do that consistently, and you'll build apps people genuinely want to keep on their phones.