Introduction

Personas have long been a useful tool in a user-centered design process; however, in recent years, jobs-to-be done, a new technique for focusing on customer needs, has been gaining steady prominence.

Definition: Jobs-to-be-done (JTBD) is a framework based on the idea that whenever users “hire” (i.e., use) a product, they do it for a specific “job” (i.e., to achieve a particular outcome). The set of “jobs” for the product amounts to a comprehensive list of user needs.

With the popularity of the JTBD paradigm, there are calls in some corners to abandon personas, suggesting that JTBD has emerged as a more useful technique. This point of view is based on a fundamental misunderstanding of the purpose of personas as primarily demographic representations of users, missing the key behavioral considerations that are essential to good personas and that provide much needed guidance for interaction design and product strategy.

Jobs-to-Be-Done: A Useful Tool to Focus on Outcomes Rather than Features

The Jobs-to-Be-Done framework is a representations of user needs born out of qualitative user research, such as field studies, interviews, and discount usability testing. It involves identifying for which goals customers “hire” your product (and, ideally, also finding out if there are competitor products that these users are ready to “fire”). Armed with this understanding, a product team can think about the nature of the users’ core problems and needs from a fresh perspective, and devise product features that solve that main need as best as possible.

While the JTBD framework is new, it is similar in many ways to established methods such as task analysis and use cases, which focus on the context, goals, and steps involved in the interaction with a product. The core differentiator between JTBD and these traditional system-analysis techniques is that JTBD is much less prescriptive about what exactly the users’ task is, and how they will accomplish it. Task analysis and use cases aim to understand the best way in which the product can handle the typical activities that users need to do (and often end up being biased by existing solutions); the JTBD approach moves the focus on desired outcomes and questions whether those typical activities are the way of reaching the outcomes that users really seek.

For example, if a traditional task analysis unearthed that delivery drivers frequently needed to print out directions that showed how to navigate between each stop on their daily route, it’s likely that the design team would focus on making it as easy as possible for the drivers to format and print the directions; however, a JTBD-focused approach would focus on the delivery driver’s “job” (that is, getting navigation guidance while driving), and would look for solutions to that problem (such as a GPS system providing voice guidance).

The JTBD framework suggests that innovation and good design come from assessing the customers’ real needs, and creating a solution that is unencumbered by the existing products that fulfil those needs. However, radical innovation can be a costly and risky product-improvement strategy.

Oftentimes, we hear JTBD advocates referring to the famous Theodore Levitt quote, “People don't want to buy a quarter-inch drill, they want a quarter-inch hole.” Rather than focusing on a list of features for a product, the JTBD framework forces designers to think about outcomes: would users be able to (happily and easily) complete the job they “hired” the product for? Does this solution provide a better outcome than existing ones?

While the JTBD approach does not prescribe a specific format or deliverable, most often a job-to-be-done is defined in sentence format, noting what users have to do, and any key contextual information, such as why or where they do it. Finally, a JTBD description typically captures the functional success criteria (the objective, clear requirements for this job to be successful), as well as the emotional success criteria (which may be further broken down into the users’ individual emotional criteria, and any social considerations, such as how they imagine they’ll be perceived by others).

Job to be done written in sentence format as "travel to another city for a conference", along with user requirements for that job to be done.
Jobs-to-be-done are typically summarized in a single sentence describing what the user needs to accomplish, and any important context that might impact this job (in this example, work travel for a conference, rather than vacation travel). Jobs-to-be-done also typically include some information on the objective, functional success criteria as well as the subjective emotional success criteria that cover what counts as a good experience. The emotional criteria are often broken down into two levels: personal criteria and social considerations.

Good Personas Go Beyond Demographics

Many of the arguments that suggest that personas have become irrelevant with the introduction of JTBD are based on the flawed assumption that personas are primarily demographic depictions of customers. Demographics are troublesome for product or design decisions, as they don’t provide behavioral or attitudinal data, and are mostly suited for making marketing and advertising decisions.

In fact, personas are meant to be rich representations of users, and go further than mere demographic or personal details. Most well-crafted personas include a multitude of information such as:

  • Demographic details, such as age, marital status, or income
  • Personal details, such as a short biography, photograph, and name
  • Attitudinal and/or cognitive details, such as information about the persona’s mental model, pain points, and feelings about the tasks that need to be accomplished
  • Goals and motivations for using the product
  • Behavioral details about how the persona tends to act when using the product

The demographic and personal details exist for two main reasons:

  1.  to build empathy among the product team toward the user
  2.  as mnemonic devices to aid in making them memorable to the team

Unfortunately, many personas (really, marketing segments being masqueraded as personas) don’t go any deeper than the demographic or personal level, which is why personas can often be derided as less valuable for making design decisions than jobs-to-be-done.

Well-executed personas are based largely on rich behavioral characteristics, attitudinal data, and insights about mental models, and they require qualitative research with real users to uncover the why behind users’ behaviors. These rich personas typically will include information related to specific goals that users must achieve when they use the product; these goals are directly comparable to the information found in the jobs-to-be-done definition.

Well crafted persona with Goals and Objectives, along with behavioral considerations included.
Well-crafted personas include details about user goals that are similar to those in jobs-to-be-done descriptions, but are enriched with attitudinal, contextual, behavioral, and personal data that can provide a well-rounded set of considerations to guide UX designers and product teams in decision making. (We made up this persona as an example for the report on Effective Agile UX Product Development, but it’s representative for personas made in projects that employ a user-centered approach to design.)

Jobs-to-Be-Done Don’t Promote Empathy

One of the main reasons that Personas originally focused on realistic user depictions was to move away from the box-checking mentality of lists of features and requirements, and to focus on what the experience should be like for users. While JTBD do include some key considerations about the emotional and social context of a user goal, they generalize them among the entire user base, and therefore miss that key sense of context about users, and lose the opportunity to create empathy among the design team.

Personas Help with Prioritizing Among Different Users

Imagine the following scenario: you are on a design team building a new version of a popular productivity desktop application. In recent years, competitors have entered the market with innovative products, and there is a desire among your company’s leadership to redesign the application to compete with the new products in your market. While it is useful to interview your existing and potential new customers to find out which jobs-to-be-done are important to them, it’s also worth noting the differences that will be key among these groups: if you design from a clean slate, trying to solve the jobs-to-be-done in a way which suits the brand new users, you will likely severely alter the workflows of your dedicated, existing customers (and thus negatively impact their productivity, as they have to relearn the product). If you completely redesign a legacy feature (or, as is often suggested by the JTBD framework, create an entirely different, innovative solution to the problem), you might harm your existing user base.

UX practitioners have to balance design considerations among many different kinds of users, who often have competing interests. While all the purchasers of a drill have the same job-to-be-done of putting holes in things, a professional contractor will care about the durability of the tool, while someone hanging a few pictures in their home might care more about price. These two considerations are in conflict with one another, so if we attempt to address the job without differentiating (and prioritizing) between these users, we’ll probably come up with an unsatisfactory solution, no matter how innovative.

While the same job-to-be-done may have different requirements for different user groups, the reverse is also true: one user group (or persona) may “hire” the product for different jobs in different contexts. For example, I use the same flight-booking website for both work travel and vacation travel. These different types of travel are ultimately distinct JTBD with very different considerations, but, regardless of which situation I’m using the site for, I share the same mental model of how the system works, attitudinal characteristics, and behavioral traits — whether I’m flying to an NN/g UX Conference, or to Peru to hike the Inca Trail. I’m likely to have behaviors and attitudes that are similar to some other users, and quite different than other clusters of users. This is why we create multiple personas: to reflect on the key differentiating factors between our users, so we can balance needs and prioritize among personas.

Personas and Jobs-to-Be-Done Are Compatible

Despite many contrary voices suggesting that JTBD can entirely replace personas, the two are in fact, quite compatible. Depending on your organization’s needs and on whether your team already uses personas or JTBD, they can be used in a complementary fashion, or core jobs-to-be-done information can be integrated into personas.

In organizations that have already embraced JTBD, there is no need to duplicate this work in personas: each persona artifact can reference the already existing jobs-to-be-done that apply to that particular persona, along with any unique, differentiating information about that persona’s functional or emotional success criteria for that JTBD.

If your organization uses personas already, but they don’t include the rich goals and behavioral details that are key to having effective personas, start by augmenting the persona artifacts with JTBD-like information: instead of simply listing the persona’s goals, consider formatting this information as jobs-to-be-done, and ask: what is the user trying to accomplish? What are the key success considerations (both functional and emotional) for those jobs?

If there is a lot of resistance in your organization to creating personas (such as problems getting buy-in from leadership, or skeptical colleagues), but there are resources and appetite for user-centered data to influence product design, JTBD can be a useful alternative. As JTBD are a new and popular technique that has a lot of support in the business literature, there may be enthusiasm for this technique. The JTBD that emerge can always be used in combination with personas (as discussed above) if you are able to get buy-in for a personas project later on.

Summary

The usability of any given design can only be assessed relative to two variables: who are the users and what do they need to do? That’s why it’s critical for the validity of a usability study to recruit representative test users and give them representative tasks to perform. A particular design may be great for one category of users and terrible for another category of users, so if you test with the wrong users, the test results won’t tell you anything about real use. For that exact reason, we need to specify both the target audience and their goals during the design process, so that we don’t design for the wrong users or create the wrong features. Users and tasks: we need both for a UX process to be successful.

Personas are more than simple demographic or marketing segments, and they include rich information on users’ goals, needs, pain points, and expectations, while embedding this information in a narrative format that promotes empathy among the design team. Although jobs-to-be-done can provide a useful way to articulate specific user needs, this information is already represented in well-executed personas.

Learn more about Personas in our full-day seminar.