Table of Contents

User Personas Guide

The Definitive Guide to User Personas

You’re probably familiar with the concept of buyer personas. (If not, you can learn everything you need to know about buyer personas from Pragmatic Institute.) But just as important are user personas.

Developing user personas is critical for engineering teams to have context when building products and for customer experience and support teams to attune themselves to customer needs.

Understanding user personas and how to create them for your product will help you better understand your market and align internally to ensure you develop a product people will actually use.

What are user personas?

User personas are short descriptions of fictitious, archetypical customers who are most likely to be the users of your product. They may or may not have a say in the purchasing decision (although generally not). Essentially, they’re hypothetical biographies of each type of user you’re developing your product for.

User personas can be as broad or as specific as you’d like them to be. For example, many companies choose to really paint a picture of their various types of users and assign each persona a name, age, race, ethnicity, gender, job title, likes/dislikes, etc. They may even include a stock photo of what the person might look like in real life. Other companies choose to leave out demographics to keep from pigeonholing their users and making assumptions about them that may or may not be true. Such personas may focus more on the users’ role within a company, who they report to, challenges they face, how they’re evaluated and so on.

Why user personas are important

User personas are a great way to summarize qualitative and quantitative research and to share the results of user research across the company. In addition to development, you’ll want to share that information with marketing, sales, company trainers, technical writers, HR and other stakeholders.

Everyone benefits from keen user personas:

The users themselves benefit, of course, as they get better products.
Development’s work is more appreciated and receives better feedback.
Software testers have the capability to test realistic scenarios.
Data analysts know which questions to ask.
The UX team is no longer solely responsible for the user experience; responsibility is shared.
Technical writers can create user documentation that addresses real problems.
Managers understand how users’ behavior influences the company’s KPIs.
Product owners have accurate data to ensure that their products succeed.

By combining qualitative and quantitative research, you’ll gain an accurate picture of your users that allows you to create user personas that will resonate with teams across your organization.

Who owns the development of user personas?

While sales and other stakeholders may provide insight into user personas, the product manager should own the process of doing the research and developing the personas. That’s because you are the person who should best know your product’s users. Plus, some of the information you’ll use to inform your user personas is the same information you’ll collect when identifying your market problems, competitive landscape and market definition.

Of course, it will then be important for you to gain buy-in from the executive, sales, development and marketing teams. That should be fairly simple, however, when you present the research you’re going to conduct to develop your personas.

How to develop for your product

While there may be some overlap between your buyer personas and user personas, it’s important to approach each separately as they have their own development process. Whereas much of the information for your buyer personas can be obtained by interviewing potential buyers, the first step of creating user personas is observation.

Observe users of all experience levels

Some problems can be discovered only in the user’s natural environment. Thus, the first step in understanding your users is to shadow experienced users for a day. People like to be treated as experts and are usually happy to share their knowledge. These shadow days are particularly helpful in understanding what your product needs to do for your users to be able to accomplish their goals and why a “less cool” feature may need to be prioritized in the backlog. It’s also how empathy is born.

But even with shadowing, problems may remain hidden, especially when experienced users are involved. People can adapt to anything, even inefficient products and bad software. They will find workarounds to complete their tasks. That’s why getting a fresh perspective helps highlight these invisible issues. The views of new and experienced users may be surprisingly different, so be sure to shadow junior employees as well and/or attend new-user training programs when available.

Why is this step important? Real users don’t follow testing scripts. They just want to get their job done, whatever it takes. It often seems illogical. Your team may ask why users would ever do things a particular way. They can’t understand the pressure real users experience if they haven’t spent any time with them.

You may be wondering how many potential users you should shadow. Ultimately, that’s a decision only you can make. We recommend conducting as many as it takes to begin seeing patterns develop. This often falls somewhere in the neighborhood of 10 to 20.

But don’t stop there. Encourage users to visit your environment, too, and put themselves in your shoes. Hold a brainstorming session. They may spot problems in your way of thinking that are invisible to you and wouldn’t be discovered during the shadow days. Remember, this is a discovery mission, not a sales call. Learn our best practices for conducting user interviews in our Uncovering Market Problems webinar.

This shadowing and user interviews, called qualitative research, help build important relationships and great products. It also can be a lot of fun. There is only one problem with it: It’s impossible to interview every user, so this type of research doesn’t prove anything. That’s next.

Identify trends

Once you begin to identify themes from your one-on-one interviews, then you can start grouping types of buyers together. Who has similar job roles, responsibilities and concerns? Which people are facing similar problems? Who is trying to accomplish the same thing as someone else?

Put together an outline of your suspected buyer personas. Next, you’ll test your hypotheses.

Survey customers

Once you have some preliminary user personas, now it’s time to confirm (or disprove) them. Here is where quantitative research helps. If there is any kind of data about your users, use it. Visualize data wherever possible, as it often triggers new questions. And be sure to tackle questions from different perspectives to avoid confirmation bias. (Testing an antithesis usually mitigates the problem.)

If quantitative research is not already available, conduct your own. Surveying current users via an online tool or with the help of a partner like UserTesting will help you validate your hypotheses. This combination of qualitative and quantitative research helps answer exactly what it is that happens and why people do it. It helps build products with the users in mind, products that get the job done.

Write user persona descriptions

Now it’s time to get to writing. Summarize your findings into three, four, five—however many personas you need to represent the themes you uncovered in your research. We can’t give you a specific number—the number of user personas you create will depend on your market—but it’s common to have somewhere around three to five user personas per product. Just be sure to not go overboard. Having too many personas may mean you’ve failed to truly identify your target users and may end up leading to further confusion and disorganization.

Gain buy-in

Once you’ve nailed down your user personas, you’ll need to gain buy-in from executives and key stakeholders, including sales, marketing, development and so forth. It’s crucial that everyone on the team be on the same page when it comes to who your users are. Be sure to present your research along with the personas to illustrate how and why you arrived at the personas you did.

Share, share, share

Finally, share your user personas far and wide (internally only, of course; they’re proprietary information). Host meetings, produce written summaries and discuss your personas often. Or consider doing what British online grocery giant Ocado Technology did with their user personas: Establish a habit that every member of the team refers to the user personas when making decisions about product development and feature releases.

Learn More

Examples of user personas in action

So how do you use your user personas once you create them? In lots of ways. First and foremost, they should inform the development of all new product and features launches—which products to pursue and which features to include. You’ll also use them to craft realistic testing scenarios to reduce the number of updates needed on the backend.

Of course, there are other ways to use user personas as well. Get inspired by the following examples of how two companies have put their user personas to good use.

Box

Box develops and markets cloud-based content management, collaboration and file-sharing tools for businesses. With a customer base of 97,000 that covers every industry and type of business out there, Box had to find some way to organize its product management and development teams. They decided to organize by user persona.

Box has three main user personas:

End users, or the folks who interact day to day with Box products and clients
Administrators, who operate Box behind the scenes for a company
Third-party developers, who have questions like, “How quickly do you have the SDK in my language?”

“And so for each of those, we’re designing and thinking through the experience,” said Jon Fan, VP of product management at Box, in our User Personas in Action podcast. “And I would say the interesting challenge for us is to unify those experiences into what will look like and feel like a single product but gives a different personalized set of capabilities to each person who’s using the product.”

Hear more about how Box relies on user personas in User Personas in Action.

Ocado Technology

As the world’s largest online-only grocery retailer, Ocado Technology reaches 70% of all British households. The company develops its systems for processing and delivering because it couldn’t find the solutions it needed off the shelf. With such a broad customer base, Ocado created user personas.

For example, the company’s internal user personas, Luke and Robert, are both delivery drivers responsible for delivering groceries within one-hour time slots. While they share a common goal of delivering groceries to customers, their motivations and frustrations are different. Why does it matter?

“Most people we hire are like Luke but become more like Robert over time,” wrote product owner Anna Miedzianowska in a blog post for Pragmatic Institute. “As they gain experience, their perspective changes. Roberts provides excellent customer service and knows the job better than anyone. They have navigated through the complex process and are happy to share the tricks they’ve learned.

Miedzianowska and her team use the things that frustrate and motivate Lukes to help them become Roberts more quickly, meaning they would perform better, experience higher job satisfaction and be less likely to leave the company. The result would be better employee retention, less time and money spent on initial training and less need for Roberts to help Lukes (or cover their mistakes). In other words, helping Lukes ultimately keeps customers happy because it supports the continuation of excellent service. Helping Roberts means providing ongoing support and further improvements to job efficiency.

Involving various departments in their research—especially service delivery, data and HR—not only enriched the details for each persona but also resulted in the discovery of a third persona: Albert. Alberts are similar to Lukes, but don’t become Roberts over time. They find the job too complicated because they don’t have any relevant experience on which to build. They give up quickly and leave the company. Knowing where Lukes and Alberts struggle lets Ocado question the most complex parts of the process and focus on things that matter.

To work, these personas need to be properly communicated. Sending an email with persona descriptions to the team is not enough. A poster on the wall is not much better. People get used to them quickly, like any new piece of office furniture.

“Instead, our personas are real-life size cardboard cut-outs, residing close to our desks, where we can always see them,” Miedzianowska says. “They come to our sprint review meetings and they attend workshops with real users. They even have email addresses and wear real clothes. People stop beside our office and ask about them. That directs more attention to our users and triggers conversations that wouldn’t happen otherwise. And my team doesn’t say, ‘The users want the latest AngularJS on the UI,’ anymore. They say, ‘Robert struggles with out-of-date information; he needs it to be refreshed in the background.’”

Persona archetypes vs. stereotypes

In our discussions of personas, we often get tripped up by the terms “archetype” and “stereotype.” They may be similar, but it’s important to understand the difference so as to not conflate the two. At Pragmatic, we think of them like so:

An archetype is used to inform
A stereotype is used to demean

So, a persona is an archetype (but not a stereotype) for the ideal user of our products. Be sure to describe only relevant information in your personas and not to make assumptions about any particular group of people.

Learn more about user personas

Understanding user personas will help you better understand your market and ensure you develop a product people will actually use. Learn more about how to develop user personas that lead to better products and more in Pragmatic Institute’s Build course today.