Personas have been around for a while in the usability arena – so long that I’m not going to describe very much about what a usability persona is all about. Suffice to say, there is a sheet somewhere that somebody thinks is a fair representation of you and how you interact with them.
From the list of benefits of personas, I would like to focus on one key item that can help you to apply personas to a wider set of problems.
“[They] serve as a reference tool that can be used from strategy through to implementation.“
At an abstract level, personas are a communication tool. Instead of describing a user as “a user with permissions to access call history, client notes and payment history and who works in the customer services team and specialises in the car rental business area”, you wrap that all up into a biography for a user who you call Sam Rental.
Now you can have conversations with people about Sam Rental and you all know that this persona wraps an entire concept into a simple name. You can also use this name in your specifications: “Given Sam Rental is using the call history screen…”. George Miller would be delighted.
You can use Sam to discuss business needs, test out ideas, create strategies, think through marketing campaigns and test software you create to interact with Sam. Of course, you’ll need more than Sam, you’ll want to create a number of personas – and this can get hard to manage.
To ease the creation of personas, you can use a naming convention that bakes in more meaning. The use of Sam Rental hinted at this possibility. The surname “Rental” was selected to highlight that this persona was working in the Car Rental team. You don’t have to be this literal, but by using a name that provides clues about the persona you can reduce the cognitive overhead of leaning what all the names mean.
You will also want to avoid baking-in every difference between personas within the name. The persona Sam CallHistory-ClientNotes-PaymentHistory-CarRental is not a great handle because it hasn’t encapsulated the meaning in a shorter form. The key to naming the persona is to consider the important difference between this persona and the others that you have.
If you can find the important differences and creatively inject them into the name, the personas will be a better communication tool.
You can create even better names using combinations, for example; we can use the first name to highlight the user’s role and the surname to reflect the area of expertise. Here is a quick list (that is particularly basic, but should give you the idea).
|Sam||A customer services user with the default set of permissions who can access basic screens.|
|Steph||A finance team user with elevated permissions to access payment screens.|
|Len||A high net worth customer.|
|Chris||A customer with a tight budget.|
|Rental||A person with an interest in car rental.|
|Outright||A person with an interest in car purchasing.|
I can generate a whole bunch of personas using these first name and last name combinations. Len Outright who wants to buy an expensive car, who will probably chat to Sam Outright to do so – while Chris Rental speaks to Steph Rental about his late payment for the car he rented.
As soon as you create a combination, you already know what they represent and you only have to learn four names and a couple of surnames. You could even make it easier by calling your high net worth customer Maximilian and your customer with a tight budget Mindy (max and min). There are lots of ways of adding meaning to a simple name.
You can also use this technique to create company names, price plans or other kinds of data. Just remember, don’t get too cute with your test data. Nobody wants to stumble across an offensive name, even in a test environment – and it is surprising how many screen-shots will leak there way out of a test environment when someone gets excited about a new feature.