Summary: 5 persona distinctions are required to learn how to use personas properly. Getting personas right can save you time and help you get accurate user information. Personas should be based on user research and point to behaviors, not individuals. Using ‘Associating Adjectives’ can help ground you and reinforce observed behavioral patterns and roles. More importantly, grounding your team will help them navigate this often not-quite-understood qualitative research deliverable.
What are Personas?
Personas are representational profiles of user activity, behavior, motivation, and intent. They are used to identify, understand, and pinpoint awareness of users and their dominant needs, scenarios, characteristics, problem-solving patterns, and pain points. Personas capture user roles, goals, and tasks.
Alan Cooper, father of Visual Basic and UX leader, claimed he invented personas (he authored The Inmates are Running the Asylum and spoke at a high level about personas). Many point to Moore’s earlier sensation Crossing the Chasm as the origin of persona use in current product design. Cooper may have been among the first to popularize (eg market) the term within the newly fresh Dot Com UX community (we were calling the field Information Architecture, not UX at the time). Much of the language in the late 1990s to mid-2000s was not standardized. Even UI’s were called “GUI’s” (goo-ey’s), often entirely referring to what we call ‘front-end web development’ today, not “UX/UI” as it’s called today. In 1999, I was calling personas “user profiles”.
Now, Alan Cooper’s association with personas is curious because he nor his firm, at the time, did much to clarify persona best practices. As a result, a lot of persona “noise” floated around in the community for over 10 years or more. In fact, he may have thrown a lot of teams off the scent for a long time, focusing only on goals (and even branding a new spin on Human Centered Design methodology with “Goal-directed design”.
Worse, the lack of clarity from Cooper on personas flourished personas that were fake or at least useless as product development UX tools. Though, to be fair, Kim Goodwin, his right arm, seemed to know what she was doing more than Cooper, probably because she led the UX research team for a while…
5 Key Persona Distinctions: How to use Personas properly
Let’s unpack Cooper’s mistakes with personas that many teams unfortunately adopted. In fact, this flat persona rut still persists in much of the industry. Only Forrester Research, to my knowledge, has consistently educated on persona best practices. However, they missed a few distinctions, too.
The 5 key distinctions that will improve your persona development process include:
1. Focusing on more than persona goals: Goals are great, but keep going! Under goals sit tasks, and under tasks sit sub-tasks. Pull in the whole data set, not just the silly goal focus that makes most personas childish. For Example:
Mistake: “Jim wants to buy a car” [goal]
Instead:
A. Technical Tony is looking for a powerful engine he can use to tow his boat [goal]
B. He’s researching truck types with tow hitches [task]
C. He wants to know if tow hitches can be added later so he searches a boat owner’s forum [sub-task]
2. Positioning personas as roles: Mistaking personas for individual users or people is the classic mistake. By pivoting your position to see personas as roles or ‘hats users wear’ you can better understand how that role will interact with the design. Personas should point to behaviors, not individuals.
Remember personas are representations of collective user actions. The big problem with matching personas to an actual user you talked to or discussed in a meeting is your sample size of that single user. In UX our qualitative research sample sizes are small, which also means we are more interested in behavior and shared problem-solving between users (not each user individually).
Mistake: If you interview 15 users and create 8 personas based on individual users, that is not much of a pattern. It’s a too detailed segmentation of user behavior.
Instead: It is better to find generalized behavioral patterns or archetypes in the data that apply to a larger set of users. You can then lean on a functional role to design for. With 15 users you might identify 3-4 key roles that capture 75-90% of user problem-solving needs.
3. Naming personas with strategic nicknames: Another common mistake is to name your personas as if they are actual people. Instead, use an “associating adjective” to help characterize the dominant actions or pain points of a user archetype.
Mistake: By using a person’s name you end up forgetting personas are a “role”. Instead of “Susan”, it’s better to use some alliteration to capture a problem many users face: e.g. “Duplicate Debbie”.
Instead: Using an “associating adjective” like this will help you better use your personas to discuss and evaluate them, remember them, and ultimately socialize them more easily among stakeholders.
Why do we use a photo as if it’s a person? First it’s difficult to visualize a set of behaviors or roles. So we use a photo to humanize or activate deep-seated empathy– it sends a message to the reader: “This is another human being you can empathize with”.
4. Differentiating design from marketing intent: I have seen too many ‘diluted personas’ that are contaminated with a marketing-centric persona approach. In UX, we are influencing behavior, so we need behavioral profiles or “Design Personas”.
“Marketing personas” are not directly helpful to UX deliverables other than to recruit and understand market projections at the start. During design, a marketing persona can distract us with demographic details. For example:
Mistake: Sally is 33, lives in Seattle and makes $50,000 a year which she saves $2,000 monthly toward her dream home. [marketing lens]
Instead: Repeat Rita has bought a house before but it was so stressful, she forgot the terminology eg. what an ARM mortgage was, and thus needs it defined, just like First Home Fiona. [problem-solving lens]
5. Sourcing data of persona insights. For personas to be taken seriously, they need to be based on actual customer behavior. Observing and interviewing are the most common formats. Note: This is not user testing– that is a different UX technique used to evaluate an interface, not understand user goals etc. For example:
Mistake: Using surveys, web analytics, internal discussions, and marketing data like broken focus groups will get you opinion and speculation.
Instead: Interviewing and observing users and witnessing their pain points, while hearing their stories, will help you gather important context clues in order to situate their behavior: roles, goals and tasks.
See 5 Steps for aligning persona research to design
Personas as storytelling vehicles for organizational value
Finally, we must recognize that personas should be tangible and operational. At Experience Dynamics, we 3D print them into pop-outs that the team handles and examines. However, the key to making personas sing is to give them life through story. Now, some IT-heavy organizations cringe at the idea of taking time to tell a user story. Ironically, Agile teams spend countless hours chasing User Stories (an Agile developer deliverable). The whole point of learning from personas is to have a story that explains users’ problems, motivations, and maybe even their feelings about the task, company, or existing design/ solution on the market.
Don’t be afraid of stories, and don’t be shut down by those in your team uncomfortable with stories. Instead, you might try what I do and say, “It’s okay if I am telling stories. It’s part of my job as an {insert UX role here} to communicate findings through scenarios and stories that detail user needs and behavior.” Then continue with the stories. It is your job! As a user advocate, you are a carrier of user needs and requirements, and story is how you transmit this vital information to your teams. Good personas with distinction can help too.
Learn how to craft your personas right in our Personas Training
Go deeper: Make your personas inclusive by default… How to create Inclusive Personas
