The argument between persona and jobs-to-be-done
Recently I’ve been working on discovering unmet user needs for my company using the Job-To-Be-Done framework, and I saw some arguments between people who use personas and people who use jobs-to-be-done (JTBD).
A common critique of using personas from the JTBD people is that personas tend to focus on the attributes of the users (like location, age, occupation…) instead of unmet needs. However, that’s not blaming personas, that’s blaming people using it poorly. Focusing on needs is exactly what personas are for. That’s being said, if the persona only shows the demographic attributes of the users, it’s done wrong! Design personas should be based on a significant amount of user research on identifying unmet user needs instead of just collecting web analytics data. Good personas can often serve as a communication tool to summarize the user research and to provide critical insights when you jump to the solution phase. To build a successful persona, we need to have a great understanding of the user goals, pain points, and behavior patterns.
The job-to-be-done also focuses on user needs. The theory is that people hire products to do “jobs”. The common confusion for people who use personas is the term “jobs”. The argument is that people don’t hire a product to simply do work, they hire a product to fulfill their needs. However, the jobs in the JTBD framework is not solutions or tasks, they are meant to reflect needs as well. So what is a “job”? I like what Alan Klement defined it in his article: “A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her.” Sounds familiar? Actually, it sounds very similar to what we are trying to accomplish with personas. The JTBD framework also focuses heavily on qualitative user research. A big difference between the two is the deliverables. Personas do a better job of promoting empathy by creating a fictional user which we can role-play while the JTBD framework is better in communicating desired outcomes.
Unmet needs = goals + pain points
It is extremely critical to discover unmet user needs through research for both personas and jobs-to-be-done. Any unmet needs will always have two components:
- The goal: What you want to accomplish and why you want to accomplish it.
- The pain point: What stopped you from accomplishing it.
Find the true goals of users: discover how users form their emotions
Sometimes it is hard to identify the true needs of users if we keep our user research only on the surface level. It is easy to get the “what you want to accomplish” question answered too quickly but sometimes without knowing “why you want to accomplish it”, it would lead us to the wrong conclusion.
Let me give you an example of an unmet need where finding the true goal is the problem. Go back to my Ann Arbor bus example. If we only ask “what happened” and “what do you want to accomplish”, then a user will tell us a story like this:
“I checked the bus schedule. The bus should arrive at 3:30 pm. I arrived at the bus stop at 3:25. It’s already 3:35 now but the bus is still not here. Why is the bus always late? I become angry and anxious when it’s late. I want the bus to arrive on time so I don’t have to wait here!”
Because the bus rider complained about the bus being delayed, it’s easy to draw the conclusion that the user goal is to get on the bus on time. And eventually, we may form a solution around the speed or the weatherproofness of the bus.
However, if we ask “why do you feel anxious at the bus station when the bus is late?”, we will get a closer look at how this rider forms his emotions — anger and anxiety.
“I have no idea where it is. How long is the delay? Is it delayed or has it gone already? Did they move the bus stop to another place? Should I wait here or should I call a taxi?”
Now, by asking such a question, we have a better idea that the bus rider is not mostly concerned with whether the bus arrives on time. His anxiety came from not knowing the status of the bus. Then the solution should be designed to improve the awareness of the bus status.
Identify the pain points: understand their constraints
Understanding the pain points is to understand what actually stops people from achieving their goals. One thing we tend to forget when we jump to the solution phase is that understanding pain points of your target user is as important as understanding the goals they try to achieve. Sometimes, there are products or services on the market that can help customers achieve their goals but still provide little value to them.
Let me give you an example where pain points stop users from achieving their goals. Two years ago, I worked on a project to design for people with low vision. From our user research, we found out that there were many types of assistive technologies in the market and a lot of them were relatively effective in providing users better reading experience. The people with low vision were also aware of those assistive technologies available in the market, but no one we interviewed utilized them. What was wrong? The price. People cannot afford the devices so they would choose a lower cost, less effective solution. If we created a wonderful device that helps people with low vision achieve their goal of reading without removing the pain point of affordability, it will still become another failed assistive tech.
Since not all of your users share the same pain points but they may need the same goal, it helps you differentiate, select, and prioritize who you will design for.
Recently, I’ve been interviewing people struggling with college essays. A common theme of the goals they want to achieve is to have their essays proof-read and polished by experts. Some people think essay tutors are too expensive while others don’t know where to find tutors or aren’t comfortable talking with tutors. Although the goal is similar, the pain points are different. And because pain points are different, their needs are different and we cannot help everyone achieve their goal using the same solution. Like the picture shown below, any combinations of goals and pain points may form a different user need. To design for people with different pain points, the solutions are also much different.
The chart from the JTBD framework (shown below) is good for you to see what jobs are under-served at a glance. However, it doesn’t tell the reasons why it’s under-served. Knowing why it’s under-served to critical to design decisions in the solution phase. That’s what I think personas can help us.
Comment below to let me know what you think.