How Can I Find Out What Users Expect in My App Category?

Building an app without understanding what users expect is like launching a restaurant without checking what food people actually want to eat. You might think you're creating something brilliant, but if it doesnt match what people need in that specific category, you're going to struggle. I've seen this happen more times than I care to count—brilliant developers building beautiful apps that nobody downloads because they missed the mark on basic user expectations. The problem is that expectations change dramatically depending on what kind of app you're making; what works for a fitness app will fall flat for a banking app, and vice versa.

Here's the thing—most people skip this research phase completely. They jump straight into design and development because its more exciting than talking to potential users or analysing competitor apps. But this is where the real work happens. When we built a healthcare booking app a few years back, we spent three weeks just interviewing patients and reception staff before touching any design tools. What we discovered completely changed our approach; users expected instant confirmation (not a callback), they wanted to see doctor photos and qualifications upfront, and they needed a stupid-simple cancellation process. None of these insights came from our own assumptions—they came from actually listening.

Understanding user expectations isn't about guessing what people want, its about systematically uncovering what they already assume your app will do based on their experiences with similar apps.

The categories you're competing in have already set certain standards whether you like it or not. Food delivery apps need real-time tracking. Banking apps need biometric login. E-commerce apps need guest checkout options. These aren't nice-to-haves anymore—they're table stakes. Miss one of these expected features and users will assume your app is outdated or unprofessional, even if everything else is perfect. The good news? Finding out what these expectations are isnt actually that difficult once you know where to look and what questions to ask.

Why Every App Category Has Its Own Rules

Here's something that catches people off guard—what works brilliantly in a fitness app will absolutely tank in a banking app. I mean, its not obvious until you think about it, but each app category comes with its own set of unwritten rules that users expect you to follow. Break these rules and people will abandon your app faster than you can say "user retention".

Take healthcare apps for example. When we built a patient management system, we discovered users expected completely different things than they did from the e-commerce apps we'd made previously. In healthcare, people want reassurance at every step; they need to see confirmation that their appointment was booked, that their data was saved, that their message was sent. Whereas in e-commerce? Users are happy with minimal friction—they just want to buy something quickly and move on with their lives. The psychology is totally different.

What Users Demand From Different Categories

Financial apps come with their own baggage too. Users expect face ID or fingerprint login as standard now, not as a nice-to-have feature. They want to see their balance immediately when they open the app—no splash screens, no marketing messages, just the number they came to check. We learned this the hard way when a fintech client insisted on a beautiful animated intro sequence... users hated it. Bloody hell, the complaints came flooding in within days.

Social apps need endless scrolling and instant notifications. Gaming apps need quick loading times and clear progression systems. Productivity apps? People expect offline functionality because they're often using them on the tube or in places with dodgy signal. Education apps need progress tracking and achievement systems—without that sense of advancement, users just drift away.

Category Rules You Can't Ignore

The tricky bit is that these expectations evolve constantly. What worked in food delivery apps three years ago feels outdated now because competitors have raised the bar. Users now expect real-time driver tracking, accurate ETAs, and the ability to modify orders after placing them. If your app doesn't have these features, you're already behind before you've even launched. And here's the thing—users won't tell you what category rules you've broken, they'll just delete your app and download a competitors instead. Understanding how to position your app when you're not first in the market becomes crucial when these expectations have already been set.

The Real Numbers Behind App Performance in Different Industries

Here's something I wish more clients understood before we start building their app—the performance numbers that work brilliantly in one industry can be absolutely terrible in another. I mean, if you're launching a fitness app and your day-one retention sits at 40%, that's actually pretty decent; but if you've built a banking app and only 40% of users come back the next day, somethings gone very wrong.

Let me give you some real benchmarks from projects I've worked on over the years. E-commerce apps typically see conversion rates between 1.5-3%, which sounds low until you compare it to mobile web at around 0.5-1%. The average session length for shopping apps tends to hover around 4-7 minutes—users browse quickly, they make decisions fast, and they expect checkout to take under 90 seconds. We learned this the hard way on a retail project where our initial checkout flow took 3 minutes on average and we saw a massive 68% cart abandonment rate. Once we stripped it down to four screens maximum, that dropped to 34%.

Session Length Matters More Than You Think

Finance apps are completely different beasts altogether. Users open them frequently (averaging 10-15 times per month) but sessions are super short—usually under 2 minutes. They're checking balances, transferring money, paying bills. That's it really. One fintech client wanted to add all these educational features and gamification elements but the data showed users just wanted to get in, complete their task, and get out. When building features like loan calculator integration, we kept the fancy stuff minimal and focused on delivering quick, accurate results.

Healthcare apps fall somewhere in between depending on their purpose. Telemedicine apps see longer sessions (15-20 minutes for consultations obviously) but meditation or habit-tracking apps perform best with very short, daily interactions of just 5-10 minutes. I worked on a mental health app where we initially designed for longer therapeutic sessions but users actually preferred quick check-ins they could do consistently rather than lengthy sessions they'd skip.

The Load Time Reality Check

Across every single industry I've worked in, one number remains brutally consistent—if your app takes longer than 3 seconds to load its initial screen, you'll lose roughly 25% of users before they even see your content. We've measured this across healthcare, retail, education, entertainment... it doesn't matter what you're building, that 3-second threshold is real. And on poor network connections? You've got maybe 5 seconds before people give up entirely.

Track your industry-specific benchmarks from day one—things like session length, feature usage frequency, and task completion rates. Generic analytics wont tell you if you're actually performing well for your category; you need to compare against apps doing similar things to understand whether your numbers are good, average, or need serious improvement.

Gaming apps have completely different metrics altogether. Session lengths can range from 3 minutes for casual puzzle games to 45+ minutes for strategy or RPG titles. But here's what's interesting—the most successful casual games I've seen optimised for that 7-12 minute sweet spot, which is exactly how long the average commute lasts. The retention numbers tell the story too; day-seven retention above 20% is considered excellent for games, whereas for a productivity app that would be worryingly low.

Social media and content apps need to hit different targets entirely. Average session lengths of 20-30 minutes are normal here, with users checking in multiple times per day. The apps that perform best create these habit loops where users open them almost unconsciously throughout their day. One media app we built struggled initially because sessions were only averaging 4 minutes—we hadn't given users enough reasons to stick around and explore, so we added better content recommendations and saw that number climb to 18 minutes within two months.

Watching What Your Competitors Do (Without Copying Them)

I spend a lot of time looking at other people's apps—its part of the job really—and you'd be surprised how much you can learn just by paying attention to what your competitors are doing. Not to copy them, mind you, but to understand what's become table stakes in your category and where there might be gaps you can fill. When I built a fitness tracking app a few years back, we downloaded every single competitor app we could find; we logged workouts in them, tried their onboarding flows, tested their social features. The goal wasn't to replicate what they'd done but to figure out what users had been trained to expect and where we could do something different.

Here's the thing though—there's a fine line between competitive research and just building a clone of someone else's product. I've seen plenty of apps fail because they tried to be "Uber but for X" or "Instagram but for Y" without bringing anything new to the table. Users can smell a copycat from a mile away and they'll stick with the original every time. What you're really looking for when you analyse competitors is patterns; what features show up in every single app in your category? Those are probably non-negotiable expectations. What features only appear in some apps? Those might be opportunities to differentiate. Knowing how to make your app worth talking about online often starts with understanding what competitors aren't doing well.

What to Actually Look For

When I do competitor analysis for clients, I focus on specific things that matter. Navigation patterns—are most apps using bottom tabs or hamburger menus? Onboarding length—do they ask for information upfront or let you explore first? Core features—what can you do without paying? Monetisation—are they using subscriptions, one-time purchases, or freemium models? And most importantly, user reviews. Reading through one-star reviews of your competitors is like getting free user research; people will tell you exactly what frustrates them and what's missing. This research also helps inform your keyword selection strategy when you see what terms users actually use to describe problems and solutions.

Building Your Competitive Analysis

I usually create a simple spreadsheet when doing this work. List your top 5-10 competitors down the left side and key features across the top, then fill in what each app offers. You'll start to see patterns emerge really quickly...maybe everyone offers push notifications but only two apps have dark mode, or perhaps there's a feature you thought was standard that actually only one competitor provides. This visual comparison helps you make informed decisions about what to include in your MVP and what can wait for later versions. And honestly? Sometimes you'll discover that the thing you thought made your app unique is already being done by three other apps, which means you need to go back to the drawing board.

Actually Talking to Your Users Before You Build Anything

Here's something that still baffles me after all these years—clients will spend thousands on development but won't invest a few hundred quid in actually talking to the people who'll use their app. I mean, would you build a restaurant without asking anyone what food they like? It's a bit mad really, but it happens constantly in this industry.

The best projects I've worked on always started with proper user interviews. Not surveys. Not focus groups with free sandwiches. Actual one-on-one conversations where you shut up and listen. When we built a healthcare booking app, we sat down with about fifteen potential users and just watched them try to book appointments on existing apps. The insights were gold—turns out people weren't confused about the interface, they were terrified about sharing medical information over their phone. That's not something a survey would've caught.

The mistakes users make tell you more about what they expect than anything they say in a survey.

Start with about ten to fifteen interviews if you can manage it. Any less and you're just guessing; any more and you'll start hearing the same things repeated. Ask them to show you how they currently solve the problem your app addresses—even if its a clunky workaround. Watch where they get frustrated. Take notes on the exact words they use because that's your marketing copy right there. And here's the thing most people get wrong: don't ask "would you use this feature?" because everyone says yes to hypotheticals. Ask them to show you the last time they needed something similar and what they actually did about it. While you're gathering this feedback, you can also start building an email list of interested users who want to be notified when your app launches.

Testing Your Ideas Against What People Really Need

The gap between what you think users want and what they actually need can be bloody expensive to discover after you've already built the thing. I've seen startups burn through their entire budget building features nobody asked for, and its always painful to watch. The good news? You can test your ideas before writing a single line of code—and honestly, you should.

Prototyping is your best friend here. I'm not talking about fancy high-fidelity designs; I mean simple clickable mockups that show the core flow of your app. Tools like Figma or even basic sketches on paper can work. The point is to put something in front of real people and watch them try to use it. When I was working on a healthcare booking app, we tested five different appointment scheduling flows with actual patients. The one we thought was most "elegant" confused everyone—turns out people just wanted to see available times immediately, not scroll through multiple screens. We learned that in a week of testing rather than three months of development. This kind of early testing is particularly important when you're working with specialised user groups—for instance, designing apps for construction workers requires understanding their specific workflow constraints and environmental challenges.

Ways to Test Before Building

• Create clickable prototypes and run 5-10 user tests with your target audience; you'll spot major problems quickly
• Build a landing page describing your app and measure actual sign-up interest—if you can't get 100 email addresses, you might have a problem
• Use beta testing groups on platforms like TestFlight (iOS) or Google Play's internal testing; real usage data beats assumptions every time
• Run small paid ad campaigns to test different value propositions; see which messages actually get people to click
• Join relevant online communities and ask direct questions about pain points—but don't just pitch your idea, listen to what people are struggling with

What to Look For in Testing

Pay attention to where people get stuck, not where they say they get stuck. I mean, users will tell you one thing in interviews but do something completely different when you watch them use your prototype. For a fintech app we built, people said they wanted detailed transaction categorisation... but in testing, they never used it. What they actually used was the simple overview screen showing their balance. That insight saved us months of building complex features that would've sat unused.

The other thing? Test with people who don't already love your idea. Your mum's feedback is lovely but probably not representative of your actual market. Find skeptics. Find people who currently use competitor apps. Find people who've never heard of you—their fresh perspective is gold.

The Features Users Expect Depending on Your App Type

After building apps across dozens of different categories, I've noticed something interesting—users don't judge all apps by the same standards. What works brilliantly in a fitness app would feel completely wrong in a banking app, and the features people consider "must-haves" change dramatically depending on what they're trying to accomplish. Its not just about having good features; it's about having the right features for your specific app category.

For fintech apps, security features aren't optional—they're the baseline. Biometric login, transaction notifications, spending breakdowns and the ability to freeze cards instantly have become standard expectations. I've worked on banking apps where users actually complained when we didn't include Face ID on the first screen, even though they had to enter a PIN anyway. They wanted that visible reassurance. But here's what surprised me: fintech users also expect really smart categorisation of their spending without having to manually tag everything, which means your backend needs to be doing some heavy lifting with transaction data.

E-commerce apps need completely different features. Saved payment methods, one-tap reordering, proper product filtering and sorting, plus a wishlist that actually syncs across devices. The big one though? Visual search. Users now expect to snap a photo of something they like and find similar products in your app. When we added this to a fashion retail app, it became the third most-used feature within weeks, which honestly caught everyone off guard. For business expense apps, features like receipt scanning functionality have become essential rather than nice-to-have additions.

Health and fitness apps live or die by their tracking capabilities and integration with Apple Health or Google Fit. Users want automated tracking where possible—nobody wants to manually log every workout or meal unless they're really committed. Progress visualisation matters too; people need to see their improvements over time or they lose interest fast. One health app we built had brilliant functionality but terrible progress charts, and the retention numbers showed it clearly.

What Users Actually Expect by Category

The Features That Cross All Categories

Some features have become universal expectations regardless of your app type. Dark mode isn't a luxury anymore—users genuinely get annoyed when its missing, especially if they use your app at night. Proper search functionality matters more than most developers think; I've seen apps with hundreds of features that users couldn't find because the search was rubbish. And please, make your app work offline in some capacity. Even if it's just viewing previously loaded content, users expect to open your app and see something useful without an internet connection.

Onboarding is another area where expectations have shifted massively. Users don't want lengthy tutorials anymore—they want to get value immediately and learn as they go. We tested two versions of an e-learning app: one with a detailed five-screen tutorial, another with contextual tips that appeared when users encountered new features. The second version had 47% better completion rates for the first lesson, which translated directly to better long-term retention. Understanding how progress bars manipulate user behaviour during setup can make a significant difference to completion rates.

Push notifications need to be intelligent and customisable. Users expect granular control over what notifications they receive and when. A shopping app sending promotions at 3am will get uninstalled fast, but that same app sending a notification that a wishlisted item just went on sale? That's genuinely useful. The difference is understanding context and timing, not just blasting notifications and hoping something sticks.

Look at the top three apps in your category and make a spreadsheet of every feature they offer. Then categorise them into "present in all three", "present in two" and "present in one". The features present in all three are your baseline—users will absolutely expect them in your app too. The ones present in two are worth considering seriously, and the ones only in one might be differentiators you can use or ignore depending on your strategy.

One mistake I see constantly is developers assuming their app is unique and doesn't need standard category features. A meditation app client once told me they didn't need a timer because their approach was "about the journey, not the duration". Right... except every competitor had timers, and users kept requesting it in reviews. We added it three months after launch and the rating jumped from 3.8 to 4.4 stars. Sometimes the standard features exist for good reasons. You need to balance innovation with meeting basic expectations—it's often better to avoid looking outdated by missing expected features than to be revolutionary but confusing.

Video streaming apps have perhaps the highest feature expectations of any category. Users want downloads for offline viewing, continue watching across devices, multiple profiles, parental controls, quality settings and subtitle customisation at minimum. When we built a streaming platform for educational content, the client wanted to save money by skipping the multi-device sync feature. Big mistake. Users would start watching on their phone during commute, then want to continue on their tablet at home. Without that sync, they had to manually find their place again, and loads of them just gave up. We added it in phase two, but we'd already lost users who might never come back.

Gaming apps need responsive controls, progress saving, achievements and some form of social competition or sharing. Free games need to balance monetisation carefully—users expect in-app purchases or ads, but they'll abandon your game instantly if it feels too aggressive. I worked on a puzzle game where we tested different ad frequencies: every three levels, every five levels, and only between sessions. The five-level frequency performed best for both retention and revenue, which shows you cant just guess at this stuff.

The real skill is knowing which features to build first. You cant launch with everything, so you need to prioritise ruthlessly based on what users absolutely expect versus what would be nice to have. For a food delivery app, real-time tracking is non-negotiable but group ordering can wait. For a productivity app, cloud sync needs to work perfectly from day one, but advanced automation features can come in version two once you've validated the core concept. When working with teams, getting everyone to agree on feature priorities becomes crucial for maintaining focus and meeting user expectations.

Measuring Whether You're Meeting User Expectations

Here's what I've learned after shipping dozens of apps—launch day is actually when the real work begins. You can't just release your app and hope for the best; you need to know if people are getting what they expected. And honestly, the data doesn't lie. I always tell clients that metrics are like a health check for your app, they tell you exactly where things are going wrong before users start leaving bad reviews.

The first metric I look at is retention rate—how many people come back after day one, day seven, and day thirty. If your day-one retention is below 25%, something went wrong immediately after install. Users opened your app, didn't find what they expected, and left. I've seen this happen with a fitness app we built where the onboarding took too long; people wanted to start exercising but had to answer fifteen questions first. We cut it down to three questions and retention jumped to 42%.

The Metrics That Actually Matter

Session length tells you if people are finding value or just poking around confused. For a banking app we worked on, sessions were averaging under thirty seconds—turns out the login process was so frustrating people gave up. Once we added biometric authentication, average session length tripled because users could actually get to their account information. App Store reviews and ratings are obvious but often ignored until its too late; I check them weekly at minimum. Pay attention to what people complain about most frequently, thats your roadmap for what expectations you're not meeting. This ongoing monitoring is part of understanding how to measure progress after launch, not just during development.

Setting Up Your Measurement System

You need analytics from day one—I use a combination of tools depending on the project but at minimum you want crash reporting, user flow tracking, and event tracking for key actions. For an e-commerce app, we tracked how many users completed checkout versus how many abandoned their cart; the difference between those numbers showed us exactly where expectations broke down. The checkout process had an unexpected shipping cost that only appeared on the final screen, and cart abandonment was sitting at 73%. We moved that information earlier and abandonment dropped to 48% within two weeks.

Don't forget qualitative feedback either. In-app surveys asking "Did you find what you were looking for?" right after key actions give you context the numbers cant provide. Sure, some people find them annoying but the insights are worth it—just keep them short and dont show them too often.

Turning Research Into an App People Will Actually Use

Right, so you've done all this research—you've spoken to users, looked at competitors, analysed the data—and now you're sat there with a massive pile of notes wondering what on earth to do with it all. I've been in this exact position more times than I can count, and honestly? This is where most projects either come together beautifully or fall apart completely.

The biggest mistake I see is trying to build everything at once. You know what happens? You end up with a bloated app that does fifteen things poorly instead of three things brilliantly. When we worked on a fitness app a while back, the research showed users wanted meal tracking, workout logging, progress photos, social features, coach messaging, and about ten other things. Building all that would've taken months and cost a fortune. Instead, we launched with just workout logging and progress tracking—the two features that came up most often as "must haves" rather than "nice to haves". It was a hard decision to make but it meant we could get something real into users hands quickly.

The apps that succeed aren't the ones that listened to every piece of feedback—they're the ones that knew which feedback actually mattered

Building Your Feature Priority Matrix

I use a simple system for turning research into actual features. Draw a grid with "user value" on one axis and "technical complexity" on the other. High value, low complexity? Build it first. High value, high complexity? Phase two. Low value features don't make it onto the roadmap at all, no matter how easy they are to build. This sounds obvious but you'd be surprised how many teams build features just because they're technically interesting rather than because users need them. Making sure your developer uses quality tools becomes important here, as proper development practices make it easier to add high-value features later without rebuilding everything.

Testing Before You Commit

Here's something that saves time and money—validate your research findings with a clickable prototype before writing any proper code. We built an entire banking app interface in Figma and tested it with twenty users over two days. Found out that our "clever" gesture-based navigation confused the hell out of people, even though it tested well in the surveys. Changed it to a standard tab bar and suddenly everything clicked. Cost us two days of design work instead of two months of development.

The thing about turning research into a real app is that you need to stay flexible. User expectations aren't set in stone; they evolve as they actually use what you've built. I always plan for at least two major updates in the first three months after launch based on real usage data. What people say they want in research and what they actually use can be quite different, and that's perfectly normal. You also need to consider how to plan around changing phone technologies to ensure your app remains relevant as platforms evolve.

Conclusion: Building Apps That Match What Users Are Looking For

After nine years of building apps across healthcare, fintech, e-commerce and everything in between, I can tell you that understanding user expectations isn't a one-time thing—its an ongoing process that continues well after your app launches. The fitness apps I worked on five years ago had completely different expectations than the ones we build now; users have been trained by market leaders to expect certain features, certain interactions, certain levels of polish. And that bar just keeps rising.

The apps that succeed are the ones that take all this research—the competitor analysis, the user interviews, the testing—and actually use it to make decisions. Not just design decisions either. I mean decisions about what features to build first, how to structure your onboarding, even what to call things in your interface. When we built a financial planning app for a fintech startup, we spent weeks just figuring out what users in that space expected from terms like "budget" versus "spending plan"... sounds trivial but it made a massive difference to comprehension and trust.

Here's what I've learned works best: start with a clear picture of what your specific category demands as table stakes (those features users will judge you harshly for missing), then identify one or two areas where you can genuinely do better than what's currently available. Not different for the sake of being different, but better in ways that matter to your actual users. The recipe app we built didn't try to reinvent how people search for recipes, but we did make the shopping list integration work properly—something users told us repeatedly was broken in every other app they'd tried. That one thing, done really well, became our main differentiator and the feature users mentioned most in reviews.

Frequently Asked Questions