What Would Karl Do? Or How to Get Real Value From Personas (Part 2)

Where we get into the details and nitty gritty on personas.

Part 1 of this post is available here.

  • What is a Persona?
  • What isn’t a Persona?
  • Why do People Dislike Personas?
  • Who can Benefit from Personas?
  • What are the Main Types of Personas?
  • How to Create Compelling Personas?
  • How Many Personas Do You Need?
  • And yes, you’ll learn about Karl

What Information Does a Persona Contain?

The short answer is that personas should contain the information needed by the team to do their jobs and make the decisions they need to make. This may sound like a non-answer, but to be honest, this is one place where a lot of personas go wrong.

Screenshot of a variety of persona templates and canvases
Screenshot of a variety of persona templates and canvases
Persona templates

The problem with these templates is that they only give a superficial description of the role and give a one-size-fits-all format.

Yes, they have boxes for challenges, objectives and the like, but a set of bullet points with a photo and some demographic information is not enough for anyone to truly appreciate the complexity of a role and empathize with their situations.

Just as a 1–2 page bullet-point resume can hardly fully describe you and your accomplishments to a prospective employer, an analogous 1–2 page persona CANNOT do justice to the roles of interest.

They can’t provide the needed detail to enable teams to understand, internalize and empathize with a complex role that they are building for or marketing to. This is one reason that personas have a bad reputation in many circles.

Provide detail, but not too much detail

In the case of personas, it’s better to err on the side of detail, but not go overboard. You want to give enough information so people can understand detail and nuance, but you don’t want to overwhelm the people with information overload.

  1. Persona background (skills, education, previous jobs etc.)
  2. Persona’s team and work environment
  3. Persona’s job focus, scenarios, objectives, challenges etc.
  4. Tools and other technology used
  5. Background research data used to create the persona

1. Company background and situation

For B2B personas, before getting into the role itself, it’s important to provide context, and that starts with the company the persona works in. This is important, because a first step when creating a persona (more on this later) is to go through a segmentation process. Remember, the persona needs to be focused, specific and detailed.

If the HR software was specifically targeting large enterprises (vs. mid-sized companies or startups) then the context of the large enterprise should be reflected in the persona.

This context should include company objectives or challenges that may impact the persona, and other details to give a believable picture of a company. These could be market or industry challenges, or internal issues that are relevant to the team(s) using the personas.

2. Persona background (skills, education, previous jobs etc.)

This is where a lot of personas have problems. Often personas are created with generic demographic information — Phil is 35 years old and has an MBA from Wharton with 10 years of experience in Finance….

Providing some form of work history or previous jobs helps round out the persona in the mind of the reader. This is some of the richness and detail that makes it easier to internalize the role.

In today’s world, as we see new jobs and roles emerging and people moving between roles (e.g. from Design -> Product, or Product -> Marketing etc.) providing that background context is often important.

3. Persona’s team and work environment

People don’t work alone. Maybe some people would prefer that, but we work with and across teams and organizations. Detailing with whom, and how the persona works within their company, is often (though not always) important. If your product helps people collaborate (for example) then this kind of information is critical.

4. Persona’s job focus, scenarios, objectives, challenges etc.

This is the meat (or bread and butter depending on your preferred food-related cliches) of the persona. What do they do in their job, what are their responsibilities, challenges, objectives etc.

Scenarios are critical

I can’t stress enough how important it is to understand and include work- related scenarios in the persona description.

The persona is not just a description of the person/people, but it’s a description of the ROLE, and that MUST INCLUDE what they do in that role.

These work-related scenarios will almost always be at the heart of any discussion you have about the persona when you try to apply it. The other information in the persona will provide additional context to support those discussions.

5. Tools, applications and other technology used

Again, depending on whether it’s helpful, providing an overview of tools and technologies that people use — and we use a lot of tools and technology in our jobs today — can help provide needed context. And we’re not talking about email and calendaring here, but role specific tools or applications.

6. Background research data used to create the persona

It’s one thing to provide the integrated persona — essentially a narrative and other key information based on the research — but it’s important to also provide the background research data that was used in constructing the persona.

How To Create Compelling Personas

The following is the approach I use. There may be other approaches. If those help you achieve your goals, then use those. My goal is to create useful practical personas that teams (product, marketing sales etc.) can internalize and leverage in their work.

Hypothesize, Research, Analyze, Synthesize, Evangelize
Hypothesize, Research, Analyze, Synthesize, Evangelize

1. Hypothesize

Any good research project should start with some hypotheses. i.e.

  • what are you looking to find out
  • what questions do you need answered by the research

And now….here’s Karl

I promised to talk about Karl. I’ll use Karl as an illustrative example in this section. Karl, was probably the first properly researched persona I worked on many years ago, when I was in California. This was back around 2004/2005.

We realized very quickly that we didn’t really understand what an “administrator” actually did and decided to do some fundamental research with our customers.

Segmentation

We wanted to understand what “administrators” did, what responsibilities they had, who they worked with and how they worked to resolve problems. We also wanted to know if there were different types of administrators with different responsibilities and focus, and if so, who were the administrators we should be focused on.

2. Research

Research should be conducted as a team. As much as possible, the primary consumers of the persona, whether they are Product Manager, Engineering and UX, or members of a Marketing team led by a UX Analyst (or Designer etc.) should be direct participants in the research.

There is NO SUBSTITUTE for hearing customers or buyers speak FIRST HAND about their roles, and being able to ask exploratory or clarifying questions directly and in context.

Quantitative Exercises

If needed, add some quantitative exercises — a short survey or card sorting/prioritization exercise — to your interview. Not only does this help break up the monotony of a long conversation, but it allows you to use a different approach to help uncover facts that you may not have found otherwise.

Post Interview Discussion

Immediately after each interview, have a team debrief. Schedule this time as part of the time that is blocked off for each interview. Invite others who will leverage the persona but can’t attend the interviews to attend this part of each session.

  1. It helps ingrain knowledge and build empathy while the information is top of mind
  2. Lesser known details or connections to previous findings can be unearthed and shared.
Not my actual board. Source: https://twitter.com/JLMittelmeier/status/1094976783261278208

Researching Karl

We conducted our persona research as a team. I (as the Product Manager) made most of the customer contacts and set up the meetings, but the entire Dev team (4 or 5 people) attended ALL interview calls. We had a very tiny UX team at the time and they were focused on other work, so they didn’t participate.

3. Analyze

Analyzing the findings should also be done as a team. It’s one thing to hold and discuss all the interviews together, but pulling out the insights, deciding which ones are important and relevant, identifying any gaps you have in the data and following up on those should not be put solely on the shoulders of any one individual — i.e. not just on the Product Manager or the UX Analyst (who are the most likely people to be handed this task).

Analyzing Karl

It was in the analysis process that we named the persona Karl. Karl was one of the interviewees, and we all agreed that his interviews (we did more than one with him) were so rich and detailed that his situation — a global pharmaceutical company with a 7/24 “follow the Sun” administration model — was one we’d really focus on addressing.

  • Database
  • Infrastructure
  • Application

4. Synthesize

Once you’ve completed the research and analysis, it’s time to synthesize the persona. This is where a lot of personas go wrong, because they present the persona with useless data or in forms that don’t help.

  • What is clear? What needs more explanation?
  • What can be removed? What needs to be added?

Synthesizing Karl

The Karl persona came together pretty quickly to be honest. Given we’d all participated in the interviews and analysis together, there was very little disagreement or debate over what the persona needed to include.

The research was eye opening in many ways for us and we got to understand the realities of our target customers at a level of detail that we wouldn’t have had otherwise.

We had to break and rebuild our mental models to align with the research. If we didn’t, then why do the research in the first place?

Application Administration Realities

For example, Karl (the actual person, not the persona) had told us they had 30+ Dev/Test/Prod environments of our product in their company. They were a regulated industry (pharmaceuticals) and had to go through very structured processes when migrating data between or upgrading these environments.

5. Internalize

Internalizing the persona means having people understand the details, be able to truly empathize with the role and use that when having discussions and making decisions.

This is THE MOST critical part of this process. You can do all the other steps, but if people don’t internalize and use the persona, then all that effort is wasted.

How this is done will vary depending on the team and the application of the persona.

Internalizing Karl

It’s hard to measure how well Karl was internalized, but I would say that the level was high.

How Many Personas Should be Created?

This last question is one that comes up often and is important to consider.

A Few Final Words

If you’ve read this far, thanks. I know this was a long article. But, IMHO, the detail was needed.

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take you 30 seconds at the most, but will really be valuable to me. Thanks in advance.

Product Consultant. Contact me for help in building great products, processes and people. http://www.transformationlabs.io