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.
In Part 1, I covered:
- What Problems Need to be Solved
- 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?
In Part 2, I cover:
- What Information Does a Persona Contain?
- 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.
You can easily Google (or Bing or DuckDuckGo) and find a multitude of persona tempates or canvases to use.
As much as I’m an advocate for templates and canvases (when they are appropriate), creating personas is NOT a place where templates and canvases make sense.
Why? I’m glad you asked.
The reason is simple. A persona needs to be rich, detailed and nuanced. And it needs to contain the information the teams need in the forms they need them.
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.
I’ve been on the receiving end of these kinds of personas. The research behind them was thorough and the effort sincere. They were posted on a wall in a high traffic area so people could see them, read them etc.
But the personas were ineffective because they were superficial, there was no way to dig deeper into them or understand how they were arrived at. So they became another statistic in the history of failed personas.
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.
When I’ve created personas, I’ve used the following general structure:
- Company background and situation
- Persona background (skills, education, previous jobs etc.)
- Persona’s team and work environment
- Persona’s job focus, scenarios, objectives, challenges etc.
- Tools and other technology used
- Background research data used to create the persona
NOTE: I emphasize “general” because there is no one-size-fits-all formula here. The persona needs to be tuned to the needs of the people who will use it.
A persona created for a product team in one company will not contain the same categories as a similar persona created in a different company. They may be similar but they won’t be the same because the context and situations the two companies are focused on will be different.
With that in mind, let’s drill into each of these categories.
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.
Think back to the HR software example at the top of this article. An “executive” in a large enterprise would have different HR needs than an executive in a startup.
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.
Don’t use an actual company though, as that may skew or bias people’s thinking, but create a “representative” company (even if it’s a thin veneer over a real company) that maps to and is analogous to the kinds of companies that are important to the team.
e.g. If your target company is a large bank, don’t use an actual bank like TD Bank (in Canada) or DeutscheBank etc. The realities of those real world institutions may cloud how the persona is internalized. But create a bank with a similar profile — e.g. a fictitious Canadian Federated Bank (CanFed) and use that.
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….
If this kind of information is really important, then include it. But if it’s not (and usually it’s not), then don’t. Put information into the persona that will be used by those who leverage the persona.
For technical personas, e.g. roles that require technical education (specific types of engineers, accountants, data scientists etc.), listing accreditations, specific skills, educational certifications (advanced degrees etc.) can be important. These could be university degrees, online certifications (e.g. Coursera or EdX) or other skills that are relevant to the role/persona.
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.
The work environment is often important to understand. If it’s a high-stress, task-centric workplace, vs. a more creative or unstructured environment, that may be relevant.
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.
It’s important to get into these in detail, because this information will be the most relevant to persona-related discussions and decisions by teams. Don’t just list bullet points of objectives and challenges, but frame them using work-related scenarios for the role.
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.
For example, if the lack of proper automation tools are a problem, provide an example scenario to illustrate this.
In the HR application, if managers have a difficult time conducting proper employee reviews (and that is something relevant to your product plans or company), give examples (based on research) to show exactly what challenges those managers have.
Describe a scenario (or two) that represents what the current situation and challenges are. Also, if possible, provide a future “ideal” state (again based on research) to help the team better understand what the persona would like to be able to easily do.
This information will be invaluable to the team in focusing discussions around the right problems.
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.
In the HR application scenario, perhaps companies don’t have a single integrated HR tool, but are using a variety of different (and possibly homegrown) tools to handle employee reviews, booking vacation time, employee compensation, career planning etc.
Naming specific products and the challenges related to using them will provide additional context and realism to the persona.
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.
Why?
For those people who weren’t directly involved in the research, those who want (or need) to dig deeper, or those with more analytic minds, getting additional details will help them better internalize the persona.
The data also helps answer many questions that arise from people asking why the persona is defined the way it is. If your persona is truly research-based, you will uncover facts or patterns that will be new to you or may not seem intuitive. But they are real and it’s important for people to understand them and believe them, and thus the data helps.
For example: For one persona I worked on for QA engineers, the interview participants (QA teams at our customers) had far less technical expertise than we had assumed. This didn’t sit well with the product team and engineers using the persona, given their own assumptions and experience with QA teams. But once the data behind the persona was shared, they had to accept it and remove the belief they had about the technical skills of QA team members.
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.
I break the process into 5 steps:
1. Hypothesize
Any good research project should start with some hypotheses. i.e.
- what do you know (or believe you know)
- what are you looking to find out
- what questions do you need answered by the research
These questions should be thought through so that your research can be targeted and ultimately effective in finding the information needed to create your personas. The questions you ask will determine the information you get that will feed the persona you define.
Don’t skip this step. It is the basis for a successful research step and ultimately a successful persona.
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 wanted to build a unified, web-based administration interface for our product — a big on-premise data integration platform — that had multiple Windows-based thick-client interfaces. We were also adding a number of new capabilities that also impacted administration of the platform.
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.
This ‘segmentation’ of customers was important. We believed there were different needs across geographies (i.e. Europe vs. North America, vs. Asia), as well as by size of installation, and we needed to understand those distinctions BEFORE any design work was done. This was our core hypothesis.
We made sure to focus a good part of our efforts on some of our biggest customers — companies that had dozens of Dev/Test/Prod installations of our product across their organizations, and who operated globally. We had had a lot of grumbling from these customers about our existing admin capabilities.
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.
e.g. a good simple prioritization exercise is to provide a list of challenges that your target group faces and ask people to rank them in terms of what is most to least important to them. Then drill down on WHY some items are more important and others are not.
This type of exercise opens up the discussion and will give you insights that you wouldn’t get with open ended questions like “What keeps you up at night?” or “What challenges do you face during a typical day?” etc.
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.
Discuss people’s thoughts, what they learned, what was notable, how the interview and findings compared with previous ones etc. This has several benefits:
- It helps build common context with the (extended) team as different people will hear and interpret the same interview differently
- It helps ingrain knowledge and build empathy while the information is top of mind
- Lesser known details or connections to previous findings can be unearthed and shared.
Obviously in today’s world, it’s very easy to record interviews, get complete transcriptions of them, and use qualitative research tools to organize what you’ve found. We didn’t have those tools back then and used the only technology available at that time: Post-it notes. Our walls looked like this.
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.
The research consisted of remote interviews (we had no travel budget) with participants. We had a general set of questions we wanted answered, but a lot of the discussions were free flowing once the customers got talking. We really wanted to hear their objectives, issues, frustrations etc.
We had 2 people take notes (myself and 1 of the engineers) just to make sure we didn’t miss anything. And we definitely had post interview discussions. It was great to have the engineers fully participating. Their questions during the calls were often very different from mine, and the combined findings helped us understand the challenges and objectives well.
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).
Just as the research was a group effort, the analysis should be as well. Every step in this process is an opportunity to deepen the understanding of the team, and to become more aligned with common context.
Pull insights and supporting data out of the interview transcripts and notes, and catalog them in a separate document. This can act as a reference document to support your persona once you create it.
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.
This didn’t mean we’d only focus on his needs — we had several other customer interviews that formed our persona — but his situation really resonated with the team.
We worked with the UX team — they had some time for us at this point — to properly pull the findings together and start constructing the persona.
We also further segmented the findings into different types of administrators. For the record, we identified 4 types of admins:
- Network
- Database
- Infrastructure
- Application
Our core customers fell clearly into the Application Administrator roles, and thus our persona, Karl, was defined as an Application Administrator.
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.
But, if you’ve done your research as a team, then it becomes very easy to identify what is useful and necessary information and what isn’t. Any kind of synthesis takes iteration, but you can quickly pull the key information, create the persona — I prefer well written descriptive text vs. bullets and templates — and share it with others for feedback.
- What makes sense? What doesn’t?
- What is clear? What needs more explanation?
- What can be removed? What needs to be added?
These are all questions that should be asked and answered as the persona is synthesized.
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.
We wrote up a document and shared it with the team and others in product management and engineering who were interested in the work we were doing.
We did get some interesting questions from them; mostly because they didn’t participate in the research and so the findings seemed out of line with their own mental models.
This is one of the real benefits of participating in first hand research. We all have mental models based on what we know. Those models are effectively beliefs or truisms in our minds. And while they are based in (some) fact, they are also based on implicit assumptions, where we fill in knowledge gaps, often subconsciously.
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.
Karl had a team of 4 people working under him. This group of people managed, upgraded and trouble shot 90+ instances of our product worldwide. We had assumed his company had several TEAMS of people doing this job.
Karl’s situation opened our eyes to similar challenges (limited staffing and time) faced by other large customers, and we shared that with other teams in our company. They were all surprised as well, and this finding changed our overall view of how we had to design our management interfaces and capabilities.
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.
Product teams, (Product Managers, Engineers, UX Analysts and anyone else directly working on the product) need to ensure they have a clear understanding of the persona’s objectives, scenarios, challenges etc.
For Marketing and Sales teams, who would focus more on the Buyer persona, and likely were not directly involved in the research (particularly Sales teams), this means holding education sessions with them to get familiar with key findings of the persona, and answering questions they have.
This could also include role playing with them (i.e. having one of the researchers acting as the persona and sales people interacting with them) so they can understand how the persona can support their efforts.
Internalizing Karl
It’s hard to measure how well Karl was internalized, but I would say that the level was high.
“What would Karl do?” became a common question when we were trying to decide whether to support something or during design discussions. Some people felt a bit odd talking about the persona with a proper name, but over time everyone, at least outwardly, seemed to adjust well.
The product work on the “Admin Console” as it came to be known, went on for many months. We had a beta of it, and many of our persona interview customers (including the real Karl) participated in it.
Karl was amused when we told him we had named our persona after him, and he became even more invested in helping us get the functionality right.
When we had our release, we generally got good feedback, but there were a number of limitations and design issues that arose that we had to deal with. I’d say we got the Admin Console 80% right, which is honestly about the best one can imagine given the situation back then.
How Many Personas Should be Created?
This last question is one that comes up often and is important to consider.
With the Admin Console, we created 1 persona. Karl was focused on very large enterprise installations of our product. We had other segments of customers that we were building for of course. We had smaller and mid-sized installations as well. e.g. anywhere from 1 Dev/Test/Prod setup up to an average of about 4 or 5 of them.
But we felt we had a good understanding of the needs of those customers and we really wanted MORE focus on the needs of those largest customers. So we used Karl to help us get that focus.
If we were starting from scratch and building a brand new product, as opposed to enhancing an existing product, I probably would have had 2 or 3 personas (depending on what our segmentation and what the research supported).
Then we could have had different discussions and used each of the personas in the proper context. We could even have had discussions like, “This might work for Karl, but would it work for Sheema?” (assuming Sheema was a persona created for a mid-sized enterprise admin).
And, just to repeat, none of this persona talk is implying you only use personas and never go back and talk to real human beings. Of course you do. But there are times where talking to people is necessary and times when it’s not. The personas help ensure that when you’re not talking to people, you’re talking about their needs with empathy and in a common, fact-based context.
A Few Final Words
If you’ve read this far, thanks. I know this was a long article. But, IMHO, the detail was needed.
Personas are a tool, and like any tool, they can be used well or used poorly. The challenge is that you also have to create the tool before you can use it, and that makes them doubly challenging.
There are a lot of challenges to overcome when using personas. My advice is to start small (e.g. 1 key well-segmented persona), research it well as a team and use it in a product or launch or other initiative.
Then expand your usage to additional personas, especially for new product initiatives and share that information within your company so others get familiar with your work, the concept of personas and why they are important.
Also finally, keep your personas updated as you learn more about your target users, buyers, influencers, prospects etc. Given how rapidly our world is changing, what was relevant and accurate last year may be out of date this year. e.g. Think of how the pandemic has impacted virtually every role in every company.
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.
===> Click here. <===
Saeed
