Proper use of personas

Seems the in thing to do this spring is critique persona use.

In the last two weeks, I’ve seen tweets stating personas should be anonymized because age, gender, ethnicity, etc. can cause distracting assumptions. I’ve seen tweets that said specificity matters because the point of personas is to build empathy. I’ve seen tweets that maybe personas don’t build empathy very well. I’ve even seen a few people suggest they shouldn’t be used (though I can’t find any of their tweets now).

And if any of that advice is useful to you, go for it.

Here’s some more advice about using personas.¹

1. Personas should be based on user research and analysis. The farther away from user research you wander, the more risk you add to your design project. This is the one universal truth that separates creating personas from writing fiction about the people you wish were using your system.
2. Personas are deliverables used to track the research and analysis you do about your audience, so you don’t have to keep it all in your head. (Write it down or it never happened!)
3. Personas are a technique for storing the assumptions and research you had about your audience so a year later you can remember why you thought what you thought.
4. They are a way to encourage acknowledgment with business sponsors and project teams that you have more than one audience. “Who will use this?” “EVERYONE!” “Try again, Sparky.”
5. They are a way of teaching new designers to think about users before thinking about solutions. Just the act of identifying personas is educational. I’ve had more than one volentold SharePoint admin exclaim “Oh wow these are fantastic!” when I explained what a persona was.
6. They are a way of reminding old designers that new designers still exist, and that we can all take a decent trip back to basics every once in a while.
7. Personas are useful as protection for your research sources. Someone is much more willing to give you their actual views of a process or a goal when their words can’t be traced directly back to them. Personas allow you to anonymize the interviews so that you can bring up important user points of view without a manager storming out of your meeting to go give the interviewee a piece of their mind.
8. Personas are a method of visualization used to differentiate audiences, so that the team can keep straight all the different actors on the system. (You can’t tell the players without a program.)
9. They are a way to validate your user research with the people that you interviewed or their managers — “does Jeff seem like he’d be a member of this team? Why or why not?”
10. They are a fast way to show progress in the user research when the sponsor is getting itchy to see screens. “While I work on that wireframe can you validate this persona and shop it around?”
11. Personas help the content folks identify audiences for tailoring content, writing audience briefs, etc.
12. Personas are a framework that folks writing requirements can use to create the actors in use cases or Agile stories.
13. Personas help validate security and systems requirements in a conversational way when reviewing requirements or detailed design. “Can Taliq access this screen as a service rep or is Wanda the financial planner the only one who has access?”
14. They are a way of telling stories to walk people through processes and get sign-off on screens.  “Adele clicks here, then fills out this form, then clicks here” makes more sense to most people than “this is the form screen and its exits and entrances.”
15. Pictures of your personas should be hung all over the project room so that everyone can see the users and remember that’s who we’re building for.
16. Personas may encourage your project team to empathize with the users.
17. More importantly, personas encourage you to empathize with the uses.
18. Personas should only have information relevant to your project because everything else is distracting for the project team.
19. Personas should have a snapshot of the life of the user because your project is not their life, and the project team needs to be reminded of that. They are a subtle way (or sometimes not-so-subtle way) to remind the project sponsors that users have lives outside of their product and nobody’s visiting your website nineteen times a day “to have a community”.
20. Personas should be embellished to contain accessibility issues like low vision or deafness to remind the project team to be inclusive.
21. Personas should concentrate on the user’s tasks and goals, not their ethnicity, age, gender, etc. because those elements might distract the team or cause unneeded assumptions.
22. Personas should be specific — identifying the user’s ethnicity, age, gender, etc. —  so they’re someone you can picture saying hello to in the hall.
23. They are a subtle way to remind your project members that black managers exist, women developers exist, deaf customer service reps exist, but the stereotypes in their heads probably don’t exist.
24. Personas should never be reused, because they should be specific to the project.
25. Personas should always reused, since the users don’t change just because your project has. (Make sure you revalidate them for each project!)
26. Over a really really long time Personas can help you spot trends or changes in that audience.
27. They should never reference the user’s hardware or software.
28. They should always reference whether the user is on mobile or desktop and what OS they’re using — you know, their hardware and software.
29. Every time you use personas you should use them the same way, except that’s not actually possible because teams and projects are all different.
30. Personas, when documented, should fit on one page. Or five pages. Or a full report with a nice summary.
31. They should always/never/sometimes have pictures.
32. They should be whatever your boss expects.
33. They should be whatever your contract stipulates.
34. They should be whatever your mentors suggest.
35. They should follow industry advice, unless that advice is worthless or doesn’t apply to you.
36. They should help you fail faster.
37. They should help you not fail at all.
38. Personas have multiple purposes.
39. Personas meet multiple project goals.
40. When all is said and done, personas should look like, contain, and be used for whatever the hell makes your work more effective and your project more successful.