Build Mobile Personas That Last

Who, exactly, is “the user”? When two good ideas fight over the same sprint, whose needs break the tie? And why does the user in every meeting have the same taste as whoever’s talking? (Uncanny. Almost like we made them up.)

A persona fixes all three: a specific person, drawn from research, who the team can design for and argue about. Get it wrong and it ends up printed, pinned up, and walked past.

On mobile, that person also comes with a place, a pace, and a phone in one hand. Nine things decide whether yours holds up.

1. Swap “the user” for a person.

Whitney Quesenbery shows why specific beats general in her 2003 personas overview[1]. One slide sums up a crowd in statistics. The next is Elizabeth, 35, with a five-year-old son, who last went online to find a local official’s name. You can’t design for the crowd. You can design for her.

That’s a persona: a fictional, research-based character who stands for a group of people who use your app. It isn’t one real person, but it should feel like one.

So give the user a name. Imagine a dog-walking app, and a persona named Priya. (She’s imaginary, and she’ll stick around.)

Now better questions show up. How would Priya feel about this feature? Would she understand this screen?

Those questions let you validate product and design decisions against someone specific and keep her needs and goals in front of the team. When ideas conflict, they set the priority: the argument moves from what you like to what Priya needs.

“The user” agrees with everyone. A persona can disagree.

2. Build it from people you’ve met.

The details matter: the more real, relevant information behind a persona, the more accurate the decisions you make with it.

You’ve seen the other version. Open a template! Pick a stock photo! Name her Busy Beth!

To be fair, it’s quick. But ask Beth to choose between two designs and she’ll pick her author’s favorite. Why? Because every detail came from inside the building.

Instead, write down a hypothesis: who you’re designing for, what they’re after, what drives them, and what gets in their way.

Then interview real people, and watch them complete tasks in their own environment. Surveys and focus groups are useful, but they capture what people say they do, while a persona runs on what they actually do.

For V2 of the study app I co-founded, I built a research platform. The two surveys running on it now are screeners: 41 responses from a community college STEM group and 63 from Prolific. A screener can tell you who to talk to. It can’t tell you who they are.

Every detail you invent is a decision you’ll make on a guess.

3. Sort what you heard into patterns.

A few interviews in, you’ll have a pile: quotes, notes, a blurry photo of a whiteboard.

Tag every observation. Group what repeats. Name the groups.

I’d look for four kinds of patterns:

• Environmental: the context of use. What’s around them?
• Cognitive: time. How much do they have, and how much attention comes with it?
• Social: triggers. What, or who, makes them reach for the app?
• Behavioral: roles. A dog walker is also a scheduler, a messenger, and sometimes a search party.

The persona isn’t any one interview. It’s what kept coming back.

4. Start typical, then widen.

Start with one persona. The Interaction Design Foundation’s article on why personas matter[2] is blunt about the alternative: design for everyone and you get something mediocre at best.

I’d build it around your most typical user, the person who looks most like the people you met. (Quesenbery[1] would pick the one with the most complex needs instead.)

Typical isn’t average.

Quesenbery calls a persona “archetypal, not average,” and the U.S. Air Force can tell you why. As Todd Rose recounts in The End of Average[3], researcher Gilbert Daniels checked 4,063 pilots against the average on ten body dimensions. Even counting the middle 30 percent of each range as average, not one pilot was average on all ten.

So design for Priya, the full-time walker, first. Then widen the cast. Add the student working around classes. Add the retiree who walks a few dogs on weekends. She still counts. She just doesn’t steer.

The average user is the one person you’ll never meet.

5. Give the persona a place and a pace.

Mobile users are often on the go and easily distracted, which says more about the setting than the person. Priya checks the app mid-walk, watching traffic, the dogs, and a screen, in roughly that order.

The Interaction Design Foundation’s guide to mobile personas[4] names three things: location, connectivity, and device usage patterns. For Priya, that means a signal that’s fine at the park and gone in the elevator, and a cracked phone in a jacket pocket.

Pick the key tasks, and make those work with one thumb and half her attention. The rest can wait.

If your persona could be sitting at a desk, you haven’t finished writing it.

6. Borrow their words.

Fill in the usual fields: a name, a background story, personality traits, goals, motivations, behaviors, and pain points. Then watch whose words you use.

The instinct is to tidy everything into team language: “Needs streamlined client communication.” It’s accurate, and nobody has ever said it out loud.

So use your participants’ words, almost verbatim. The character is invented, but the stories are real, and paraphrase sands them down until they sound like a spec.

Aim for a sentence or two of background, two or three on the problems to solve, and two or three on what they need and how your design can help. Here’s Priya:

If no participant would say it, your persona shouldn’t either.

7. Sketch a proto-persona when time is short.

Not enough time to interview anyone? That’s what a proto-persona is for: a quick persona built from what your team knows and outside sources like market research. It gives early-stage design a starting point and something to aim at.

I know the squeeze. The first version of our study app rested on secondary research and what’s known about how people learn, because AP exams weren’t going to wait.

Label a proto-persona plainly, and plan to replace it. Making one does no harm. The harm comes months later, when nobody remembers it was a guess and it has quietly become Busy Beth.

A proto-persona is a hypothesis wearing a name tag.

8. Use AI for the legwork, not the listening.

Don’t just ask AI to create a persona for your app.

Sure, what comes back looks the part: goals, frustrations, even a heartfelt quote.

But it can’t know what your users need, and that’s the part a persona is for. AI also isn’t a replacement for empathy, emotional intelligence, or intuition. The Interaction Design Foundation’s guide to AI for personas[5] agrees: a persona that AI invents from scratch is almost as bad as one built on assumptions, and it skips the research that builds a team’s empathy.

Personas are about focus. So is AI at its best: working with you on one task at a time. Give it the legwork:

• Define your objectives: draft research questions and refine a problem statement.
• Narrow down participants: write targeted screeners and personalized outreach.
• Plan the research: turn rough notes into documentation.
• Analyze transcripts: transcribe your recordings, tag recurring themes, and find connections across interviews. (Read the transcripts yourself, too.)
• Summarize insights: turn them into an affinity diagram or a draft persona to check against the research.

“Make me a persona for a dog-walking app” asks AI to imagine your users. “Here are my transcripts; what do the walkers who stopped logging walks have in common?” asks it to help you see them.

AI knows what people are like in general. Your users aren’t people in general.

9. Keep the persona in the room.

A persona does most of its work after it’s written. Use it as a reference during critiques and iterations: when a design goes up, ask what Priya would do with it before anyone says what they would. Quesenbery[1] suggests running design reviews from a persona’s point of view.

She also has a simple check: show the persona to people who meet real users, like your support team, and ask whether they recognize anyone. Better yet, ask users whether they recognize themselves.

Bring Priya to your next interviews. Cut the details that stopped being true. Add the ones that started.

Stop updating a persona and it slowly turns back into “the user.”

Put a real person behind the name.

A persona is a small piece of fiction with a serious job: one specific person to design for, instead of everyone, no one, or whoever’s talking. On mobile, that person also has somewhere to be.

So meet them before you name them. Meet them where they use your app. Meet them again when the product changes. Let AI help with the sorting, and do the listening yourself.

The name can be made up.

Everything else should be true.