--- title: Who Might Use My Mobile App? description: Wondering who might use your mobile app? Learn how to define your audience by situation, emotion and behaviour rather than age brackets alone. image: https://weareaffective.com/hubfs/learning-centre-images/who-might-use-my-mobile-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/who-might-use-my-mobile-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Who Might Use My Mobile App? Table of Contents Ask a founder who their app is for and you'll usually get an age range, a city and an income bracket. We answer the question "who might use my mobile app" with a list of situations instead, because a 34 year old buying their first flat and a 34 year old leaving a marriage will open the same product in completely different states of mind. > Ages tell you nothing about the day somebody opens your app, and the day shapes the design. Demographics are useful later, for media buying and for sizing a market. They're a poor brief for a designer. Age doesn't tell you what someone wants in the first thirty seconds, how much patience they have, or whether they even know what the app is for when they land on the first screen. Across concierge products, a gifting app, a fitness social product and a group travel booking platform, the same pattern keeps showing up. The people who pay for the product and the people who live in it are rarely the same, and the groups you didn't plan for often decide whether the thing works. This piece walks through how we work out who's really going to use a product, how we [go and find out rather than guess](https://weareaffective.com/app-user-research), and what we do with the answer. ## Start With Use Cases, Not Demographics Take a flat management app with concierge services, the kind of product we've worked on. Before anyone talks about age brackets, we write down every situation that ends with a person living in that building. A first place after leaving home. A divorce, where someone's moving out and starting again. A couple who've saved for years and finally afforded the flat they wanted. Relocation for a job. Downsizing after the children have gone. #### Who might use my mobile app, and when? Each of those arrives with a different feeling, a different amount of time, and a different tolerance for being asked to fill in forms. The person moving out of a marriage doesn't want a cheerful welcome tour. The couple who've been saving for a decade probably do want a bit of ceremony. Same building, same app, same age on the form. The list of situations also tells you [what to go and check](https://weareaffective.com/app-user-research). You can survey against it, recruit focus groups against it, and throw out the ones that turn out to be rare. Skipping that step is expensive. [Business of Apps](https://www.businessofapps.com/insights/top-reasons-why-mobile-apps-fail-to-make-a-mark-in-the-market/#:~:text=As%20surprising%20it%20may%20sound,%20three%20days%20of%20its%20installation.) puts the share of apps that fail without prior market research at 42 per cent. Write your use case list before you write a single user story. If a use case can't be described in one sentence about a real day in someone's life, it isn't a use case yet. ## The Difference Between Who Buys and Who Uses We worked on a gifting product that let parents and children build wishlists of things to save towards, and let friends, family and grandparents put money into those pots for birthdays or holidays. It predated PayPal's money pots and the savings features that challenger banks later shipped. Three very different groups had to be served at once, and only one of them was anything like the person we'd have described as the buyer. | Group | Why they're in the app | What the design had to do | | --- | --- | --- | | Parents | Set up a wishlist and share it | Get out of the way, they already knew why they were there | | Children | See the pot grow towards something they want | Make progress visible and worth coming back to | | Grandparents and other contributors | A family member asked them to send money | Explain what this is, why it's safe, then handle the payment | The concierge app had the same split in a different shape. A property developer paid for it and had clear commercial goals. Residents were the ones who'd open it on a wet Tuesday to report a broken lift. [Designing only for the person signing the contract](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need) would have produced a building management tool nobody loved. So the buyer sets the brief and the user decides whether it survives. Both need to be in the room. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Mapping the Emotional State People Arrive In The journey starts before anyone taps the icon. Somebody's been handed keys, or had an argument, or received a text from their daughter asking them to chip in for a birthday present. That's the state they bring with them, and the first screen either meets it or ignores it. > The mood arrives before the user does, so the first screen is answering a feeling, not a search. On the concierge app, this changed something as small as notification timing. We didn't go with a fixed delay like two days after move-in. We ran scenario research to understand how people actually behave on moving day. Someone who arrives in the morning will start unpacking that afternoon. Someone who arrives at eight in the evening won't touch a box until tomorrow. A single person takes longer to unpack than a household of three. What we built was dynamic timing. The app worked out when to send each message based on arrival time and how many people were moving in, so the prompt about recycling or fire drills landed when there was space to read it. It's a small thing on a spec sheet and a big thing in the hand, because a message that arrives mid-chaos is just noise. ## Finding Real Demographic Data on Your Audience Once the situations are written down, demographics stop being a guess and start being a check. We worked on [a fitness social product built around](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) meeting people for shared workouts, and the research told us something the founding team hadn't assumed. A high proportion of the likely user base was female. That one fact rewrote the central feature of the app, which we'll come back to. #### Where the demographic data lives To find mobile app user demographics without inventing them, we pull from whatever already exists before commissioning anything new. - App store and Play Console data for any product already live, including device, country and language - Existing customer records, order histories and CRM exports from the wider business - Social audience breakdowns, which are rough but free and fast - Competitor review sections, where people describe themselves while complaining - Short surveys sent to an existing mailing list, built around the use case list None of it is perfect. Platform data skews to whoever already found you, and review sections skew to the angry. Read together, though, they usually confirm two or three of your use cases and quietly kill one you were fond of. ## Running Focus Groups That Actually Tell You Something On the gifting product we ran several focus groups across different ages and types of people, because the product had to work for a parent setting up a pot and for a grandparent who'd been sent a link. Asking one group and assuming the rest would cope would have produced something that only made sense to the people who built it. A focus group goes wrong when you ask people what they'd like. People are generous, and they'll invent an opinion to be helpful. The sessions that pay for themselves ask about what already happened. 1. Write the situations first, then recruit people who are actually in them 2. Ask what they did last time, in order, with dates and names where they remember 3. Watch for the workaround, because the spreadsheet or WhatsApp group they built is your feature list 4. Read the words back to them, since terminology that makes a team nod can make a user hesitate 5. Run one group who'll never be customers, for reasons we'll get to Record how long people take to answer, not just what they answer. [A pause before someone explains why they trust](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them) a product is usually the sound of them deciding they don't. Six to eight people, an hour and a half, and a clear list of situations beats a hundred survey responses about preferences. ## Why Talking to People Who Will Never Buy Pays Off On the concierge app for a high-end property development, we ran focus groups with two groups. One was high-net-worth individuals, the target customers. The other was people living in social housing, who were never going to buy a flat in that building. We brought the second group in because they already had the thing the client wanted the product to create. A genuine sense of community, where people know each other's names, interests, families and pets. That quality is usually missing in high-rise developments, where residents can share a lift for three years and never speak. What we found in those sessions is that the conversations between neighbours weren't superficial. They were deeper than that, and that depth was what held the place together. The target audience couldn't have told us this. You can't describe the mechanics of something you've never had. So the group who'd never pay us a penny gave us the design direction, and the group who'd pay for everything gave us the constraints. Recruiting outside your target market feels like a waste of budget right up until the session where somebody explains, without being asked, exactly what you've been trying to build. ## When Your Audiences Want Contradictory Things The property developer on that concierge project wanted two things. A full-service building management utility, where residents could report a leak or book the lift without phoning anyone. And a community-building social tool that made the development feel like a neighbourhood. Those two goals pull in opposite directions. Every task you move into an app is a conversation that no longer happens at the concierge desk. Build enough of them and you've engineered the silence you were hired to fix. > Two good ideas in one product can quietly cancel each other out unless somebody names the conflict. Naming it changed the brief. We stopped treating the app as the place where everything gets solved. The mundane, transactional jobs went in, so maintenance requests, fire drill procedures and where the recycling lives all became a few taps. The time that freed up was pointed back at people, with the app actively encouraging face-to-face conversation with the concierge and between residents. Contradictions between audiences are normal and they're solvable, as long as you stop trying to split the difference. Work out which jobs belong to the software and which jobs belong to the humans, then let the software protect the humans' time rather than replace it. ## Designing Onboarding for Users Who Arrive With No Context The hardest part of the gifting product was onboarding, because two groups needed completely different things from it. Parents had gone looking for the app. They'd read about it, decided it solved a problem, and downloaded it on purpose. Their onboarding could be short and could assume the why, so it only had to cover how. Get the wishlist built, get it shared, get out of the way. Contributors came in cold. A grandparent got a message from a family member asking them to put twenty pounds towards a bike. They hadn't chosen the app, hadn't heard of it, and in some cases weren't comfortable entering card details anywhere. For them the onboarding had to teach first, covering what this is, why it's safe, how it's safe, how it works and what the money's for, before it ever asked for a payment. Running both groups through one flow would have failed both. The parents would have been bored and the grandparents would have been lost. Friction in that first session is costly either way, with [AppsFlyer](https://sparklin.com/blog/why-users-abandon-apps-during-onboarding) figures putting users who hit it at 2.7 times less likely to return by day seven. ## Safety, Trust and the Users You Did Not Plan For The fitness social product started out map based. Your location, live, on a map, so other people could see you were nearby and suggest a run. It's a clean idea when you picture the user as somebody like the person who designed it. The research showing a high proportion of female users turned that feature into a security problem overnight. [Broadcasting a precise home or gym location](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron) to strangers isn't a feature anyone should ship. We rebuilt it with a randomised offset, so what you see is a vague area rather than a point. Enough to judge whether a meet-up is realistic, not enough to find anyone. People could then talk, read each other's profiles, and choose to share their exact location when they were ready. The value survived and the risk went. For any feature that shares location, identity or money, write down the worst thing a user could do with it to another user. Design that out before you design the happy path. Trust work shows up in quieter places too. The reason the gifting product's contributor onboarding explained how the money was held wasn't politeness. A grandparent who isn't sure will simply close the app and ring their daughter instead. ## Turning Audience Insight Into Product Decisions Research that doesn't change the build is a document. On the concierge app, the focus groups led to three concrete changes, and the client could point at each one. First, the mundane building tasks were automated and pushed into the app, which cleared the concierge's time for the conversations that actually built familiarity. Second, we added personalisation so residents could see their neighbours' interests, and so the concierge came across as a person with a personality rather than a service desk. Third, we built a social space inside the product where those connections had somewhere to live. It worked really well. Every one of those traces back to a sentence someone said in a room. Community is built on familiarity, and familiarity is built on knowing names, interests, families and pets. That's the whole chain, from a focus group comment to a feature in a backlog. The same logic applies to messaging. A notification written for the person who already knows what your app does is a different message from one written for the person who doesn't, and the difference shows up in the numbers. [EMB Global](https://blog.emb.global/target-audience-for-mobile-apps/#:~:text=A%20target%20audience%20is%20a,%20your%20product%20or%20mobile%20app) reports personalised push notifications aimed at specific interests being opened eight times more often than standard ones. ## How One User Group Brings You the Next We worked on a travel booking product aimed at people in their early twenties to mid-thirties, built around group trips. After launch the team tried the usual acquisition tactics. Referral discounts, push notifications to wake up lapsed users, social sharing of trips, email campaigns through Mailchimp. All of it did something and none of it did much. > The booking flow brought the users, because a group trip needs everybody on it to actually be on it. What moved the numbers was a loop built into the booking itself. When one person organised a trip, the app prompted every other traveller in that group to download it, both for the group chat and to submit their passport details. The organiser needed them to, so they did. One person booking a trip for ten gave us nine new users, and each of those nine had their own friends and their own trip to organise next summer. That's [a product decision rather than a marketing one](https://weareaffective.com/learning-centre/5-reasons-every-business-should-focus-on-mobile-app-development), and it came from understanding a second user group the original brief barely mentioned. The organiser was the customer. The other nine were participants who happened to need the same app. Designing properly for the participants turned them into the growth channel. ## Keeping Your Picture of Your Users Honest After Launch Your picture of your audience starts going out of date the week you launch. The useful correction comes from [behaviour in the product rather than from another round](https://weareaffective.com/learning-centre/the-soft-launch-conversation-nobody-wants-to-have-with-marketing) of interviews. We look at dwell time, how fast people move through, how long and how often they use it, whether they come back, and whether they keep getting stuck on the same screen or complete different tasks across several visits in a day. Those patterns point at emotional state, and emotional state tells you which of your use cases is actually showing up. Feedback needs the same honesty. App rating prompts used to be fired at the moment somebody uninstalled, which is about the worst possible timing. By then a person either has no use for the product any more and won't bother, or they've had a bad experience and will say so. The ratings that came back were never representative of the people quietly getting value every week. Ask at a moment of success instead, right after a task somebody wanted to finish gets finished. The answers are more balanced and they tell you which group is happy, which is a question your use case list was always trying to answer. ## Conclusion Working out who might use my mobile app is less about describing a person and more about listing the days that end with someone opening your product. The flat after a divorce. The grandparent sent a link by their daughter. The woman deciding whether a stranger should know where she runs. The nine friends on somebody else's holiday. Every project here changed shape once we knew that list. The concierge app stopped trying to replace human conversation and started protecting it. The gifting app grew two onboarding journeys instead of one. The fitness product swapped a precise dot for a vague circle and kept the thing that made it worth using. The travel product found its growth inside the booking flow. None of that came from a demographic profile. It came from writing down the situations, going and talking to people who were in them, including a few who'd never buy, and then letting what they said change the build. If you're mapping out who your app is really for, or you suspect the audience you launched with isn't the one you've got, we're happy to talk it through. [Let's talk about who's really using your app](https://weareaffective.com/get-started). ## Frequently Asked Questions Why shouldn't I define my app's audience by age, location and income? Demographics are useful for media buying and sizing a market, but they make a poor design brief. Two people of the same age can open your app in completely different states of mind, and that day, not their age, is what shapes what they need from the first screen. What is a use case list and how do I write one? A use case list sets out every real situation that ends with someone opening your app, for example a first place after leaving home, a divorce, a relocation or downsizing once the children have left. Write it before you write a single user story, and if a use case can't be described in one sentence about a real day in someone's life, it isn't a use case yet. How do I know which use cases are real rather than imagined? Use the list as a research brief. You can survey against it, recruit focus groups against it and throw out the situations that turn out to be rare. Skipping that step is expensive, with Business of Apps putting the share of apps that fail without prior market research at 42 per cent. Why does the difference between who buys and who uses matter so much? The person who pays for a product and the person who lives in it are often not the same, so designing only for the buyer leaves most of your audience unserved. In a gifting product, parents, children and contributing grandparents all needed the app at once, and only one of those groups looked anything like the buyer. How should the design change for different groups in the same app? Each group needs a different amount of explanation and a different tone. People who already know why they are there want the interface to get out of the way, while occasional contributors who have simply been asked to send money need the purpose explained before anything else happens. What about the users I didn't plan for? Unplanned groups often decide whether the product works at all, because they arrive with no context and little patience. Treat any group you discover in research as a first class audience rather than an edge case, and check whether their journey holds up end to end. Does emotional context really change the interface, or is it just tone of voice? It changes both. Someone moving out of a marriage doesn't want a cheerful welcome tour, while a couple who have saved for a decade probably do want a little ceremony, so onboarding length, imagery, copy and how much form filling you ask for all shift with the situation. When do demographics become useful again? Later, once the product is built and you need to buy media or size the market for investors. At that point age, location and income help you reach people efficiently, but they still shouldn't be the thing driving design decisions. ## Related Articles [![When Your App Needs Music Licensing and How Much It Costs?](https://weareaffective.com/hubfs/learning-centre-images/when-your-app-needs-music-licensing-and-how-much-it-costs.webp)](https://weareaffective.com/learning-centre/when-your-app-needs-music-licensing-and-how-much-it-costs) ### [When Your App Needs Music Licensing and How Much It Costs](https://weareaffective.com/learning-centre/when-your-app-needs-music-licensing-and-how-much-it-costs) Music has a way of making digital products feel alive. The right track behind a montage feature, a... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What the Term 'Behavioural Coherence' Actually Means Across a Multi-Touchpoint Experience](https://weareaffective.com/hubfs/learning-centre-images/what-the-term-behavioural-coherence-actually-means-across-a-multi-touchpoint-experience.webp)](https://weareaffective.com/learning-centre/what-the-term-behavioural-coherence-actually-means-across-a-multi-touchpoint-exp) ### [What the Term 'Behavioural Coherence' Actually Means Across a Multi-Touchpoint Experience](https://weareaffective.com/learning-centre/what-the-term-behavioural-coherence-actually-means-across-a-multi-touchpoint-exp) A wellness brand spends eighteen months building a campaign around transformation. The photography... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![should-my-app-design-match-my-website-design](https://weareaffective.com/hubfs/learning-centre-images/should-my-app-design-match-my-website-design.webp)](https://weareaffective.com/learning-centre/should-my-app-design-match-my-website-design) ### [Should My App Design Match My Website Design?](https://weareaffective.com/learning-centre/should-my-app-design-match-my-website-design) Have you ever wondered why some brands feel completely disconnected when you switch from their... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.