How to Create UX User Personas (With Template)

TL;DR: What You Will Learn

• A UX persona is a research-based profile of a real user type, built to guide design decisions rather than sell to someone.
• Research matters because personas invented from assumptions just repackage your team’s bias as fact.
• I have included a copy-ready template so you can start building one straight after reading.

What is a UX User Persona?

Let me start with a definition, because this is where most teams go wrong. A user persona is a research-based, semi-fictional archetype that represents a real segment of your actual users, built to guide design decisions a definition consistent with how Nielsen Norman Group, a widely-cited UX research group, frames it

The key words there are “research-based” and “guide design decisions”. A persona is not a random character you dream up in a workshop to make slides look nicer.

Alan Cooper, the interaction designer who invented the method, framed it well in his book The Inmates Are Running the Asylum: “Personas are not real people, but they represent them throughout the design process.” In other words, they are imaginary stand-ins built with real rigour.

Alan Cooper, who introduced personas to software design in his 1999 book The Inmates Are Running the Asylum, put it plainly: personas are not real people, but they represent them throughout the design process. That’s the bar I hold every persona to: a stand-in for something observed, not a character.

Here’s a hypothetical to make this concrete: imagine a team building a public service app where older Singaporeans log in with a national digital ID to check health records. Their persona is not “senior citizen, aged 65 plus”. It is a behaviour-first picture of how someone actually struggles with two-factor login, small tap targets, and English-only labels.

What is the Difference Between a UX Persona and a Buyer Persona?

The confusion I see most often. Marketing teams build buyer personas, and people assume a UX persona is the same thing. It is not.

A buyer persona focuses on purchase intent, demographics, and messaging: who will click the ad, what income bracket they sit in, and which channel converts them. It exists to run campaigns.

A UX persona focuses on what the person is trying to do inside your product and where they get stuck. If you have ever wondered about the difference between UI and UX, this is a similar split: one lens is about attracting and selling, the other is about the actual task and experience.

For our Singpass example, a buyer persona might say “digitally cautious, values government trust”. A UX persona says “abandons the flow when the OTP screen times out before she finds her phone”.

What Should a UX Persona Include?

A useful UX persona is built around behaviour and context, not just a headshot and an age. When I build one, I make sure it carries these things:

• Goals: What the user is genuinely trying to accomplish, like renewing a subsidy without visiting a service centre.
• Behaviours: How they actually use the product, such as relying on a family member to complete steps.
• Pain points: The specific friction, like tiny fonts or jargon-heavy error messages.
• Context of use: The where and how, for instance, a shaky mobile connection on an older Android phone.

Notice that demographics barely feature. Age matters only where it shapes behaviour, such as eyesight affecting readability.

When Personas Add Value

Personas earn their keep when a team has to make trade-offs and disagrees on who they are designing for. They give everyone a shared, evidence-based reference point.

They add the most value on products with distinct user segments, like a service that must work for both a confident young professional and an elderly first-time user. Skip them when you have no real user data, because a persona invented without research is just an opinion in a nice template.

Gathering the Research Inputs That Make Personas Real

One thing I tell every team I train: a user persona without research is just an assumption wearing a nice layout.

If you invent “Busy Bella, 32, loves convenience” out of thin air, you have not described a user. You have described a hunch, and hunches make expensive design decisions.

The credible way to build a persona is to feed it real evidence, both qualitative and quantitative. Let me walk you through the three sources I lean on most.

It helps to know where you’re aiming. Nielsen Norman Group sorts personas into three tiers by rigor: proto-personas built from a team’s existing assumptions in an afternoon, qualitative personas built from roughly 5 to 30 user interviews, and statistical personas built from large-scale survey and cluster analysis. For most teams, qualitative is the sweet spot: real evidence, without needing a research department to get there.

User Interviews and Contextual Inquiry

Talking to real users is where personas get their soul. Numbers tell you what happened; interviews tell you why.

I recommend sitting with people while they actually use a product, which we call contextual inquiry. Watching a hawker stall owner fumble through a delivery app on a cracked phone teaches you more than any survey ever will.

Ask open questions about goals, frustrations, and workarounds. If you are building or hiring for this skill, the way candidates probe user motivation is exactly what comes up in these ten UX designer interview questions hiring managers ask.

One important note: under Singapore’s Personal Data Protection Act (PDPA), recorded interviews and stored names or contact details generally count as personal data; the PDPC’s own guidance on this is worth a skim if you’re unsure where the exceptions apply. Get clear consent, tell participants how you will use their responses, and anonymise identifiers before you write anything up

Behavioural Data and Analytics

Interviews reveal intent, but analytics reveal behaviour at scale, and the two often disagree.

Here’s a hypothetical: imagine a Singapore e-commerce team selling on their own site as well as major marketplaces. In this scenario, they pull checkout drop-off data and notice a spike in abandonment at the payment step on mobile.

In this scenario, the analytics tell them where users leave, and interviews reveal shoppers were hunting for a specific payment method and couldn’t find it. Neither source alone would have caught the full picture.

Look at funnels, session recordings, heatmaps, and drop-off points. Let the data challenge the story your interviews are telling you, not just confirm it.

Surveys and Support Tickets

Surveys help you validate patterns across a larger group and attach rough proportions to what you heard in interviews.

Support tickets and live chat logs are an underrated goldmine. Your customer service team already knows the recurring pain points, so read through a month of tickets and tag the themes.

When you collect survey data, apply the same PDPA discipline: state your purpose, seek consent, and strip out anything that identifies an individual before it lands in a shared persona document.

Here is my one rule that ties it all together: triangulate. Never build a persona on a single source.

When your interviews, your analytics, and your support tickets all point to the same frustration, you can trust it. When they contradict each other, that tension is where the most interesting design insights hide, so dig in before you write a word of your persona.

Turning Research Into Patterns and Segments

Once you have finished your interviews, surveys, and analytics pulls, resist the urge to jump straight into writing a user persona. Raw data does not hand you neat groups. You have to find them.

The mistake I see most often is teams inventing a persona from a gut feeling, then hunting for quotes to justify it. Do it the other way round: let the patterns surface first, then name the people they represent.

Affinity Mapping Your Notes

Start by getting every observation out of your documents and onto individual sticky notes, one thought per note. I mean actual behaviours and quotes, not summaries.

Then cluster them. Put notes that feel related next to each other without labelling anything yet. Only after the groups form do you write a heading for each cluster. This is affinity mapping, and it works just as well on a Miro board as on a meeting room wall.

You are looking for repeated behaviours, goals and frustrations, not demographics. Two people can both be 45 and behave nothing alike, so cluster on what they do and want.

Spotting Distinct Segments

Imagine a Singapore fintech team reviewing usage data and interview notes for their investing app. On the surface, everyone is a user. Look closer and two very different behaviour clusters appear.

One group is cautious older savers who log in occasionally, favour fixed deposits and SGS bonds, and abandon any flow that feels risky or jargon-heavy. The other is fast-moving younger investors who trade weekly, chase new products, and get frustrated by anything that slows them down.

These two groups need different designs, so they need different personas. Forcing them into one blended “average user” would produce a product that serves neither well.

That is the real test of a segment: does this group need something meaningfully different from the others? If the design implications are identical, you do not need a separate persona.

How Many User Personas Do You Need?

Most projects land on three to five personas, a range Nielsen Norman Group’s own research on persona sets points to as well. That range is not a rule; it is a practical limit on what a team can actually hold in their heads while designing.

I would rather have three personas the whole team can recite than eight nobody remembers. Over-segmenting is a common trap: you slice so finely that you end up with personas separated by tiny differences no one will ever design around.

When you have a long list of candidate segments, ask two questions:

• Does this group behave differently enough to change a design decision?
• Is this group important enough to our business to prioritise?

Merge the ones that fail either test. Keep the segments that survive, and only then start writing them up as personas.

Building a Persona Step by Step

Let me show you how I turn a raw research segment into a user persona that a team can actually use. We will build one together, field by field, using evidence rather than imagination.

Our example is Mei Ling, 34, a working mother in Tampines who books childcare through a government portal on her phone during her MRT commute. Every attribute below comes from something a real user said or did, not from what I assumed.

Core Profile and Context

Start with the basics, but only the ones that shape decisions. Mei Ling’s age matters less than the fact that she is a dual-income parent juggling a full-time job and school pickups.

Her context is the headline: she completes tasks on a small screen, in short windows, often standing on a crowded train. That single detail already tells us the portal must work well on mobile with large tap targets, not just on a desktop.

I write context from real behaviour I observed in interviews, not demographics for their own sake. If a field does not change how you design, cut it.

Goals, Motivations and Frustrations

Next, capture what Mei Ling is trying to achieve and why it matters to her. Her goal is simple: secure a confirmed childcare slot before it fills up, without taking time off work to phone a centre.

Her motivation runs deeper. She wants the peace of mind of knowing her child is cared for so she can focus at work, which tells us reassurance and clear confirmation states are as important as the booking flow itself.

For frustrations, I use direct quotes pulled straight from interview transcripts. A quote like “I filled in everything and then it timed out, and I lost it all” is the kind of line that, once heard in an interview, becomes the anchor for a frustration about session timeouts and lost progress.

Design implications flow naturally from each of these:

• The goal of fast booking implies a streamlined flow with minimal steps.
• Motivation of reassurance implies visible confirmation and status tracking.
• Frustration with timeouts implies autosave and clear error recovery.

A real quote does more work than a paragraph of description. It keeps the whole team honest about who they are building for.

Behaviours and Scenarios of Use

Finally, describe how Mei Ling actually behaves and paint a scenario the team can picture. She checks the portal in two or three quick bursts a day, rarely finishing a task in one sitting.

Write a short use scenario in her words: she opens the app between MRT stops, gets interrupted when she reaches her station, then resumes at her desk during lunch. That interrupted journey is a design constraint most teams miss until a persona surfaces it.

If your team also builds the interface, this is where the persona meets tools. When you move into wireframes, this complete beginner’s guide on how to use Figma helps you translate these behaviours into screens that respect how Mei Ling really works.

Keep every field ruthlessly focused. A persona earns its place only when each attribute points to a decision your team can make.

Avoiding Assumptions and Stereotypes

The fastest way to ruin a user persona is to build it on what your team believes rather than what your research actually shows.

I have watched this happen in workshops. Someone confidently says, “Our users are busy mums who hate reading long text,” and because nobody pushes back, that guess quietly hardens into a persona that shapes months of design decisions.

Pressure-Test Every Attribute

Go through your persona line by line and ask a simple question of each statement: Is this evidence, or is this opinion?

If an attribute came from an interview transcript, a survey response, or observed behaviour, it stays. If it came from a hunch, flag it and either verify it or delete it.

I find it helps to keep a visible marker next to unverified claims, so nobody mistakes a placeholder for a fact.

A persona attribute is only valid if you can point to the research that produced it.

Drop Demographic Stereotypes That Carry No Design Relevance

In multicultural Singapore, it is tempting to load personas with age, race, or gender details that feel descriptive but change nothing about how you actually design.

Ask yourself: does knowing this person’s ethnicity or gender change the interface, the copy, or the flow? If it does not, it is decoration, and worse, it invites lazy assumptions.

Nielsen Norman Group has a blunt two-word test for this exact trap: you are not the user. It’s usually aimed at designers projecting their own habits onto a persona, but it applies just as well to any demographic detail a team adds because it feels descriptive rather than because research says it matters.

Here is a scenario I have seen play out. A team designing a HealthHub-style appointment feature assumed all seniors would struggle with technology, so they planned oversized buttons and stripped out useful features.

Then they ran interviews with retirees and met people who booked flights, managed PayNow transfers, and video-called grandchildren daily. Their real barrier was not capability; it was tiny text and confusing labels, a completely different problem.

That single round of talking to actual users saved them from designing for a stereotype instead of a person.

Validate With Fresh Users, Then Keep Revisiting

Once a persona is drafted, test it against people you have not spoken to yet. If your persona describes a “tech-anxious hawker stall owner” but three new interviewees are running their own Instagram storefronts, your persona needs updating, not defending.

Personas are not sacred documents. They are working hypotheses that should shift as your evidence grows, and treating them as fossilised fiction is a common reason work misses the mark.

This discipline matters beyond the project itself. It is one of the reasons why most UX designer job applications get rejected: portfolios full of confident, unvalidated personas signal a designer who guesses rather than researches.

So revisit your personas after each research round, retire the assumptions that did not survive contact with real users, and let the evidence lead.

Putting Personas to Work in the Design Process

Here is the hard truth I have seen too often: a team spends weeks crafting beautiful personas, presents them once, then never opens the file again. A user persona only earns its keep when it shapes real decisions, not when it decorates a slide deck.

Let me show you how I actually put personas to work day-to-day.

Prioritising Features and User Journeys

When I sit down to plan a release, I map each persona to their journey and ask which moments cause them the most pain.

Picture a DBS or OCBC-style banking app team debating account onboarding. If your primary persona is a time-poor working parent who wants to open a savings account during a lunch break, then a fifteen-step verification flow is a direct threat to her.

That single insight helps the team prioritise. Instead of building a shiny new feature, they decide to simplify onboarding first: pre-fill fields using MyInfo, cut redundant confirmation screens, and defer optional steps until after the account is live.

The persona turns a vague argument about priorities into a concrete question: which step is blocking this specific person, and how much revenue does that friction cost?

Guiding Wireframes and Prototypes

Once priorities are set, I keep the persona visible while I design. I literally pin the persona card next to my wireframes.

When I am building screens in Figma, I ask whether the layout matches how my persona thinks, not how the engineering database is structured. If you want a fuller picture of how tools fit into this, here is what Figma is used for in design teams and real projects.

For that banking onboarding flow, the persona reminds me to write labels in plain language, surface progress indicators, and offer an obvious way to save and resume. Small choices, but they add up when your user is anxious about sharing financial details.

Aligning Stakeholders and Reviews

Personas are also my secret weapon in design critiques and stakeholder reviews. They shift the conversation away from opinion.

When a stakeholder pushes to add another cross-sell banner during onboarding, I do not argue about taste. I ask, “Would this help Mei Ling complete her account, or does it slow her down when she is already halfway out the door?”

That one question, anchored to a named persona, tends to defuse ego and refocus the room on the user. It is far harder to argue with Mei Ling than with a colleague.

This is where personas close the loop for me:

• Recruit usability test participants who genuinely match each persona, so you are testing with real working parents, not just whoever is free in the office.
• Screen candidates against your persona’s key traits, such as digital confidence, age band, and banking habits.
• Feed test findings straight back into the persona, updating goals and frustrations as you learn more.

When you recruit test users who mirror your segments, your findings actually predict how real customers behave. That is a persona pulling its weight from planning right through to validation.

A UX Persona Template You Can Copy

Now for the part you came for: a user persona template you can lift straight into your own project today. I use these exact fields on real client work, and each one earns its place.

The Fields, and How to Fill Each One

Work through these from top to bottom, and pull every entry from your research notes, not your imagination.

• Name and photo: A human placeholder so the team stops saying “the user”. Weak: “User A”. Strong: “Auntie Sarah, 58” with a stock photo that fits her.
• Role and context: What she does and the situation she is in when she meets your product. “Part-time tuition centre admin juggling parent enquiries” beats “office worker”.
• Demographics that matter: Only the ones that change design decisions, such as age, HDB versus condo, languages spoken, or CPF life stage. Skip income if it has no bearing on your flow.
• Goals: What she is trying to achieve. “Renew my parents’ MediShield coverage in under ten minutes” is testable; “wants a good experience” is not.
• Motivations: The why beneath the goal, often emotional. Peace of mind, saving face, not troubling her adult children.
• Frustrations: Real friction points quoted from interviews. “The last portal logged me out mid-form” is gold.
• Behaviours: Observable habits, like checking on mobile during her lunch break, or only trusting official gov.sg links.
• Tech comfort: Low, medium, or high, with a note. “Confident on WhatsApp, nervous with Singpass MFA.”
• Preferred channels: Mobile app, physical branch, hotline, or a WhatsApp helpdesk.
• Key quote: One line in her voice that captures her mindset.
• Design implications: The so-what. Turn each frustration into a directive, such as “keep sessions alive for 30 minutes”.

A good entry is specific and traceable back to a real interview. A weak entry is a guess dressed up in demographics.

A Completed Singapore Example

Name and photo: Priya, 34, smiling in a hawker centre selfie.

Role and context: Preschool teacher applying for a CDA co-savings top-up on her phone between classes.

Demographics: 4-room HDB in Punggol, English and Tamil, mother of two under six.

Goals: Top up her child’s CDA before the monthly deadline without visiting a branch.

Motivations: Maximise the government matching, avoid missing free money.

Frustrations: Confusing bank redirects, jargon like “co-savings cap”, forms that reset when the screen locks.

Behaviours: Uses her phone in short bursts, screenshots confirmation for her records, asks her husband to double-check.

Tech comfort: Medium. Comfortable with PayNow, wary of anything asking for OTP twice.

Preferred channels: Mobile web and the bank app; hotline only as a last resort.

Key quote: “Just tell me plainly how much I need to put in and by when.”

Design implications: Plain language labels, a clear deadline banner, autosave, and a downloadable receipt.

Keep It Living and Shareable

Build this in Figma so it sits next to your wireframes, or in a simple Google Slides file that the whole team can open in a meeting. If you want a head start on layout, browse the best Figma templates to kickstart your designs.

Then treat it as a living document, updating quotes and frustrations as fresh research comes in, not a poster you print once and forget.

Keeping Personas Alive as Your Users Change

The mistake I see most often: a team runs a big research sprint, produces three beautiful user persona documents, prints them on foamboard, and then never touches them again. Two years later, those personas describe people who no longer use the product.

A persona is a living artefact, not a one-off deliverable. The moment you treat it as finished, it starts drifting away from reality.

Set a Review Cadence

I recommend building persona reviews into your product rhythm rather than leaving them to chance. In practice, that means two triggers working together: a calendar-based one and an event-based one.

The calendar cadence is simple. Revisit your personas at least once a year, and lightly at every major release, to check whether the assumptions still hold.

The event-based triggers are the ones that genuinely demand an update, because they signal your actual user base has shifted:

• Entering a new market or segment, such as expanding from Singapore into Malaysia or Indonesia
• Shipping a feature that attracts a different kind of user
• Noticing behaviour in analytics or support tickets that no longer matches the persona
• A change in how users are acquired, for example, a new grant or scheme funnelling in a different crowd

A Singapore Example: When Your User Base Quietly Changes

Picture a platform that helps hawkers and small SMEs go digital. Early on, its personas might have skewed towards younger, digitally confident owners who signed up on their own.

Then adoption shifts. As IMDA’s SMEs Go Digital programme pulls in merchants who previously avoided anything online, the platform suddenly serves a lot of less digitally confident users, some of whom struggle with logging in, let alone dashboards.

If the personas still describe the confident early adopters, the design team keeps optimising for the wrong person. Onboarding stays too complex, and the newer merchants churn silently.

That is the cost of skipping reviews. Your product drifts towards a user who is no longer your majority.

Version and Retire Your Personas

To keep everyone aligned, treat personas like any other shared asset that changes over time. Give each one a version number and a last reviewed date, and store the current set somewhere the whole team can see, whether that is Figma, Confluence, or a shared drive.

That way nobody argues over a screenshot from a slide deck three quarters old.

Watch out for zombie personas. These are the ones that linger in the file system, unused and unloved, quietly misleading whoever stumbles across them. If a persona no longer reflects a real segment, either update it or archive it clearly, marked as deprecated, so no designer builds tomorrow’s feature around yesterday’s user.

Conclusion

If you take one thing away from this guide, let it be this: a user persona is only as good as the research behind it. Built on real evidence, it turns vague assumptions like “our users are busy professionals” into shared, testable direction the whole team can rally around.

We started by gathering inputs from interviews, support tickets, and analytics, then clustered those findings into patterns rather than guessing at them. From there we built each persona around behaviours and goals, validated them against fresh data, and treated them as living documents to revisit as your product and audience shift.

That last step matters more than people expect. A persona left untouched for two years quietly drifts back into fiction, so a regular review keeps it honest.

I would encourage you to download the template and adapt it on your very next project. Do not aim for a polished artefact on the first pass. Sketch a rough draft from what you already know, then let real user conversations sharpen it.

Before you ship your personas to stakeholders, run one final check: does every claim trace back to an actual observation, or did an assumption sneak in? That single question has saved me from more than a few embarrassing misfires.

If you want to build this muscle properly, hands-on and guided, consider learning research-based UX design at the WSQ User Experience & User Interface (UX UI) Design Essentials course. It is SkillsFuture-supported, so you can offset a good part of the cost while you practise the full workflow on real projects.

Personas are where empathy meets evidence. Get them right, and every design decision after becomes easier to justify.