How to Create Personas in the Agile World

Have you entered a new project where you don’t have much time to do user research? or in the middle of a project where it’s needed some new personas and the time is short or with a limited budget?

If you say yes, well, we feel your pain. We always prefer to do proper and extensive user research and create perfect personas, but the truth is, only a few ux researchers have the possibility to do so.

Personas need a lot of research — trying to find the representative users, scheduling, interviewing, analyzing and group their commonalities. It can take a lot of time, especially for agile projects. Also, many times, personas can generate a lot of wasteful data and when they are finished, most become stagnated and don’t evolve. But everything evolves. People evolve. Users evolve.

So is there a quicker way to do personas? Yes, it’s called proto personas. They are quick to do and they adapt perfectly to agile projects.

‍

What are proto-personas?

‍

Proto Personas is a variant of the normal Personas.

They are a compact version of the personas, with no need for research in the first place. It’s based on assumptions, from stakeholders and your team. What? So what is the point of doing personas?

Well, personas are still really valuable. Personas are more complete than proto-personas but nowadays, we feel that with an agile world, it is difficult to do an extensive study on them. Proto-personas start with assumptions. You validate those assumptions. And adapt them with the new insights or create new ones if necessary. So it's agile! With ideation, fast learnability. And with proto-personas, you can still avoid a risky knowledge gap that can exist between user researchers and the consumers of that user research.

‍

So how do we create them?

‍

You can do this by yourself or collaboratively with your team mates or stakeholders from departments like marketing, sales and customer support.

‍

If you do by yourself

1- Grab a napkin or a sheet of paper

2- Draw three sections(it can be four, depending on how you like to organize the information)

3- The upper-left quadrant holds a rough sketch of the persona along with a name and role.

4- The upper-right holds some basic demographic, psychographic and behavioral information. In the demographic part, we rarely add a lot of data. In product and service design, we care more about the needs, goals, main activities and behaviors. So when you think about demographics, try to focus on information that predicts a specific behavior that is relevant to your product or service. For example, age might not be important to your service or product, but accessing a specific device like a smartphone, might completely change the way this person interacts with your product. Only write the differences that make a difference. Also, this section sometimes holds their main activities, related with their role.

5- The bottom-half of the proto-persona is where we add the most important information. We add the goals, needs, desired outcomes, obstacles or frustrations that keep them from reaching their goals. Users rarely need “features”. The need is to get to their goals!(And those can be not tangible, can be emotional, etc.). Sometimes, in the group exercise we separate the pain points from the needs/goals. It doesn’t matter how you organize the quadrants, as long as they make sense, and that they have all necessary information.

‍

If you do with your team or stakeholders

‍

Facilitate the a brainstorm exercise:

1 - Start by asking who the service, functionality or product should be targeting and how that would affect their use. 

2 - The team creates a list of personas. This list could contain target segments like for example “avid student”, “university professor”, “day-shift library employee”.

3 - Compact that list to three or four personas. This can help to focus and to choose which ones are the most important, the ones that are most likely to use it. There could be more in the future, but for now focus only on the most important.

4 - Ask them to differentiate them by roles and needs, not on demographic information.

5 - Ask the team to complete the proto-persona template for each one. Normally we do this by separating in groups and each focus on the specific persona. Then we bring these back to the group to review

6 - Revise each persona based on feedback from everyone.

 After you have all the proto-personas, it’s advisable to get input from other people from the company, so you can share with them.

‍

Go and validate

‍

You got your proto-personas. They look great. But you need to validate them and see if they exist, and if all the assumptions are real.

Try to recruit users for interviews starting for example, by the target segments. So from the example above “college students”, or library employees, etc. We might find the target segments or maybe not. If we can’t find them, they probably don’t exist. So you need to adapt and edit those personas.

So basically, ask this three questions:

1 - Does the proto-person exist?

As I mentioned before, you can start by trying to recruit that target segment. It's a quick way to test this assumption.

2 - Do they have the needs and goals that we sketched for each?

To this question, we can listen and observe each of the users. Do they have the same problems that we assumed? Can we confirm the assumptions? Are they real? If not, you should go back and adapt those. We don’t want to design solutions for problems that don’t exist right?

3 - They will value the solution for the problem?

We nailed with the problems, and with the perfect solutions. But would they value this solution over others that they already have in their day-to-day work?

We need to understand how they solve the problems nowadays. We need to see if from all the users, if they value it.

Many of our clients still work with long excels and with emails back-and-forth. And many might not use them everyday. Maybe they use it once a month or once a week. Maybe it’s just for a couple of users and not for the majority.

So even if the persona exists and they have a real problem, it might not mean that they always value a solution for it. Imagine that the solution takes a lot of time to code and developers effort, and when you ship it, most of the users don’t use it. Better to find out early than late!

We can validate proto-personas not only with interviews, but with usability tests, surveys and other research methods. And they should be updated. A lot of times, proto-personas stay the same, with no updated information. So try to avoid this. Proto-personas should be updated regularly during the project, to more accurately reflect what has been learned about them.

‍

‍

‍

Conclusion

‍

Proto-personas are faster to create than personas, and will give you some knowledge about your users. You don’t need a lot of deep research at first to have their needs, goals and pain points.

You can do them by yourself, or with a team and stakeholders. The more collaborative, the better! In this way you and your team can have a shared understanding of who they are, what they need, and what pains they feel.

Having proto-personas is quicker — but still, you need to validate and update them. They are like real humans. They evolve, they adapt. Just keep listening, watching, and questioning, to extract new needs, goals and other obstacles they find along the way.

‍

Check the Hi Masterclass at https://www.youtube.com/watch?v=WsL_eZ7r7xw

‍