5 Persona Distinctions: How to use Personas properly
Summary: Getting personas right can save you a lot of time and avoid common approaches to generating persona nonsense. Personas should 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, really?
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 and the author claimed he invented personas (he authored The Inmates are Running the Asylum that spoke 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 — remember 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. e.g. 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 garbage 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 UCD methodology aka Goal-Directed Design) and encouraging 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, most of the industry is still stuck in this flat persona rut. Only Forrester Research, to my knowledge, has consistently educated on persona best practices — though 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: Example: (Mistake) “Jim wants to buy a car” [goal]…Better: “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’re more interested in behavior and shared problem-solving between users (not each user individually). For example, if you interview 15 users and create 8 personas based on individual users, that’s not much of a pattern. It’s better to find generalized behavioral patterns in the data that apply to a larger set of users, and lean on a functional role, you can design around. 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. Okay, in the industry we standardized the use of a photo of a person on each persona, no wonder we are confused. Note: 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”. So if you name your personas as a person eg. (Mistake) “Susie”. By using a person’s name you end up forgetting they are a role. Better: “Duplicate Debbie” This uses a nickname, and is an actual B2B persona who spent all day chasing duplicates — — notice how I remembered the pain point and could tell a little story about “her”. Using an “associating adjective” like this will help you better use your personas to evaluate them, remember them and ultimately make better design decisions with them in mind. Have fun with it, but make it relevant to the core problem or behavior and in rare cases, the segment you are profiling in your persona.
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 distract us with demographics and while fine on their own, have no place in UX Design process. For example (Mistake) “Sally is 3, lives in Seattle and makes $50,000 a year which she saves $2,000 monthly toward her dream home” (sees her from a 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” (sees her from a 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.
Personas as storytelling vehicles
Finally, it is important to recognize that personas be made tangible and operational. At Experience Dynamics we 3D print them, into pop-outs that can be handled and examined by the team. 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, though 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 their problem, motivation, and maybe even their feeling 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.
About the author: Frank Spillers, CEO/ CXO of Experience Dynamics, a leading UX consulting firm with Fortune 500 clients worldwide.
For over 20 years, Frank has been a seasoned UX consultant, Researcher, Designer, and Trainer. He is an award-winning expert in improving the design of digital products, services, and experiences. Frank is a Subject Matter Expert in UX Design, UX Management, Accessibility, Emotion Design, Service Design, Localization UX, Lean UX, VR/ AR UX Design. He provides private corporate training and offers courses to the largest online design organization in the world (Interaction Design Foundation). In 2001, Frank founded UX consulting firm Experience Dynamics. He provides deep learning opportunities at UX Inner Circle.
