Creating User Personas
This article describes the characteristics of effective user personas, and how they can be used to guide teams to make product decisions that match the needs of the users.
User Personas are a written way of approximating your understanding of your diverse users and their goals and motivations for using your product. User personas allow you to summarize what you know about your current users and what new users that you want to target in a memorable way. User personas also give an easy customer template for your entire team to refer to throughout the iterative process of design and development.
In order to come up with your user personas, you should start with the following question: What are the characteristics of your target audiences and how do these characteristics shape how your users will engage with your website?
Your first instinct might be to say that your target audience is everyone. This is a natural starting point, but it is unhelpful for a few reasons:
- First of all, “everyone” probably isn’t your true audience. Is your site and customer support available in every language? Does your site accept different currencies? Can your team ship the product to all countries?
- Second, even if your target audience really is everyone, not everyone is going to use your product in the same exact way. Figuring out which groups have unique motivations and needs that you will want to target is the best way to grow your users and get to the target audience of “everyone”.
Thinking about the user and what they want is natural for all members of the team, whether they are marketers, designers, developers, or customer support. If you are creating a product without written user personas that have been discussed and agreed upon as a team, everyone on your team will have their own assumed and imagined set of users, and those perceptions might be conflicting or inaccurate.
For example, let’s imagine that you are on the Product Design team for a food delivery app called FastEats. Here is an example of a potential user persona:
User Persona Example
The Kitchen Avoider
“I just want to get through my week without thinking about cooking and groceries.”
Tim rarely cooks, and he uses FastEats as a replacement for fast food and snacks. Tim is looking to spend about $10-12 per meal before tax and tip and uses the app about 3-4 times per week. When choosing his meals, he’s more concerned about taste and price than nutrition. About half of his purchases will happen after the dinner rush hours, between 9 pm and 1 am. He uses the app regularly throughout the year and would appreciate some loyalty program, or a premium program that would allow him to waive delivery fees or restaurant minimums by paying a set amount each month. He is a repeat customer at about 5 nearby restaurants and is not looking for new suggestions.
Entry point: Tim heard about FastEats from his friends, and then searched for it using the App store.
Device: Tim keeps the app on his iPhone, but he might use the web application if he is doing something unusual (like chatting with customer service).
Goals: Wants fairly standard fare (burgers, tacos, pizza) delivered to him within an hour.
Frustrations: Doesn’t want delays, and doesn’t want minimum order limits that are greater than $12.
This example is shorter than what most companies would use for a user persona, but it can still help you start to think about what real user personas would look like.
Turning Research into Stories
User personas should be based as much as possible on user research and market research. Note the estimate from the example above that Tim is looking to spend about $10-12 per meal before tax and tip. This should be based on a finding from user research.
If your app is brand-new, this is probably market research.
- Ex: “Tim” currently eats 3-4 times per week at fast-casual restaurants, where the average bill is in the $10-$12 range. Your app wants to target this kind of customer, because of their repeat purchases.
If your app already exists, this should come from user research:
- Ex: 30% of users under age 25 will decline to make a purchase or remove items from their cart if their bill goes over $15.
Personas are really just a way of turning research into stories, so that it’s easier for your team to stay on the same page about your user needs, and keep the needs of the user in-focus at all times. The complete market and user research that your company has conducted is likely too complex and nuanced for the entire team to consider on a day-to-day basis. But many team members could ask: “Does this work for Tim?” or “Does this work for The Kitchen Avoider?” when they are adding a new feature.
If you don’t have any users yet, or any data about the market you wish to enter, you can still make preliminary personas. But make sure that you prioritize getting data as soon as possible, and that you use real data to revise your preliminary user personas.
You should be able to get basic data about your users when they visit your site, and for how long they visit your site, with a web analytics tool like Google Analytics. This is a good basic first step that can help you get started at conducting user research.
Multiple Needs, Multiple Personas
Often times, an app needs to work for many different kinds of users in order to be successful. There will not be one persona, but many different personas, and keeping track of your diverse users and use-cases in a memorable, narrative form will help you make sure that your product is meeting everyone’s needs as you grow and expand. For example, eBay needs to work for both buyers and sellers. This is a fundamental business need, as the marketplace falls apart if the site doesn’t work effectively for both buyers and seller.
Let’s go back to the FastEats example. Here are a few more personas that this app might want to target:
The Clean Eater
“I want to explore healthy options in my neighborhood.”
Lily found FastEats through a billboard advertisement. She’s an early adopter of new products, but she is likely to cancel within one or two months if she is unhappy with the product, or with customer service. Lily is cost conscious, but she is also nutritionally-conscious, but she’s willing to pay more (up to $15-20 per meal) for healthy and sustainably produced food. She needs a wide variety of healthy options in her delivery area in order to keep using the FastEats. She follows health food trends, and she wants to be able to purchase acai bowls and green smoothies from the app, as well as more traditional fare.
Her purchases will be evenly divided between dinner time on weeknights, and when she’s entertaining friends on weekends. Her purchases have a clear seasonality: she will order more frequently in the winter when she stays home and orders in, and less in the summer, when she is more likely to spend more of her food budget going out to restaurants. Lily lives in NYC, and has dozens of restaurants using FastEats within less than a mile.
Entry point: Lily downloaded the app through a social referral program through one of her friends.
Devices: She keeps the application handy on her Android smartphone. She wants to be able to do everything that she needs just with the mobile app.
Goals: Wants healthy, local options delivered to her.
Frustrations: She wants to know information about nutrition and sustainability within the app.
The Data-Driven Restaurateur
“I want to expand my customer base, and I want to see the data.”
Colleen is a restaurant owner of a local chain that has three branches. She sells her food on your platform because it helps her coordinate delivery orders and increases the volume of her business. She uses FastEats because it brings in new customers and makes her life easier. She can expand her delivery business just by hiring more delivery staff without needing extra help to answer the phone and provide customer support. She’s price sensitive; if FastEats starts charging a commission of more than 15%, she might set up her own mobile application or switch to a competing app. She wants your application to deliver repeat customers, and in order to assess this, she wants to be able to see and analyze her FastEats sales easily using the business dashboard.
Entrypoint: Colleen’s business was identified by the business-to-business sales team.
Devices: Her restaurants are set-up with the iPad to receive and manage orders, but she uses the web application to look at the business dashboard as she is reviewing her company’s financial statistics.
Goals: To make more money than she would without using the app, with as few additional costs or hassles as possible.
__ Frustrations:__ Colleen is aware that due to the FastEats commission, her margin is lower for purchases made through the app. She wants to track her revenue very carefully to make sure that this continues to be a good investment for her.
The Prompt Deliveryman
“I want to make my deliveries on time, and I want to get good tips.”
Bryant is a deliveryman for Colleen’s restaurant. To help him do his job effectively, FastEats needs to block users that are outside the delivery range, and provide automated time estimates based on his backlog that he can manually adjust. His income is partially dependent on tips, so if customers aren’t given accurate wait-times, his own income will suffer.
He has worked for Colleen for three years, and she listens to her staff when making business decisions. If Bryant and other staff members aren’t happy with their user experience on FastEats, she will consider switching to a competitor.
Entrypoint: Bryant joined the app when his employer started using it.
Devices: Bryant uses his personal smartphone to connect to the app and receive updates.
Goals: He wants to make all of his deliveries on time, so he can get his tips.
Frustrations: Bad wait time estimates, which are prone to happen during peak hours, will hurt his tips.
The Busy Mom
“I want a break from cooking for my kids once a month.”
Natalia is married and lives with her husband and their three kids. She works in advertising and usually gets home around 6 pm. Natalia and her husband split most domestic chores, but she handles more of the cooking and she just doesn’t always have time or energy to cook after work. She uses FastEats less frequently than most of the users (about 1 or 2 times per month) but since her orders are for 5 people, her average order is about $80-100. It’s important to her that restaurants place their entire menu on the app, including the kids menu. Because her whole family is waiting for dinner, Natalia has less tolerance for late deliveries than other users. This is tricky because she lives in a less dense section of a mid-size city, so the restaurants near her are within a 5-mile radius rather than a 1-mile radius.
Entrypoint: Saw the service on a TV ad, downloaded it from the app store.
Devices: Uses the smartphone app and the web app with equal frequency.
Goals: To feed her family once or twice per month, simplifying her life when it’s busy at work.
Frustrations: Delays are a big problem because her kids will complain. There aren’t as many options in her area.
After creating personas such as these, when you come across a decision, you can ask yourself: What makes the most sense for Natalia? How about Bryant? Is this going to piss off Colleen?
A Note on Demographics and Diversity
It’s good practice for the names and images that you use in your user personas to be diverse with respect to age, gender, race, ethnicity, etc. You most likely want your product to appeal to users across these demographic groups.
However, it’s important not to assume reductive differences in how different demographics use your site or application.
User personas should remain grounded in how people use your app, and there are likely many roles that will influence this more directly than demographics. As we saw from the FastEats example, the needs of the user were largely defined by their role (customer, business owner, etc.) and their motivations for using the product.
Start by defining use-cases and user motivations, rather than trying to define a persona for every demographic group. Keep your personas grounded in real user research.
Common Sections for User Personas
- Nickname for the type of user they are (“The job seeker”, “The daily user”, “The homeowner”, etc.)
- Realistic name
- Job title
- Key characteristics
- Goals or Motivation
- Entry Point (how did they find your site or product?)
- Quotes about what they are looking for (these might come directly from real user interviews)
- Frustrations or pain points
- Seasonality (do they use your product more during one time of year than another)
User personas look a bit different from project to project and company to company, and that’s okay!
Regardless of exactly what they look like, useful user personas will:
- be founded on user or market research
- include some personalizing narrative that makes them catchy to remember
- be general enough to be widely applicable to product decisions
- cover the main use-cases that make reaching your business or product goals possible