How Do I Create a User Persona for My Mobile App?

A user persona for a mobile app is a short description of one kind of person who opens your app, what they're trying to get done once they're in there, and how they're feeling while they do it. You create a user persona by talking to real people, reading what your analytics and store reviews already say, and grouping the patterns into a handful of characters your team can hold in their heads. App user personas are worth the effort when they change a decision, and worth nothing when they don't.

Most personas fail because they describe who someone is and skip what they're trying to do.

The personas that arrive with a handover pack are usually demographic sketches. Thirty-four, lives in Manchester, enjoys yoga and weekend city breaks. That tells a designer nothing about what to put on the empty state, how to word a permission prompt, or whether the first screen should be calm or quick.

So this is a practical walk through how we put personas together for mobile products, what we ask, what we throw away, and what happens to the product once the personas are in the room. Some of it comes from projects where the persona work changed the brief entirely.

What an App User Persona Actually Is (and How It Differs From a Marketing Persona)

A marketing persona exists to help you reach someone. It carries the channels they spend time on, the message that lands, the price they accept, the reason they click. An app user persona exists to help you design what happens after they're in, so it carries the job they came to do, the moment they opened the app, and the emotional state they're in while they're using it.

We worked on a mobile app in the health and wellness genetics sector where those two things had come apart completely. The packaging and the online presence were luxurious and aspirational, all about transformation and becoming a better version of yourself. The app itself was cold and clinical, functional in its copy and its design. Somebody read the aspirational marketing, ordered a kit, did the test, waited, then opened the app to see their results and landed somewhere that felt like a different company.

Where app user personas differ

Somebody had written a persona for the person deciding to buy. Nobody had written one for the person sitting on the sofa at nine in the evening, reading something personal about their own body, slightly nervous about what it says. Those are two different people with two different needs, even when they're the same human being three weeks apart.

Gathering the Research: Who to Talk To and What to Ask

On a concierge app for a high-end property development, we ran focus groups with two very different groups. One was high-net-worth individuals, the actual target customers. The other was people living in social housing, who'd never be customers at all. We brought the second group in because they already had the thing we were trying to design into the product, which is a real sense of community, openness and neighbourliness. That quality is mostly absent from high-rise developments where residents never learn each other's names.

The same client had come to us with a budget and a fairly fixed idea of what they wanted, really looking for a validation rather than a scoping. We persuaded them into a proper discovery phase with focus groups and user workshops first. What came out of the sessions was that everything came down to communication, and the product needed to be far simpler than they'd planned.

Questions that get you somewhere

• What were you doing in the ten minutes before you opened the app?
• What did you expect to happen when you tapped that?
• What did you do instead the last time it didn't work?
• Who else is involved before you make that decision?
• What makes you put your phone down halfway through?

This kind of research is becoming standard practice rather than a luxury, with Maze, 2025 reporting that 42% of product managers already run user research of their own.

What Your Analytics and App Store Reviews Are Already Telling You

Before anyone books a single interview, there's a pile of evidence sitting in the dashboard and the store listing. Analytics tells you where people stop, how long they stay, which screens get opened at seven in the morning and which ones get opened at eleven at night. Reviews tell you the words people use for your product, which is rarely the words on your website.

On an anonymous messaging app we worked on, registration was required upfront, so we couldn't drip-feed the value once somebody was inside. Everything had to be communicated before the download, which meant a lot of work on the App Store listing and the screenshots. All the messaging that normally unfolds through use had to be front-loaded.

Your reviews are a free transcript of the words your users actually use.

That project changed how we read store pages generally. The reviews on your own listing and on the three apps people compare you against are a running record of expectations, disappointments and workarounds. One-star reviews are especially useful, because angry people are specific. They name the screen, the step and the thing they assumed was going to happen.

Spotting Patterns and Grouping Users Into Segments

Grouping is where most persona work goes wrong, because the easiest thing to sort by is age or income, and neither changes what you design. Sort by what people are trying to do and what stops them, and the groups start to earn their place.

We worked on a social product for fitness that was originally map-based, showing users their real-time location so people nearby could meet up for a shared workout. The research showed a high proportion of users were going to be female, and precise location sharing became a serious safety problem rather than a neat feature. So we redesigned it with randomised location offsets, so you see only the rough area somebody is in. People can then talk, look at each other's profiles, and choose to share an exact location later.

If two groups in your research want the same thing for the same reason and behave the same way inside the app, they're one persona with two job titles. Merge them.

A workable sequence for getting there:

1. List every behaviour you've observed, one per line, no grouping yet.
2. Sort those behaviours by the job the person was trying to finish.
3. Check each pile against a motivation and an anxiety, and see if it holds.
4. Delete any group that doesn't change a single design decision.

How Many Personas Do You Actually Need?

Two or three. Four at the outside. Past that, nobody remembers them and the team quietly goes back to designing for themselves. There's a reasonably well-travelled claim from MixBright that around 90% of a company's sales come from three or four primary personas, and while that figure comes without a stated method, it matches what we find when we sort real research into piles.

On a gifting product we worked on, the whole design came down to two people. Parents creating a wishlist were tech-savvy and arrived with a clear purpose, so their onboarding only had to show them how to use the thing. Contributors, often grandparents, arrived because a family member had messaged them asking them to do something. They had no context at all.

Two personas, two different products

Those two personas pulled the onboarding in opposite directions. One wanted speed and the other wanted explanation, and we couldn't average them out into a single flow without failing both. Two personas were enough to make the hardest decision on the project. A fifth persona wouldn't have added anything except a slide.

What to Put in the Persona

Keep it to one page, and keep every line connected to something somebody has to design. A stock photo and a favourite coffee order are padding. The test for any field is simple, which is whether a designer or a developer changes what they make because of it.

Add two or three real quotes from your research underneath, word for word. Quotes travel further inside a team than any summary you write, and they stop people rewriting the persona in their own head.

Context: Device, Moment and Mindset

Mobile personas live or die on context. The same person handles your app differently on a crowded train with one thumb than they do in bed with the lights off. Write down the posture, the hand, the signal strength and the interruption risk, because all four change what a screen can reasonably ask for.

One of the first things we do with clients is work out the core flow, the emotional feeling we want somebody to have, and the functional and emotional job the product is doing. From there we work out how much use somebody needs before the value actually lands. If a person needs to experience a five-minute workout before a fitness product makes sense, then five minutes of workout is what has to happen first.

Work out the smallest amount of use that makes the point, then protect that path.

That threshold is where the login prompt belongs. Personas for apps are what let you set it honestly, because the answer is different for the person who came looking for you and the person who tapped a link from a friend with no idea what they're opening.

Motivations, Anxieties and Emotional Drivers

Start by mapping every situation that leads a person to your product. On an app for managing the flat you live in, with concierge services attached, we'd look at all the routes into that building. Somebody buying a first home after years of renting. Somebody going through a divorce and starting again. Somebody who's finally afforded the place they always wanted. Three people, three completely different emotional states, one home screen.

Those states then have to be checked rather than assumed, through focus groups and surveys, because a team's guess about how a user feels is usually a guess about how the team feels.

For every motivation you write down, write the matching anxiety underneath it. The anxiety is what your interface has to answer first.

Headspace handles this better than it gets credit for. The illustrated characters rather than photography are doing a lot of the trust-building work. A photograph of a serene person on a clifftop sets a standard a stressed user feels they're failing to meet. A cartoon sun implies nothing about you at all. Teardowns of wellbeing products tend to focus on the copy and skip straight past the artwork, which is carrying the emotional load.

Building Proto-Personas When You Have No Users Yet

Pre-launch, you write proto-personas, which are the same document built from assumptions you've labelled honestly as assumptions. Then you go and test the riskiest ones before anything gets designed.

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out every competitor product, planning to merge several of them into one. They were excited and pleased with themselves, and the spreadsheet was genuinely thorough. We started asking questions about the prospective users instead. Why does somebody pick an all-in-one product over three specialised apps they already have? Does merging those features water each one down? The founder was deflated by the end of it, and that's uncomfortable, and it's our job to be honest about what makes a product succeed. Building on vanity metrics serves nobody.

Turning assumptions into proto-personas

A competitor spreadsheet describes products. A proto-persona describes a person with a problem, a current workaround, and a reason to switch. Write the switch reason first, because if you can't write it, no amount of feature mapping fixes that.

Writing Personas the Whole Team Will Actually Use

A persona document that lives in a shared drive is a document nobody reads twice. The ones that stick get spoken out loud in meetings, which means they have to be short enough to quote and human enough to argue with.

In our client workshops we run a game called the dinner party, where we picture the product itself as a person. How do they dress, how do they talk, are they the loudest voice in the room or the quiet one listening at the end of the table? It gives us a character to measure everything against. Once that person exists, you can hold any screen or any line of copy up and ask whether they'd really say it that way.

Run that alongside your user personas and you get both halves of the conversation, which is who's speaking and who's listening. Then judge every interaction against the pair. The tone, the copy, the timing of a notification, the way an error reads at seven in the morning. If it fits both characters, keep it. If it doesn't, throw it out and start again.

Turning Personas Into Product and Design Decisions

On the concierge app, the original brief was to give everyone in-app access to everything, so residents never needed to speak to the concierge at all. We pushed back on that. The research had said community came from communication, and removing the only human in the building was pointing the wrong way.

So each concierge got a profile inside the app listing things to talk to them about. Football, motorsport, whatever that person was into. An explicit invitation to have a human conversation rather than file a request.

The first real test of a persona is whether it takes a feature out of the plan.

Alongside that, we automated the mundane tasks to free up space for social interaction, added personalisation so residents could see their neighbours' interests, and created a social space within the app. Plenty of planned features were dropped. The product came out simpler than the client had imagined, at a lower cost, and it worked really well. None of that happens without the focus groups that produced the personas in the first place.

Validating and Updating Personas as the App Grows

Personas go stale, and they go stale quietly. Your audience shifts, a feature changes who downloads you, a channel brings in people with different expectations. The document on the wall stays confident while the reality underneath it moves.

Set a rhythm for checking them rather than waiting for something to feel wrong.

1. Every month, read new store reviews and note any language you haven't heard before.
2. Every quarter, compare your analytics segments against the personas and look for a group with no home.
3. Twice a year, run a short round of interviews with recent installs and recent churners.
4. After any major release, check whether the job each persona came to do has changed.

Teams that keep their personas tied to data report getting more out of them. MixBright puts the figure at 82% saying their value propositions improved, which is self-reported and light on method, so treat it as a direction of travel rather than a measurement.

Mistakes That Make Personas Useless

The failure modes repeat across projects, and they're mostly about the persona describing a person instead of describing a design problem.

• Demographics doing all the work, with age and postcode standing in for motivation.
• Personas written from the team's assumptions and never checked with anyone outside the building.
• Seven personas, which is the same as none.
• A marketing persona copied into a product brief and asked to do a job it was never written for.
• Emotional state left off entirely, so the tone of voice gets decided by whoever writes the copy last.

Put the date and the research source at the top of every persona. An undated persona gets trusted long after it stopped being true.

There's one more, which is treating the persona as a finished artefact rather than a working tool. The value shows up in the argument it settles on a Tuesday afternoon, when two people disagree about whether a screen needs an explanation and somebody opens the document to check who's actually arriving there.

Conclusion

Creating app user personas is slower than it looks and simpler than it sounds. You talk to real people, including a few who'll never buy from you. You read what your analytics and reviews already say. You sort the findings by what people are trying to do, keep two or three characters, and write down the moment, the mindset and the anxiety alongside the job.

Then you use them. The genetics app needed a persona for the nervous person reading their results, not only the aspirational one deciding to buy. The fitness product needed a persona honest enough to make location sharing a safety question. The gifting product needed two, because the grandparent arriving from a text message is a different person to the parent who went looking.

Every one of those changed what got designed, and a couple of them changed what got left out, which saved real money. That's the measure worth applying to your own personas.

If you're working through this for a product of your own and want a second pair of eyes on the research plan, let's talk about your app user personas.

Frequently Asked Questions