What is a Persona?
Personas are a tool commonly used in UX design. Invented in the 80’s by Alan Cooper - they help teams create products with a specific user (or users) in mind. They help product teams by providing a frame of reference for prioritisation and design decisions. Personas can also help with product strategy and go-to-market plans.
Each persona is chosen to represent a cluster of the user base. Persona descriptions can include:
- Fictional Name
- Job Title / Responsibilities (If appropriate)
- Behaviour Patterns
- Goals (and tasks they are trying to complete using your product)
- Skills
- Attitudes
- Background information (or demographics such as age, education, ethnicity, and family status)
- Operating Environments (physical, social, technological)
- Issues or pain points
- A picture / or imagery
Personas are deliberately chosen to reflect differences between clusters of users (but also the similarities of characteristics within clusters) highlighting the diversity of their needs. Together, the personas should account for the majority of the expected user base.
Personas should be based on real user research. If you haven’t yet done research and you’re basing your personas on assumptions, it’s best practice to call them ‘Proto Personas’.
Example for a Supermarket customer
Cost Conscious Carl | <Photo Here>
<Fictional Personal Details Here> |
Goals | Reduce the price of the weekly shop |
Behaviour Patterns | Compares prices across shops
Uses vouchers heavily |
Attitude | Skeptical of promotions
Not loyal to any supermarket
Appreciates high quality produce |
Environment | Shops off-peak
Shops across supermarkets |
Background Information | Over 65
Retired - on a pension |
Personas are typically presented on a single slide or A5 piece of card. Teams add some fictional detail, to create a more relatable, believable and memorable narrative around the persona.
Personas help teams understand who they’re building for. They’re a tool to kickstart empathy. The hope is that team members will internalise the different needs and expectations of their main customer groups → and stop designing for themselves.
Empathise → Define → Ideate → Prototype → Test The Design Thinking Process
Personas are powerful (and risky) because they’re reductive.
Products should solve a customer need → that requires the customer to be defined. Personas add value because they provide focus, and help prioritisation discussions. BUT everyone is an individual and people are complex. Personas are also a reduction in fidelity. It’s important therefore that they’re grounded in research, and aren’t seen as a substitute for testing.
It’s easier to empathise with people you know, than large groups that you don’t.
Fundraising campaigns that focus on individuals and emotion are more successful than more rational campaigns that focus on statistics. Initially at Facebook the early engineers were college students → building a product for college students. To get to a billion users though - they had to enlist design and research to help understand the needs of different populations.
Accessibility
Personas can help your team empathise with users that have different access needs. The Government Digital Service (GOV.UK) has created 7 accessibility personas, each with different access needs. Use them to kickstart conversations about accessibility in your team - but not as a substitute for accessibility testing.
What’s the difference between Archetypes and Personas?
They’re functionally similar → they’re both a tool to represent the same data and insights about users. Personas have a human face, and fictional information. Archetypes don’t. Deploy archetypes if the team are skeptical about personas or personas already exist elsewhere in the company - but they don’t serve the same purpose of your product / project.