Understand your users with personas

While personas can be a great tool for understanding your users, they’re not always the right tool to use.

Don't use personas if:

• You don’t have research or evidence to inform and support assumptions. You should do research and speak to potential users first.
• You’re evaluating a production service or product. Instead, do usability testing or user research.

• Research team
• Designers that will be using the personas in the future
• People who can help you understand your users/stakeholders (users themselves, program stakeholders, holders of data)
• People who will be making decisions based on the personas (designers, project collaborators, developers, etc.)
• Any other eager participant with a vested interest in the success of your project

Step 1: Objectives and Planning

Determine the requirements for the persona(s): The first step is to determine why you need personas. There should be a specific need to make the most of the final product. Personas need to be context-specific. They should focus on the user behaviors and goals of a specific area of your product or service. Personas should not be reused by groups within the same organization that focus on different products/services. For example, an inspector will have different goals and needs during pre-inspection compared to later in their workflow.

Determine the persona archetypes: A persona does not represent the entire population of your users. It needs to focus on a specific archetype of the user population. This is why you may need to create several personas to capture a greater representation of your users.

Each persona should represent different key goals and challenges that your product or service aims to solve. For example, previous research found that while TC inspectors have many similar job functions, they have different tools to when working on water, land, and in air. As such, the research team planned to interview marine, surface, and aviation inspectors to account for all environments.

The main difference between your persona archetypes should be behavioural characteristics, like differing needs, not demographic characteristics, like age. For example, if there are no age-specific goals or challenges faced by inspectors, then there is no need to create separate personas by age group.

Step 2: Gathering evidence

Once you’ve determined your objectives and your user groups, you’re ready to start collecting information for your personas.

To achieve the most accurate personas, the information you collect should come from user research. You can do this by conducting interviews with your users/user groups (see the play Interviewing your users). While it’s not always possible to do user research, it’s the gold standard. You should try to do user research to ensure accurate, validated personas.

If you can’t do user research, there’s still information that you can collect about your users through other means to create a preliminary persona. This could be gathering marketing data on your users, or interviewing stakeholders who know your users. Any other methods you can think of to learn about your users is valid. The personas you create from these sources can serve as a placeholder until you can do user research to validate your findings.

Step 3: Creating the personas

Once you’ve finished conducting your user research, you’ll have a large amount of data and findings. You’ll need to make decisions about what information is most relevant to your target audiences. You can still use Information you omit from your personas in other artifacts, like customer journey maps.

What not to include in your persona(s)

Your personas should be about one page each and should only include the necessary information

Career Foundry mentions that:

As a rule of thumb, avoid adding extra details that cannot be used to influence the design. If it does not affect the final design or help make any decisions easier: omit it. While you do want to build up a realistic character, there’s no need to include pointless details that won’t influence the final design. If you’re designing a holiday-booking app, it doesn’t make sense to include information on Savannah’s favourite TV programs or what football team she supports. So, only include details that serve a design purpose!

Persona outline and examples

Renowned UX specialist Kim Goodwin outlines that personas should be “1–2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few (very few!) fictional personal details to bring the persona to life”.

Let’s break these sections down:

• Behaviour patterns: how does the person goes through their day. What’s their productivity ritual
• Goal and motivation: what is the person trying to achieve, and why?
• Needs: what needs does the person have in the context of motivation and goal?
• Tasks: what kind of activities does the person carry out and why?
• Skills: what skills does the person have? How technologically literate are they? Are they an expert in Excel or do they spend most days writing?
• Environment: what is the person’s physical and social context?
• Interaction/community: who are the people and communities the person is interacting with, and why?
• Fictional personal details: name, age, personality trait

Validating personas

Once you’ve created your first draft personas, you need to validate them with your users and stakeholders to ensure they’re accurate.

A great way of doing this is to use surveys to reach more users to confirm your findings. Surveys are quick and because they’re unmoderated, you can send a survey to many more users than you would reach through interviews.

Other ways to validate your personas:

• Get wider subject matter expert approval – With your persona in hand, share it with as many subject matter experts as you can. See what feedback you receive, given their different expertise and backgrounds
• Complexity – Personas are a representation and as such, generalized and sometimes inaccurate. If you add more information and more accurate data, people will view your persona as fact rather than a guide. Don’t do this. Instead, keep your persona simple.
• Use quantitative data – if you include accurate quantitative information in your persona, validate the persona against the facts you collected during the process. Question everything.
• Look for self-identification – If you interviewed subject matter experts or users to generate your persona, interview users again after you’ve created your persona. Make sure that you interview the same and different users. See if they identify with one of the personas you have created. If none of your users identifies with a persona, then your persona isn’t valid. You’ll usually get one person who doesn’t identify with a persona. That’s ok.

Step 4: Using the personas

Creating a persona scenario is a valuable way to see how people might use your solutions, based on their context, unique needs and motivations. Scenarios capture what users would likely experience as they proceed toward using an ideal solution.

Scenarios are a flexible tool for ideation, iteration, and usability testing. They often expose vital areas to test. Scenarios help teams discover user needs and can be used to keep stakeholders on track with a shared vision.

Scenarios can be highly visual narratives or simple written statements. Ensure you:

• Provide context – this should include:
• Who – details of the persona
• What their goals are
• When they might perform tasks (including obstacles)
• Where they might do these (including obstacles)
• Why they want to do things
• Focus on the bigger picture – what leads up to the interaction, what impact the user’s world and influences how they interact with a solution (e.g. cultural context), and what they need before using the solution (e.g. information).
• Make the scenario simple for people without technical backgrounds – This allows everyone including stakeholders to relate to the scenario
• Keep the scenario centered on the user – Keep your ideas around solutions grounded in the reality of the users’ context.

Here’s an example of a user scenario:

“Pat, 42, is a senior inspector with Transport Canada. They work in the marine sector and are highly skilled, organized and diligent. They need to document notes and details while on board a naval vessel. They’ve tried using smartphones and tablets but are frustrated by the lack of connectivity and technical issues. They’ve resorted to pen and paper. When they return from an inspection, they typically transcribe their physical notes into the secure system.

Ideally, Pat would like an app that allowed them to capture notes and details directly into the secure system while on site. They’d love the app to be simple, easy to use, especially with one hand, and available on a rugged, waterproofed device that included a built-in camera and flash.”

Step 5: Maintaining the personas

As roles, capabilities, and technology advance, you should revise your personas throughout the design/product lifecycle. This ensures they remain relevant. You might have to additional research to determine if there are significant changes to your users’ needs. You might also have to create additional personas, or eliminating ones that are outdated.

TC Personas Framework

UIE – Perfecting Your Personas

UX for the Masses – 5 Ways to use personas in your projects

Adobe Blog – Putting Personas to Work in UX Design: What They Are and Why They’re Important

This is Service Design Doing – Creating Personas

This is Service Design Doing – Creating Personas, part 2

Atlassian Persona Template

Career Foundry: How to Define a User Persona

Materials on this website were produced and/or compiled for the purpose of providing Canadians with access to information about the programs and services offered by the Government of Canada. It is subject to the following Terms and conditions.