
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?
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.
Best Regards,
Frank Spillers, Chief Experience Officer @ Experience Dynamics
Looking for more?
Join Frank Spillers' UX Inner Circle: Get 1:1 mentoring and UX process tune-up advice and direction.
(Express your Early Access interest here)