Making decisions in projects isn’t easy. Differences in opinion or perspective can delay (or completely prevent) teams agreeing upon the solution to a problem. There’s no direct science to making the right decisions when it comes to your brand, product or service but there are tools that can help. Personas are one of them and we’ve used them successfully on a number of our projects at Hoffi.
A Persona is a profile of a fictional person, based on the real users of your product or service1. There’s no strict template to follow but they typically show the ways a person interacts with your organisation. Personas get project teams thinking about problems in a unified way and from the perspective of the user, making them a useful communication tool for most projects.
Personas are an essential component of User Centered Design and a great way to follow up User Research. They offer a means to present a condensed and concise version of your findings to other members of the project team. This might be their only opportunity to “meet” and understand the real people they’re trying to help so it’s important that you maintain the real-world detail you’ve captured from research. Avoid creating Personas that lack detail but also avoid adding fictional details to fill in any gaps2. These can turn into generic groups — or even worse, stereotypes — and this could lead the team to make incorrect assumptions about their users.
So what information should you include in your Personas?
You can create effective Personas that contain all the information needed by answering the following three questions:
- What (if any) research has been done?
- What information do you want to focus on?
- Who are you sharing the Personas with?
This will help to ensure that you include the necessary information when developing your Personas, and that they will be tailored to your project.
Lene Nielsen describes the following four types of Persona3 — considering the points above will help you select the right type (or a hybrid of types) for your project.
Engaging Personas
If you’ve ever come across a Persona before, it likely fell into this category, as it’s probably the most common.
As the name implies, it’s designed to be more engaging and it does this by detailing as much real-world information as possible. Routines, hobbies, interests, backgrounds and emotions can all be included to create a fully realised, 3D rendering of a user. The idea is to make a Persona that feels real to any team members it’s shared with, making them more likely to not only remember the user, but also to empathise with them and deliver for them.
These Personas aren’t the best fit for all projects, though. They contain so much information about a user that they rely on thoroughly collected real-world data from qualitative research. Some projects or team members might benefit from a Persona that focuses more on concrete data and statistics — instead of emotions, which brings us onto the next type.
Role Based Personas
Role-Based Personas focus on the role a person plays in their organisation. These Personas should still feel like a real person but contain less personal information and more details about the user’s role, such as; a description of the role, who it impacts and what its business objectives are.
Role-Based Personas should be supplemented with other data wherever possible. For example, it could be useful to explain what percentage of users have this role, their average technical proficiency or their market share. This means Role-Based Personas are more data-driven and need to be created from both qualitative and quantitative research. Each role captured from research should be translated into its own Persona, this can result in a large number of Personas being created.
These Personas are useful to organisations whose decisions are informed by the roles of people they deal with. They can be useful tools where buy-in requires hard evidence.
Fictional Personas
Unlike the previous types, these Personas are not created from user research. Fictional Personas are created from assumptions or anecdotal information from previous interactions with users.
These could be used to give your project team a quick sketch of users but you should try to limit the information they contain to safe assumptions only. They will still be the most inaccurate of the four Persona types, and therefore can be the least helpful. Even when erring on the side of caution, it’s not recommended that these are used as a guide for your product or service.
The initial exercise of creating this kind of Persona can reveal gaps in knowledge, thereby demonstrating a need for user research and highlighting areas that require attention.
These Personas are best treated as hypothetical or provisional because, while they’re a good starting point, they would ideally evolve into more detailed Personas after user research has been completed.
Objective Personas
This type of Persona only concerns itself with the needs or goals of a user. It sits somewhere between the Engaging and Role-based types.
Objective Personas contain details about a person when they are interacting with your product or service. This could be what a person is trying to do, the technology they are using or the time they have available. Similar to Engaging Personas, emotions can be included, but with a key difference — Objective Personas only contain the user's emotions when engaging with your product/service. Qualitative user research is again a good source for this type of Persona but, because of its limited scope, it requires less information than Engaging Personas.
The main strength of these Personas is their simplicity. By cutting out anything unnecessary, team members can quickly understand the needs of users and then work to meet them. However, depending on the project team, there is a chance that these Personas don’t resonate with people in the same way.
So there you have it, four types of Personas that you can use in your next project.
As mentioned previously, you might find that the right type of Persona for your project is a hybrid of these. Don’t worry about sticking to any one type. You could create a Persona that details the needs of a user (Objective) but also include some personal details (Engaging) and statistics from research (Role-based). You can also create as many Personas as you need for your project and they don’t all have to be the same type. If the project scope or budget means that catering to all of those Personas is not an option, or if some Personas contradict each other, you can choose which users are prioritised and work to meet their needs.
In our next article we’ll be looking at one specific application of Personas, User Stories. Sign up to our newsletter below to get notified when this goes live.
Resources