Personas in UX Research

Most businesses know that the key to success today is designing user-centered products and services rather than technology-centered ones. Personas are a great tool for creating solutions based on user goals, behaviors, motivations, and needs.

One of the most significant advantages of using personas is that they build empathy and make users memorable among team members. Personas become imaginary team members that help drive design solutions with users' needs at heart.

Despite all the advantages of introducing personas in your design process, you can only effectively use personas in teams where stakeholders understand the persona's importance and user-centered design. Otherwise, it's too expensive and time-consuming.^[1]

What is a persona?

A persona is a fictional yet realistic description of a typical or target user of a product. It doesn't represent a real individual, but it should feel like one.

Personas are built from real research. Interviews, field studies, and other discovery methods reveal patterns across users, and a persona synthesizes those patterns into a single, memorable character. That character captures user needs, goals, beliefs, and pain points. It may also include context like how users interact with the product, whether by choice or because their job requires it.

The real value of a persona is focus. Design teams work better when they're designing for someone specific rather than a vague idea of "all users." A persona gives the team a shared, concrete reference point they can return to throughout the project.^[2]

The purpose of personas

Personas serve a deceptively simple purpose: they keep users real when the team isn't talking to them. Without a persona, "the user" becomes whoever is loudest in the room: a product manager's assumption, a stakeholder's gut feeling, or a designer's own preferences.

A well-built persona does four things for a team:

• Builds memory. A named character is easier to hold onto than a behavioral data cluster.
• Builds empathy. When designers can picture who they're designing for, they make decisions in that person's interest, not their own.
• Creates a shared reference. One document aligns researchers, designers, developers, and stakeholders around the same understanding of who the user is.
• Anchors decisions. When priorities conflict, the persona gives the team a principled way to ask: which option better serves this user?

Teams that refer back to personas throughout the project, not just during kickoff, get the most out of them.

Pro Tip! Personas can work as templates for recruiting user research participants.

UX personas vs. marketing personas

UX personas and marketing personas both represent people, but they answer different questions. A UX persona asks: what does this person need to accomplish using the product? A marketing persona asks: what does this person need to hear to make a purchase decision?^[3]

The distinction matters because users and buyers are not always the same person. A manager who approves a software license for their design team is a buyer. The designers who use it every day are the users. Their goals, frustrations, and success criteria differ, and both sets of needs matter.

• UX personas are built from qualitative research: interviews, observations, and usability studies. They focus on behaviors, goals, and pain points that affect how someone uses the product.
• Marketing personas are built from market research and customer data. They focus on motivations, preferences, and decision triggers that affect whether someone buys it.

Neither type replaces the other. On most product teams, designers work from UX personas while marketing works from buyer personas, each informing a different part of the product strategy.^[4]

When to create personas

Create personas as early as possible in a project, ideally during the research phase before design begins. Starting early means your team is designing around real user data from the first decision, not retrofitting a persona onto work that's already underway.

Personas should be grounded in research: interviews, field studies, surveys, and card sorting all generate the behavioral data that makes a persona useful. But research isn't always available at the start. In that case, teams can build a proto-persona based on internal assumptions and existing knowledge. A proto-persona is a placeholder, not a finished artifact. It captures what the team currently believes about users and makes those assumptions visible so they can be tested.

As research comes in, update the persona to reflect what you actually found. Discard assumptions that didn't hold up, add nuance where the data surprised you, and keep refining. A persona based on outdated or unvalidated data can be worse than no persona at all, giving the team false confidence in who their users are.

Pro Tip! Proto-personas work best as hypotheses. Share them with the team explicitly as assumptions, not conclusions.

Personas should be iterative

A persona is a snapshot, not a permanent record. As your product evolves and new research comes in, the persona needs to keep up.

Two structural changes signal it's time to revise. If two personas have grown more similar and no longer represent meaningfully different users, merge them. If a persona has become too broad to be useful, distinct behavioral patterns within it may justify splitting it into two.

Beyond structure, watch for two types of change that indicate the underlying data is going stale:

• Business and technology shifts. If your product or competitors' products have changed significantly, users' goals and tasks have likely shifted too.
• Changes in user behavior and demographics. Monitor analytics, usability testing, and research for signs your user base looks different from when the personas were built.

Most teams update personas every one to four years, though teams that revise more frequently, quarterly or more, tend to rate their personas as significantly more impactful.^[5]

Pro Tip! When updating, communicate what changed and why. Remove old versions so the team isn't working from outdated copies.

What to include in a persona

Build personas as a team, not solo. Involving researchers, designers, and product managers in the process means the findings get challenged, assumptions get surfaced, and the final persona is more likely to be trusted and used.

Start by analyzing your research data, grouping similar behavioral traits, and removing details that have no bearing on design decisions. Every element you include should earn its place: if it would not change a design decision, leave it out.

Most personas include four types of information:

• Name and image. A face and a name make the persona memorable and easier to reference in design discussions. They aid empathy, not decoration.
• Demographics. Age, location, occupation, education, and technical skills, included only when relevant to how someone uses the product.
• Psychographics. Goals, pain points, behaviors, and motivations. This is the most important layer: it captures what drives users and where they struggle.
• A tagline or quote. A short statement that distills the persona's attitude and primary goal. It does not need to be a verbatim quote from research, but it should feel authentic.^[6]

Pro Tip! Avoid using images of celebrities or unrealistic images. Photographs should reflect your persona's age, gender, ethnicity, and personality.

What not to include in a persona

Every detail in a persona competes for attention. The more you add, the harder it becomes to remember what actually matters. A persona loaded with irrelevant information does not feel richer, it feels less trustworthy.

The test for any detail is simple: would it change a design decision? If not, leave it out. A persona for a taxi app does not need to list the user's favorite travel destinations. It does need to capture that they value safety and comfort, often book rides in a hurry, and rely on their phone throughout the day. Those details shape decisions. Travel preferences do not.

Context determines relevance. The same detail can be essential for one product and meaningless for another. For example, comfort with technology matters for a consumer health app, but less for a professional developer tool.

Irrelevant details also carry a credibility risk. When teammates spot information that clearly has no bearing on the product, they start questioning the rest of the persona too.

How personas fit into the design process

Goal-directed design is a methodology created by Alan Cooper, introduced in his 1999 book The Inmates Are Running the Asylum. The core idea: good design starts with understanding what users are trying to achieve, not just what features to build. Cooper describes personas as the foundation for all subsequent design decisions.

The process has 6 stages, and personas are most active in the first 3:

• Research. Conduct user interviews, field studies, and stakeholder interviews to collect behavioral data. This is the raw material personas are built from.
• Modeling. Synthesize research into personas. Each persona represents a distinct pattern of goals, behaviors, and attitudes observed across multiple users.
• Requirements definition. Use personas to define what the product needs to do. Teams write scenarios: short narratives of how a persona interacts with the product to reach a goal. Scenarios anchor requirements in real user context rather than abstract feature lists.

The remaining stages cover design framework, refinement, and development support. By that point, the persona goals have already shaped the product structure.^[7]

Base personas on data

A good persona should be based on user research. Research methods help define behavior patterns that suggest goals and motivations, which eventually help formulate product requirements. Research-based personas are more credible to stakeholders and can be used to support design decisions.

If your business lacks the time or the budget to conduct proper research, you can always start with a persona that is based on assumptions. Use competitor analysis, social media conversations, or stakeholder interviews to determine what type of users your product will appeal to. This persona can only be used to test your ideas and should never become a reference point for developing final design solutions. Otherwise, it can lead to creating a product or service that no one actually needs.^[8]

Identify patterns to create your personas

Once your research is complete, the next step is turning raw data into personas. Start by reading through your notes and identifying patterns in how users behave, what they are trying to achieve, and where they struggle.

As patterns emerge, group similar ones into clusters. Look for shared characteristics across:

• How users complete tasks and solve problems
• Their end goals and the contexts in which they use a product
• Motivations, pain points, and attitudes
• Relevant demographics, such as technical skills or role type

Some attributes will overlap across clusters and can be merged. Others will appear too specific or too disconnected from your product to be useful, and can be dropped.

Once you have distinct clusters, compare them side by side to confirm they represent meaningfully different users. If two clusters look too similar, combine them. If one cluster covers too much ground, consider splitting it.

At this point, the clusters become your personas. Add a name, photo, and the specific details that make each one memorable and easy to reference in design discussions.

Limit the number of user personas you use

More personas don't mean better coverage. They mean more maintenance, more competing priorities, and a team that can't remember who they're designing for. Most products need between 3 and 7 personas to cover meaningful variation in the user base without creating distinctions that don't hold up in practice.

The right number comes from your research, not from trying to represent every user type. Two useful filters:

• Merge groups that share the same core goals and behaviors. Separate personas for users who would make the same design demands aren't adding value.
• Drop groups that represent segments too small or too peripheral to influence product decisions.^[9]

When you have more than one persona, distinguish between primary and secondary:

• A primary persona represents the core user group around which the product is designed. Decisions that satisfy the primary are the default.
• A secondary persona represents a group with different needs that still matter. Their needs are accommodated where possible, but don't override the primary.

Most teams work with one primary persona per product area. Secondary personas are optional.^[10]

Pro Tip! When in doubt, fewer personas are better. One well-researched primary persona outperforms five loosely defined ones.