Why do we create ‘personas’

As a designer, having worked with several teams, I came across teammates with two extreme opinions about ‘Personas’. One who thinks ‘Personas’ are a must in any design process, and other who thinks — ‘it is a waste of efforts and time’ and one can do away with it.

Starting with the sunny side of Personas…

Personas are simplified representatives of the real users. They help in sharing the user research data in shorter yet open to interpret format.

They are certainly useful in a design process for following reasons:

1. It brings all the stakeholders on the same page, and they can refer to the same set of agreed representatives of the real users
2. It becomes easier to ‘put yourself in the customer’s shoes
3. It becomes easier for the designer to design for the users with varied ethnicity, culture, age groups, geographies, abilities and personality types
4. Help in eliminating ‘personal biases’
5. Simplifies the ‘user research’ document
6. Help in right decision making. Personal opinions can be sidelined. Every option can be evaluated through the lens of personas. “Will ‘John’ (a persona) be able to do this? Will he be comfortable with the hidden menu navigation?”
7. Help in mapping ‘anticipative needs’ of the users rather than the conventional ‘requirements’
8. The team can enact as the personas and conduct internal concept testing
9. Personas would help in identifying right users for testing

All of this is good when the approach to creating Personas is right.

In one of the conferences I had attended a workshop on creating personas. Within 30 minutes each team came out with personas and his needs along with the solution(wow!). Some of the observations in the workshop (and how the same approach is followed while working on the real-time projects):

1. The so-called personas where ‘stereotypes’ and not the real representation of Personas. This also happens in practice as well. People lock themselves in a meeting room for half a day and create personas based on their own [biased] experiences ; the heavyweights here have more say.
2. Teams come out with a solution first and then try to fit the Persona (especially the pain-points) to the solution they have. For example — Team already know that they are planning to have a solution which will use the traditional feature phone based messaging services as a mode of interaction. So one of the resultant personas would be the one who is using a feature phone and is technologically challenged.
3. This is more dangerous when a team sitting in Sri-Lanka starts making personas for users in the USA by involving just one person from somewhere in the US.

In some cases, personas can be skipped:

1. You cannot conduct user research. In that case, just go by good design practices and you will have a good solution rather than just getting biased with wrong stereotyped personas
2. When the team working on a project is small and they are well aware of the target user group which is quite homogenous. Decision makers also belong to this smaller team or are closely working with the teams.
3. While delivering a customized solution for a known smaller team. Such as a solution for a local hotel chain where the users are always accessible.
4. The target user segment is very broad. In that case, just follow principles of good design and inclusive design. We can also consider creating personas of only the extreme users at both ends of the anchor points.
5. While working on a project where a broad level solution is already figured out.

The good ways to evolve and use personas:

1. Conduct qualitative user research (preferably ethnographic research with few ‘day-in-a-life’ study) with the defined consumer segment
2. Analyze and synthesize the research data. Identify some common traits, patterns, personality types, and the hot-spots
3. Be clear about the anchoring point for creating a persona. It could be the personality trait, role profile, buying behaviour, ethnicity, literacy level, technology challenges, age, abilities and any other as relevant. The anchoring points become your buckets where you can group the similar personas.
4. It is a good practice to decide on the ‘types of persona’ which best suite for the solution we plan to deliver. Personas can be classified in two types — Personality based and Job profile based.
5. Keep all constraints and plausible solution aside
6. Keep it visual. Use a lot of pictures. In all the available templates, I see nowhere pictures are being used (apart from the fake looking persona picture). Using pictures will help in a deeper understanding of the users, context and make the personas interactive & engaging.
7. Have your own standard templates, but feel free to modify based on the project-specific needs
8. Create user stories (not those single liners) which are short and engaging. They help the team visualize the plausible scenarios
9. Avoid deciding the number of personas beforehand