What is a Persona?
A persona defines a typical user of a product. They help you understand the context in which people use the product to help guide your design decisions. Personas originated from Alan Cooper’s work on user-centered design.
An Example
Below is an example persona for the Agile Alliance Submission System.
Reed the Reviewer Persona
When to Use Personas?
Personas are especially helpful when working on products with a significant amount of user interaction where the context in which those users work can greatly influence how they use the solution.
Personas are often a good technique to use in conjunction with user modeling.
Why Use Personas?
Personas provide context for your users to help guide design decisions by providing a name, face, and story for each user role and helping team members understand the jobs users do and the environment in which they work.
Personas do not have to be elaborate. A short description is sufficient. Keep them posted in the team space to remind team members who their users are.
When the team proposes various personas, they establish a shared understanding of who they are building the solution for. As a result, they’re more likely to build a solution that more closely meets the users’ needs.
How to Use Personas?
Once you have identified the user roles that are relevant for your solution, create a persona for each.
Jeff Patton suggests the following characteristics as helpful for a persona:
- Name
- A role or job title
- Quotes in the persona’s language
- Relevant demographics
- Description that reveals goals, motivations, pain points
- Description of primary activities this persona engages in.
Jeff Gothelf and Josh Seiden proposed a couple of different formats for what they call a Proto-persona, a four box and three box approach.
Four Box (as described in the first edition of Lean UX):
- Upper Left: Rough sketch of the persona along with their name and role
- Upper Right: basic demographic and behavioral information relevant to your product
- Lower Left: user’s needs and frustration with the current product or situation and the specific needs your product is trying to satisfy
- Lower Right: potential solutions for the needs identified on the lower left. This section contains feature and solution ideas.
Three Box (as described in the second edition of Lean UX):
- Upper Left: Rough sketch of the persona along with their name and role
- Upper Right: basic demographic and behavioral information relevant to your product
- Bottom: High-level needs of the persons along with what obstacles keeping them from achieving those needs
I suspect Jeff and Josh changed their format for personas between editions of the Lean UX book to emphasize outcomes over outputs.
Following is one collaborative way to create personas. This approach is especially helpful for reducing the influence of loud voices in the room and to ensure that everyone on your team gets a chance to provide input. You can use this approach with any of the formats listed above.
- Divide the team into small groups of three or four each.
- Place flip chart paper around the room, with each page representing one of the personas.
- Have each group start at a flip chart page and give them 20 minutes to create a draft persona.
- At the end of the 20 minutes, have the groups rotate clockwise, but have one person stay behind to describe what the previous group came up with. The groups then have five minutes to discuss and revise the persona.
- Repeat the rotations until the groups come back to their original persona.
Caveats and Considerations
You could use personas to determine what problem you are trying to solve with your product, but those problems aren’t always restricted to people who specifically meet a given persona. This is the argument that proponents of Jobs to Be Done use to explain why you may want to look at the job rather than the persona to identify problems to solve. Personas do have some value in guiding your design decisions, especially if the people who use your product consistently work in similar environments.
The personas originally envisioned by Alan Cooper in describing user-centered design can be quite involved. My suggestion is to use the idea behind personas to provide simple yet helpful descriptions of the two or three key user roles. The goal is a bit of needed context for the team when making decisions about how to design and build the product.
To be truly effective, the personas should be developed based on observations of people who fill those user roles in their actual environment.
Personas help prevent teams from designing products for themselves, which is important except when the team members building the solution are actually the main users.
Alliteration between the name of the persona and the role is frequently used (e.g., Reed the Reviewer, Sally the Submitter). It’s not necessary, but it can help people remember whom they are talking about.
To make personas truly helpful, they should be publicly posted and available to the teams for reference when they are working on a specific story. It’s a sign that the team has latched onto the personas when they ask, “What would Reed like in this situation?” instead of “What would a reviewer want in this situation?”
Additional Resources
Ambler, Scott. Personas: An Agile Introduction
Cooper, Alan. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing, 2004, Chapter 9.
Gothelf, Jeff and Seiden, Josh. Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Publishing. 2013. Chapter 3.
Gothelf, Jeff and Seiden, Josh. Lean UX: Designing Great Products with Agile Teams. O’Reilly Publishing. 2016. Chapter 3
Patton, Jeff. Personas, Profiles, Actors, & Roles: Modeling Users to Target Successful Product Design.
Leave a Reply