Personas Can Bring Users to Life

Personas can be a marvelous tool for helping software development and product teams capture an understanding of their users. Successful examples can bring those users to life in a team’s mind, influencing design and development and helping the team focus on the needs of a particular set of users. 

To me, there are three parts to this effort: understanding, creating, and introducing. 

Part One: Understanding

As with all of my research efforts, I like to begin by meeting with stakeholders to understand what kind of goals they have (even if I initiated the project, the stakeholders nearly always still have something they want to learn or get out of it), what we already know (institutional knowledge is a great resource for a UX researcher), and to talk about finding possible research participants. If this is my first time working with this particular stakeholder, I will also generally try to sell them on the benefits of attending research sessions themselves. 

Generally, we are working from a place where we know something about these users. If this is the case, I can start to segment them based on this discussion with the stakeholders and any existing information or documentation they can share. I might know that we expect our users to all be employees of city or state governments, or related agencies, but nothing beyond that. At this point, things might be very vague, and that’s okay. That’s why we do user research!

An effective persona should be based on primary research, but I often (in fact, nearly always) begin with some secondary research. This is also a good time to involve the data or BI team. In my mind, personas should be built on a combination of Big (quantitative) Data and Thick (qualitative) Data. Big Data gives us the "What": behaviors, demographics, etc. Thick Data provides the "Why". Along with any existing research that the stakeholders or other UX/Product/BI could provide, I will head to Google and do some searching to try to fill in the missing pieces.

Quantitative Data gives us the What: behaviors, demographics, etc. Qualitative Data provides the Why.

From this secondary research and the existing data I like to pull together a lightweight proto-persona for each of the user segments I have identified. It is important to make it clear that at this point we haven’t validated with our users, but I am a proponent of sharing early and often, as I like to use the design process to refine my research deliverables. Personas are meant to be iterated on, and I personally don’t ever view them as “finished”. It is, however, crucial to inform anyone who sees them of the stage they are in,and what that means. 

While consuming the secondary research, I will work with anyone I can to identify candidates for research. For understanding a persona in depth, I like to conduct semi-structured or unstructured interviews and ethnographic research. I usually start with product teams, but I will ask for help from sales, support, trainers, anyone I can. As in all of my research, I try to get an introduction from someone who knows the user. This works much better than a cold call or email out of the blue. Another good option (but one that I notice there is rarely budget for, at least at the places I have worked) are intercept tools like ethn.io, which will intercept users while using your app or website, and ask them if they want to participate in user research

Try to get an introduction from someone who knows the user

I’m aiming to get 5-10 initial interviews scheduled for each segment. The goal is to conduct interviews, build out an understanding of these users’ day-to-day behavior and goals, what motivates them, things they love and hate about their work, and a general picture of their personality. I have a general format I follow for the interviews, but I customize it each time to ensure it is gathering exactly the type of information I need. 

When I’m conducting these interviews, I like to use a spreadsheet to help me with finding themes. The first column lists all of the questions (one per row), and each column to the right is for one interview’s answers to those questions. As I go, I can then scan across the row to see how all of the participants responded to a particular question. This helps me identify themes quickly and easily. 

As I mentioned, I like to encourage stakeholders and other members of the team to attend research sessions. After each session, or at the end of a day with multiple sessions, I will gather the attendees together and we will essentially walk through the spreadsheet, talking about our findings for each question. I find this is a great way to get a different perspective on my interviews. I know I will never catch everything myself. 

At the end of this series of interviews, I will generally have a good start at the persona. Depending on the project variables and the needs of the team, I might do one of two things: 1) begin working on the persona content or 2) begin observation sessions. 

At this point, I like to turn to ethnography (option 2 from the previous paragraph) whenever possible. It provides a much more fleshed-out, fuller picture of the users. And even if I am forced to take option 1 and begin crafting the content, I can always go back to the users after in order to improve the personas. As I mentioned, I don’t like to look at these as static deliverables. People and their roles in work and life are constantly growing and changing, and the personas that represent them should do the same.

For the ethnographic study, I will use the findings from the interviews to craft a research guide. That said, for the most part my observation doesn’t really follow much of a script. I like to use a simple tool to help guide my observations - POEMS. This can be as simple as a sheet of paper divided into 5 parts with the following headings:

• People - Record the roles, demographics, behavior, and other observations about the people you’re observing. Who are they, and what are they doing?
• Objects - What are the physical things the people are interacting with? Any machines, devices, tools, etc. Does everyone have their phones in their hands? Do some of them write in notebooks?
• Environment - Include a description of the environment. Is it an office, a warehouse, outside, inside? Is it a poorly-lighted office with very little room to move around, or a corner office with huge windows and high-class furnishings? Take a picture, or sketch it.
• Messages - Describe any communication you observe. Do people shout across the room at each other, or Slack each other from the next desk over? What are they saying? Do they need to fill out paperwork whenever something happens? Get a snapshot of it. 
• Services - Any services, apps, or other tools being used. Do they use single-sign on to access everything? Is there an app that everyone in the role uses?

At the top of the page, I write the location I am at, the project I am working on (I don’t just use this template for persona research), and the main subject of the research (i.e., the persona).

When all is said and done, I usually have quite a few pages full of notes, a few diagrams or maps, and a spreadsheet full of findings. Ideally, there is also a team with their own observations ready to get into a room (real or virtual) and start jamming.  

Part Two: Creating

Now that we’ve spent a lot of time building an understanding of the users, we’re ready to work on crafting the actual persona. I’ve done this a few different ways in my career, and I have a definite favorite method. 

One way to turn all this data into personas is to input all my notes into the findings spreadsheet and identify themes. These themes can then serve to populate the various sections of the persona template you are using. I don’t like this way as much, because I feel you get a much stronger (and far more effective - see the Introducing section below) persona when collaborating with others.

You get a much stronger and far more effective persona when collaborating with others

To me, the more effective way is to bring a small group together to brainstorm on the first draft of the persona. As the User Researcher, you are the expert, and the final draft should absolutely be your work, but it should ideally be based upon the research, understanding, intuition, and discussion of a group of people who are invested in bringing this persona to life. 

To be honest, the two options I just mentioned are really not separate methods. It’s more like either option A or option A+B. I still create the same findings spreadsheet (each question is a row, observations from each interview get their own column, and the far right column is for conclusions and other notes) before I head into the group session; I just get more help in fleshing it out and turning it into a draft persona. 

To prepare, I ask everyone to bring their notes from the sessions they attended (or watched a recording of), and I also create a broad outline for our draft persona. This can be on a whiteboard, or posterboard, or a large sheet of paper, or even Miro if we are meeting remotely. I’ll have a section for personal/background info, motivations, delights/frustrations, tech savvy, and often others (tools of the trade, for example) depending on the situation. 

Often, I will begin the session by going around the room and asking for overall impressions - what kind of person is this? Then we will walk through each question, and discuss everyone’s impressions of the various interviews. Unless your team all have eidetic memories, they will likely need to rely on their notes for this - which is why I remind them to bring those to the session multiple times. As we go around the room, I add any new observations or insights to my spreadsheet.  

Finally, we begin to fill in the draft persona, going section by section. Disagreements often lead to the most interesting results. We just want to make sure anything we put down is backed up by evidence.

Usually, by the end of this session, we have a pretty great start at a persona. One thing I often forget to do is ask for everyone’s thoughts about what the persona looks like. You can have people jump on a computer and show you examples, or just describe the image they have in their minds. 

I will then take this draft persona back and begin to flesh it out, and trim the fat, using my findings spreadsheet. I find a few decent pictures and get some feedback on them. I put the persona into its template - or ask visual designers to do this, because they are much better at it.

As with most (all?) design projects, a review process is important at this final stage. Send it to your boss, other UX team members, and some of the people who were involved in the research and creation steps. Make sure it brings the person behind it to life. As long as the people reviewing the persona are competent and have a good understanding of the project goals and the research, it will be more effective after the review than before it.

Once this is done, give it a name and you have a persona. I like to use alliteration, such as Sam the Sales Rep or Oscar the Operations Manager. It helps people remember the persona’s name at first until it sinks in. 

Part Three: Introducing

A beautifully-designed and well-researched persona contains a lot of really great information, but the job is still only partly done once you have the final deliverable in hand. Socializing is a key part of an effective persona. 

The greatest thing about having stakeholders attend interview sessions and running the group brainstorming session mentioned in section two is that you have a great head start on socializing the personas. If you can drag along a lead dev, a product manager or analyst, and a designer into the persona creation process, you now have a “spy” in each of those teams, working towards your nefarious goal of getting the team to accept the persona as a fleshed-out human with needs, motivations, and feelings.

Add the persona’s image and name to the flow diagrams from earlier in the research process. Grab a visual designer and create some posters. Hang these up in the halls and near the engineering and product areas. Introduce the persona in a team meeting, and work with the senior members of the team to ensure they begin referring to these types of users by the persona’s name at all times going forward. Project documentation can refer to the persona. 

Do everything you can to help your new persona fit in, because if they do they will be a very effective member of your team.