How to make personas useful (and it's not stock photos)
Personas are a popular user experience deliverable, whose purpose and use are often misunderstood. This article suggests ways to make personas useful, and not just a pretty face.As a UX consultant, this was a familiar scene: our team had worked late hours for this Friday client review. The deliverable this week: Personas. After 4 weeks of user interviews, the client was getting anxious: were these expensive consultants going to do something, or just suck up money? We distilled all of what we found into rough types; argued about the details; was this detail enough to warrant another Persona, or were 5 too many already? We put together a slick presentation and the client was suitably impressed. Tired but happy, we went home for the weekend. Months later, the project finished and I realized that, as successful as they seemed, the client and the team really didn't do much with those Personas. Was it all just a waste of time?
What are Personas?
Many websites and software applications have multiple types of users with different needs. A data entry clerk uses an application differently than an account manager. Designing for only one user type and ignoring others' needs leads to unsatisfied users, while mixing functionality for different users is a common cause of confusing software.
A persona is a fictitious character that represents the specific goals and needs of a type of user for a website or application. They summarize user research and business knowledge, helping the project team and stakeholders keep in mind the sometimes conflicting user needs.
Personas are used to:
• Enable stakeholders to understand users and prioritize features and functionality
• Keep the entire team focused on the goals of real users
• Add detail to use cases, describing the "who" doing the actions
• Recruit real users for usability testing
There are a number of excellent books written on the care and feeding of Personas (1).
Persona Problems
User experience work never completes a project; its deliverables are interim deliverables. Wireframes obviously lead to a screen or page, but Personas' are an attractive deliverable without an obvious next step.
User experience teams (and some clients) still expect them, which can make them "consultainment", a feel good deliverable. Photos of users gives the feeling of real data, more than the typical not-statistically-valid user research may deserve. If there is no real user research being performed, there is a danger is that Personas may simply reflect and strengthen the project team's stereotypes of users. As many product managers have never met an actual user, and the UX team may be new to the field or industry, the "echo chamber" effect of uninformed personas may set the project back.
Defined well, Personas can be a useful communication tool to get stakeholders to agree on the fundamental goals of a project to prioritize features. Unfortunately many Personas are neither provocatively interesting nor correct-ably wrong, but merely vague. Sadly, many clients cannot tell the difference, it's up to us!
Bad Personas
• Are based on estimates or market segmentation
• Are not really read
• Are not actionable
• Reinforce user stereotypes
• Are simply copied from another project
• Always have between 3-5 types
Good Personas
• Are based on more than 10 end user interviews
• Explain themselves
• Are immediately actionable
• Give a new paradigm for thinking about the users
• Reflect the distinct functional or demographic characteristics of the user audience
When should Personas be created?
Only when they are needed. But how do you know? My tests are:
• Is there new data (user research, market research, customer service interviews)?
• Do the roles have clear definitions and distinct needs?
• Are there specific questions that an audience outside the project team need to make to define the project? (e.g. senior stakeholders, who often will not read lengthy user research findings documents need to decide whether to target sales representatives or the end consumer.)
If you don't have yes for all three, Personas should be skipped. If the client expects them, explain that you will be able to work on wireframes sooner, they always love that.
If there is no new user research data, the Personas risk reflecting project team biases. Don't add noise. If they must be created, clearly label them as "unverified" and use them to contrast assumptions of the stakeholders.
If you cannot clearly distinguish between user types, merge them until they have irreconcilable differences. The key test here is "why does it matter?" Advertising people are congenitally unable to put "Active Retirees" with "Tweeners", but our job is to determine how people use the application. Personas can be useful in countering marketing segments by showing how usage patterns cross demographic patterns, for example new credit card applicants.
The primary audience for Personas, stakeholders and project sponsors, need to be able to answer the implicit question "Are these our users and which are the priorities?" It is critical to validate this early or one risks an unclear project. (I've heard it said that development teams will use Personas after the user experience team has "rolled off", though I have never actually seen this happen.)
As a communication tool, Personas fill an important role. User experience can learn a lot about a client base, we need to pass on that information before we leave a project.
Persona Interrogation
Here are questions that I've found often distinguish users types.
• Are they familiar with the subject matter at all? (i.e. IRAs in general, rather than a particular account)
• How often do they use the system? Weekly, Monthly, Quarterly, Yearly?
• When they do use it, do they use it ad hoc, or intensively?
• How many of them are there % of user population, % of total client population (Often actual users are a subset of clients)
• How important are they as a client? For many sites, the vast number of users generate no income. Their numerical superiority should not define functionality for paying users, but identifies an opportunity to increase conversions to paying customers.
• Are you segmenting Personas by role (data entry vs managers) or by audience (visitors vs. customers), or self segmentation (independent movie buffs vs. Hollywood fans)?
Design Personas to be used
Assume the clients barely care Personas are in a sense the PowerPoint presentation to a user research findings document: Easily consumed, without all the details. The goal is to communicate enough information to make decisions, not catalog your findings. Each document should introduce itself and tell the audience what is wanted from them. I've seen stakeholders listen patiently without reacting. If the personas result in neither agreement nor correction, it has failed. As Edward Tufte said, "If the chart is boring, you've got the wrong numbers".
Make them actionable
TELL THE CLIENT WHAT TO DO for this Persona. If there is no actionable findings, question whether to keep the Persona. Too many user research projects do not take the final, essential step of telling the development team what to do with their findings. If you have nothing to say, don't say anything, but if you do, translate it into clear and actionable directions.
Just the facts For each sentence, ask the question "what should someone do with this piece of info"? If you cannot say how that Persona X is "retired with 2 kids" affects a feature or method, drop it. Go light on biographical details: our goal is not to have people identify with them, but to explain why their needs are different from another groups.
Be wary of photographs in personas, even if clients respond to them.
The human brain has special sections devoted to analyzing faces and categorizing people without really thinking –this is bad for Personas. Base Personas on what users do, not who they are. Racist, sexist and age-ist stereotypes, even if meant to be positive, should be avoided at all costs.
A Persona document should contain
• An Explanation page
What is this document, and why should any stake holder care?
• A Findings Summary / to do list page
What specific changes should the team do based on your findings?
• An Overview / comparison of all the Personas
How do they differ?
What is the percentages of total audience? Of active users? This can be found in web analytics or CRM systems.
Which would find the project most valuable?
Which are most important for this project?
(Keep these measures general: High, Medium, Low. The goal here is to let the stakeholders confirm that the team is aligned with their priorities.)
Each Persona should contain
• Title the persona by summing up the findings (E.g. "Small business owners need advanced account features") or with a representative user quote ("I need more guidance when shopping").
• Brief Description 1-2 sentences that sketch out the user type
• Characteristics that differentiate it from the other Personas
• Relevant quantitative data that explains and backs up the existence of the Persona (number of accounts, median annual spending)
• General Goals –What are they trying to accomplish by using this system. e.g. "Plan for retirement"
• Tasks –What are they trying to accomplish in a typical session e.g. "Check their balance"
• Insights –What surprising fact came out of the user research e.g. "Most of these users were unaware of the new features launched last year".
• What to do for this Persona Give specific, actionable changes e.g. "Make the registration options visually distinct".
Personas are valuable if done right
Personas can be a useful tool to communicate with stakeholders outside the project team, as long as they give actionable guidance and provoke decisions. The challenge to the UX team is to use this medium to advance understanding and not merely entertain the project!
User experience work never completes a project; its deliverables are interim deliverables. Wireframes obviously lead to a screen or page, but Personas' are an attractive deliverable without an obvious next step.
User experience teams (and some clients) still expect them, which can make them "consultainment", a feel good deliverable. Photos of users gives the feeling of real data, more than the typical not-statistically-valid user research may deserve. If there is no real user research being performed, there is a danger is that Personas may simply reflect and strengthen the project team's stereotypes of users. As many product managers have never met an actual user, and the UX team may be new to the field or industry, the "echo chamber" effect of uninformed personas may set the project back.
Defined well, Personas can be a useful communication tool to get stakeholders to agree on the fundamental goals of a project to prioritize features. Unfortunately many Personas are neither provocatively interesting nor correct-ably wrong, but merely vague. Sadly, many clients cannot tell the difference, it's up to us!
Bad Personas
• Are based on estimates or market segmentation
• Are not really read
• Are not actionable
• Reinforce user stereotypes
• Are simply copied from another project
• Always have between 3-5 types
Good Personas
• Are based on more than 10 end user interviews
• Explain themselves
• Are immediately actionable
• Give a new paradigm for thinking about the users
• Reflect the distinct functional or demographic characteristics of the user audience
When should Personas be created?
Only when they are needed. But how do you know? My tests are:
• Is there new data (user research, market research, customer service interviews)?
• Do the roles have clear definitions and distinct needs?
• Are there specific questions that an audience outside the project team need to make to define the project? (e.g. senior stakeholders, who often will not read lengthy user research findings documents need to decide whether to target sales representatives or the end consumer.)
If you don't have yes for all three, Personas should be skipped. If the client expects them, explain that you will be able to work on wireframes sooner, they always love that.
If there is no new user research data, the Personas risk reflecting project team biases. Don't add noise. If they must be created, clearly label them as "unverified" and use them to contrast assumptions of the stakeholders.
If you cannot clearly distinguish between user types, merge them until they have irreconcilable differences. The key test here is "why does it matter?" Advertising people are congenitally unable to put "Active Retirees" with "Tweeners", but our job is to determine how people use the application. Personas can be useful in countering marketing segments by showing how usage patterns cross demographic patterns, for example new credit card applicants.
The primary audience for Personas, stakeholders and project sponsors, need to be able to answer the implicit question "Are these our users and which are the priorities?" It is critical to validate this early or one risks an unclear project. (I've heard it said that development teams will use Personas after the user experience team has "rolled off", though I have never actually seen this happen.)
As a communication tool, Personas fill an important role. User experience can learn a lot about a client base, we need to pass on that information before we leave a project.
Persona Interrogation
Here are questions that I've found often distinguish users types.
• Are they familiar with the subject matter at all? (i.e. IRAs in general, rather than a particular account)
• How often do they use the system? Weekly, Monthly, Quarterly, Yearly?
• When they do use it, do they use it ad hoc, or intensively?
• How many of them are there % of user population, % of total client population (Often actual users are a subset of clients)
• How important are they as a client? For many sites, the vast number of users generate no income. Their numerical superiority should not define functionality for paying users, but identifies an opportunity to increase conversions to paying customers.
• Are you segmenting Personas by role (data entry vs managers) or by audience (visitors vs. customers), or self segmentation (independent movie buffs vs. Hollywood fans)?
Design Personas to be used
Assume the clients barely care Personas are in a sense the PowerPoint presentation to a user research findings document: Easily consumed, without all the details. The goal is to communicate enough information to make decisions, not catalog your findings. Each document should introduce itself and tell the audience what is wanted from them. I've seen stakeholders listen patiently without reacting. If the personas result in neither agreement nor correction, it has failed. As Edward Tufte said, "If the chart is boring, you've got the wrong numbers".
Make them actionable
TELL THE CLIENT WHAT TO DO for this Persona. If there is no actionable findings, question whether to keep the Persona. Too many user research projects do not take the final, essential step of telling the development team what to do with their findings. If you have nothing to say, don't say anything, but if you do, translate it into clear and actionable directions.
Just the facts For each sentence, ask the question "what should someone do with this piece of info"? If you cannot say how that Persona X is "retired with 2 kids" affects a feature or method, drop it. Go light on biographical details: our goal is not to have people identify with them, but to explain why their needs are different from another groups.
Be wary of photographs in personas, even if clients respond to them.
The human brain has special sections devoted to analyzing faces and categorizing people without really thinking –this is bad for Personas. Base Personas on what users do, not who they are. Racist, sexist and age-ist stereotypes, even if meant to be positive, should be avoided at all costs.
A Persona document should contain
• An Explanation page
What is this document, and why should any stake holder care?
• A Findings Summary / to do list page
What specific changes should the team do based on your findings?
• An Overview / comparison of all the Personas
How do they differ?
What is the percentages of total audience? Of active users? This can be found in web analytics or CRM systems.
Which would find the project most valuable?
Which are most important for this project?
(Keep these measures general: High, Medium, Low. The goal here is to let the stakeholders confirm that the team is aligned with their priorities.)
Each Persona should contain
• Title the persona by summing up the findings (E.g. "Small business owners need advanced account features") or with a representative user quote ("I need more guidance when shopping").
• Brief Description 1-2 sentences that sketch out the user type
• Characteristics that differentiate it from the other Personas
• Relevant quantitative data that explains and backs up the existence of the Persona (number of accounts, median annual spending)
• General Goals –What are they trying to accomplish by using this system. e.g. "Plan for retirement"
• Tasks –What are they trying to accomplish in a typical session e.g. "Check their balance"
• Insights –What surprising fact came out of the user research e.g. "Most of these users were unaware of the new features launched last year".
• What to do for this Persona Give specific, actionable changes e.g. "Make the registration options visually distinct".
Personas are valuable if done right
Personas can be a useful tool to communicate with stakeholders outside the project team, as long as they give actionable guidance and provoke decisions. The challenge to the UX team is to use this medium to advance understanding and not merely entertain the project!
1 The User is always Right: A practical Guide to Creating and Using Personas for the Web by Steve Mulder and Ziv Yaar
The Inmates Are Running the Asylum by Alan Cooper