Creating personas is one of those project tasks that look simple but are actually quite complex. Like a lot of things in life, the more effort you put in, the better the results. The easy route is to group similar people by a seemingly objective trait like job title. While the thinking here is logical, the results are less than helpful. The purpose of personas is to help product teams understand their users’ needs, behaviors, and challenges. Similar job titles don’t even always correspond to similar job duties, so it’s hard to even know you’re pulling together the right information about your users.
Maybe you’re dead set on creating personas using job titles of your users. In many fields, it’s hard to find the same title from company to company. At one company, an email manager might oversee sending weekly newsletters and responding to any leads coming in. At another, someone with that same title might be in charge of weekly promotional emails, SMS promotional messaging, and quarterly newsletters. Although their titles are the same and their jobs are in the same space, their jobs are as different as they are the same.
If you group personas based on title, you’ll end up frustrated, and with as little context about your users’ needs, behaviors, and challenges as you had when you started.
Let’s break down why mapping personas by job title isn’t effective—and what you can use instead, adding business value in the process.
Job title shouldn’t equate to a persona
The problem with using titles to define personas
Let’s take a look at a hypothetical example. Our client, RestaurantHelper, came to us with a key question: they have two similar products and they want to combine them, but were unsure and nervous about the impact on their users. RestaurantHelper makes products to aid restaurant workers. Although the products are similar, the targeted customers for each product are different.
One is for employees who work at pizza restaurants—the other for people who work at taco restaurants. The client wants to consolidate these two very similar products into one but isn’t sure if it’s possible.
In our initial meetings, they brought us a stack of personas focused only on job titles. While it’s great that they had thought about who uses their products, they had gotten overly granular with the personas. They were making their efforts both overwhelming and completely unhelpful.
Here’s an example of their personas for the taco restaurant:
- Oliver, taco restaurant owner – uses the software as the final person who authorizes menu changes
- Alex, afternoon shift manager – uses the software mainly to authorize menu changes
- Eva, evening shift manager – uses the software mainly to authorize menu changes
- Aria, afternoon shift taco server who has worked there for 3 years – uses the software to gather the order and prioritize the sequence in which the cook makes the food
- Evan, evening shift taco server who has worked there for 1 year – uses the software to gather the order and prioritize the sequence in which the cook makes the food
- Ivan, software installer – sets up the software at various restaurants
- Cara, a restaurant customer – uses it to order food before she arrives
- Cory, a restaurant customer – uses it to order food before he arrives
Here’s an example of their personas for the pizza restaurant:
- Ora, the pizza restaurant owner – uses the software as the final person who authorizes menu changes
- Anna, afternoon shift pizza server who has worked there for 2 years – uses the software to gather the order and prioritize the sequence in which the cook makes the food
- Cara, a restaurant customer – uses it to order food before she arrives
It’s worth noting that there is some useful information we can salvage from personas even if they aren’t well thought-out. For example, because servers use the product the most, we can reason that they will be most affected by combining the two products and any change in the software will significantly impact their work. But that doesn’t tell the whole story.
Despite distinct titles, managers and owners still often work alongside servers and use the product in the same manner—and therefore they will also be impacted by any changes. Because the client’s personas were too focused on each person’s title, it both under and over informs us on the full scope of the users and their needs. Knowing a user’s title does not help product teams understand the users’ needs for the product.
Knowing a user’s title does not help product teams understand the users’ needs for the product.
Solution – evolve from titles to roles
Step 1: Use what you know
During the kickoff workshop, the design team had the client rethink these personas as tasks instead of titles. Because this client was very connected to their users, they used their extensive knowledge to move in a more effective direction.
This resulted in personas that were much more beneficial for improving the product. New personas were created: Initial Menu Authorizer, Final Menu Authorizer, Order Taker, Order Prioritizer, and Food Orderer.
Now the product designers had more tangible workflows to think about. Their work now focused on the user’s processes, their needs in that process, and the goals they needed to achieve with each screen.
Step 2: Continually update
While we tested our first concept with participants, we learned that there was even more fluidity in the titles and the roles. At some locations, if the manager wasn’t available, some servers were permitted to authorize changes to the menu. As we learned about those use cases, we modified how the product could accommodate both users. Through our interactions with the employees of both the pizza restaurant and the taco restaurant, we found very little difference between them. Crucially, this helped our client feel more confident that it was possible to combine products, which is the question they wanted help answering in the first place.
This final deliverable included updated proto-personas that were primarily role-based. Since we hadn’t been able to focus the entire interview on learning about users’ roles throughout our research process, we weren’t comfortable calling them full personas*. However, we still made some observations to update a few aspects of the proto-personas.
Personas add business value
Now that you have more robust, reliable personas, what do you do with them? How does having these help you? They add both intangible and tangible business value.
Intangible
Guide foundational design and development decisions:
When designers and developers understand the broader goals a person is trying to accomplish, they can make better-informed decisions about what may and may not be important to that persona.
For example: if a persona’s main goal is accessing files as fast as possible, a developer will choose a technical framework that loads quickly instead of one that is optimized for super high-quality files.
Connect agile user stories to a larger context:
Agile user stories all share a common format: As a (PERSONA), I (WANT TO), (SO THAT). When product teams understand which type of persona they’re creating a workflow/feature/screen for, they can connect to those articulated needs and use it to inform how to solve those specific problems.
Tangible
Get everyone on the same page:
Everyone on product teams has a different idea of who “our users” are, especially if they haven’t been able to be part of user research. Personas create alignment within the teams, which reduces the number of discussions between teammates with under-informed opinions.
Provide a process for prioritizing development efforts:
Understanding the scope of personas clarifies the distinct needs of a user population. Those nuances help to highlight the needs of each user type, and allow for focus on the largest user type.
Enable informed heuristic evaluations of design/development work:
Personas are an easy vehicle to assess work. Someone wanting to review an initial set of screens or an early working prototype would need to imagine themselves in each persona’s shoes and walk through the experience. This exercise highlights elements that might have been overlooked when working on the details of each screen.
Set a foundation for creating a better user experience:
We can think of personas as one of the many elements in a play. Personas are the characters. But that’s not the only component of a play: you also have the dialogue, plot, and script.
You can think of the dialogue as the user flow. This is where the user interacts directly with the product/workflow/screen/feature, and it reacts.
A play’s plot is like a customer journey. It shows the beginning, middle, and end: how a persona approaches the product, conflicts they encounter, and resolution using the product.
The script is a service design blueprint. A service design blueprint, like a script, contains the story itself and how all the other actors, visible or not, coordinate to tell the whole story.
Personas help us start to understand customer journeys. These journeys lead to a larger understanding of all the players involved. Each artifact increases the context to understand needs, behaviors, and pain points. They’re each a tool to help add clarity where it’s cloudy or obscured.
And better user experiences lead to stronger business metrics:
- Better user-based metrics like loyalty, satisfaction, bounce rates, etc.
- Better business-focused outcomes like profit, ROI, conversion rates, stock performance, support costs, etc.
*The research process used in this project focused on hour-long remote concept testing sessions. For full persona work, we would have needed to spend nearly the entire time on the ins and outs of their roles.
