Personas have become a “classic” in user research. Protean, they reign as a standard meter of good practices in UX methodologies. However, across the Atlantic, the Jobs-to-be-done present themselves as a challenger.

Rarely questioned, are personas really useful? This is the question we want to discuss with you. Taking a critical look at our practices to deepen them and create new ones, this is also the objective that we are pursuing through our blog.
And when designers ask the questions that will build the User Experience of tomorrow, we share the fruit of their reflection.
Therefore, Laubheimer page, UX Specialist at Nielsen Norman Group, opens the debate on personas vs jobs-to-be-done. Here is the translation of his article.

Personas vs Jobs-to-be-done

Jobs-to-be-done focus on the difficulties and needs of users. Well-executed personas, on the other hand, include additional details about the behavior and attitude of users.
Personas have long been a staple of the user-centered design process; but in recent years, jobs-to-be-done, a technique focused on the needs of the customer, have seen their place take on significant importance.

Definition

Jobs-to-be-done is a set of tools based on the idea that every time users “to hire” a product, they are used to carry out a specific mission (the famous “jobs”) and therefore obtain a particular result. Each JTBD actually corresponds to the complete list of user needs.

The growing popularity of jobs-to-be-done has some saying that personas can be abandoned, with JTBDs being a more useful technique. This opinion is based on a poor initial understanding of the purpose of personas. Let me explain: personas would mainly be demographic representations of users, not taking into account behavioral factors. These factors are however essential to produce good personas in UX Design and product strategy.

JOBS-TO-BE DONE: A USEFUL RESOURCE

Focused on results rather than functionality, the JTBD technique is based on a representation of user needs. It is obtained by qualitative studies conducted with users (field surveys, interviews or simplified usability testing).
One of the steps is to determine what motivates users to “hire” a product (remember, they have missions to complete). It also allows, ideally, to discover the existing competing products whose users are ready to do without in favor of ours. Keeping all of this in mind, the product team can focus on the nature of the basic user constraints and needs. Then, from a new angle, design the features that best meet the main user needs.

An example: delivery services

If an analysis of traditional tasks finds that delivery people often need to print navigation instructions between each stop on their daily route, it is likely that developers will try to simplify the format and the printing instructions as much as possible. A JTBD-centric approach, on the other hand, will focus on the driver's "mission" (i.e. getting navigational advice while driving) and look for solutions to this problem (such as a GPS system voice-guided).
Jobs-to-be-done tools suggest that innovation and great design come from assessing real customer needs and creating a solution that is unfettered by products that already meet them. . However, such a radical stance on innovation may turn out to be a strategy expensive and risky for product improvement. And for good reason, here is the favorite quote of JTBD supporters:

"People don't want to buy a 60mm drill bit, they want a 60mm hole" - Theodore Lewitt

Rather than focusing on a list of features for a product, the jobs-to-be-done framework requires designers to reflect on the results :

• Will users be able to perform (easily and pleasantly) the mission for which they “hired” the product?
• Does this solution offer a better result than existing solutions?

The JTBD approach does not prescribe a particular format or deliverable. But more often than not, job-to-be-done is defined by a sentence stating what users need to do, along with a set of contextual information, such as why and where they are doing it.
Finally, a description of jobs-to-be-done generally brings together two types of criteria. The first are the functional success criteria (the purpose of the mission, the clear instructions to achieve it). The second are the emotional success criteria (which can be divided into users' individual emotional criteria and social considerations, such as how they imagine they will be perceived by others).
Jobs-to-be-done are usually summarized in a single sentence describing what the user needs to accomplish and any important context that could affect the mission (in the following example, traveling for a congress rather than for holidays). Jobs-to-be-done also includes information on objective criteria for functional success as well as subjective criteria for emotional success that contribute to a good experience.
Emotional criteria are often divided into two parts : personal criteria and social considerations.

WELL-DESIGNED PERSONAS ARE MORE THAN A DIRECTORY OF DEMOGRAPHICS

Most of the arguments put forward to suggest that personas have become useless with the arrival of jobs-to-be-done are based on the misconception that these are mainly demographic representations of users.
In addition, demographic data is problematic for decision-making in product design, as it does not provide data on user behaviors and attitudes, and is mostly suited for marketing and advertising purposes.

In fact, personas are meant to be complex representations of users, and go beyond simple demographic or personal data.
Most well-designed personas include a wealth of information, including:

• Demographic details, such as age, marital status and income;
• personal details, such as a short biography, photo and name;
• Cognitive or attitudinal details, such as information on the mental model of the persona, his pain points and perception of the tasks to be accomplished ;
• Goals and motivations for the use of the product;
• Behavioral details on how the persona tends to act when using the product.

Demographic and personal details exist for two main reasons:

• So that project team members create empathy towards the user
• As a mnemonic technique to help make it memorable for the team.

Unfortunately, many personas (which are actually marketing segments that are passed off as such) go no further than the demographic or personal level. This is why this tool is often considered less useful than JTBDs for decision making during design.
An optimal persona is largely based on complex behavioral characteristics, attitude data and mental models, also requiring a qualitative research with real users, to discover the reasons behind user behavior. These complex personas typically include information related to specific goals that users must achieve when using the product. These objectives are directly comparable to the information found in the JTBD definition.

Well-designed personas include details about user goals similar to job-to-be-done descriptions, but are enriched with behavioral, contextual, and personal data that can provide a comprehensive set of insights to guide designers. UX and product teams in their decision making. (We made the following persona as an example in a report on the effective Agile UX product development, but is representative of personas developed for projects that use a user-centric approach to design.)

LEAST: JOBS-TO-BE-DONE DOES NOT PROMOTE EMPATHY

One of the main reasons personas initially focused on realistic representations of users was to move away from an overly formal model of User Experience that revolved around lists of tasks and requirements.
This allows you to think about what the Experience should be for the user. Indeed, the JTBDs nevertheless take some considerations on the emotional and social context of the motivations of the users. However, they generalize this information for the entire user base.
As a result, we miss the key notion of the precise context of use of the target and designers lose the opportunity to create empathy towards the user.

 

PRIORITIZE DIFFERENT USERS WITH PERSONAS

Imagine the following scenario : we are part of a team of designers designing the new version of a desktop productivity application. In recent years, competitors have entered the market with innovative products, and the management of our company wants to redesign their product in order to be more competitive in the market. While it's helpful to survey your existing and potential new customers to find out which JTBDs are important to them, it's also worth noting the key differences between these two groups.
If we start from scratch for the re-design of the application, we will force existing and loyal users to re-train on its use, because of a change in the route they used to take. This will also have a negative impact on their productivity. If we completely redesign an old feature (or, as the “jobs-to-be-done” technique often suggests: create an entirely different and innovative solution for the problem), we risk penalizing the database. current users.

During the design, you have to find the balance between the various possible options according to the type of users, who often have different motivations. While all buyers of a drill press have the same mission to accomplish (drilling holes), a professional will look at the durability of their tool, while a hobbyist who wants to hang a few frames at home will be more attentive to the price. These two considerations being in conflict, it is necessary to differentiate and prioritize the users if we do not want to end up with an innovative but probably unsatisfactory solution.
While the same job-to-be-done may have different requirements for different user groups, the reverse is also true: a user group (or persona) may "hire" the product for different missions in different contexts.

An example: online reservations

I can use the same booking site for business and leisure flights. These types of journeys are in fact distinct jobs-to-be-done bringing very different reflections, but my model remains the same vis-a-vis the system which is presented to me, as well as my attitude and my behavior - that I to one NN/g UX conference or take a hike in Peru. My behaviors and my attitudes are likely to resemble those of certain groups of users as well as to be totally different from those of another group. That's why we create multiple personas: to think about the differences between users that allow us to balance needs and prioritize them among personas.
 

PERSONAS & JOBS-TO-BE-DONE: IT'S A MATCH!

While some think JTBDs can totally replace personas, the two are actually compatible. Depending on the customer's needs and if the team in charge of the product already uses personas or jobs-to-be-done, they can be used in a complementary way: the information provided by the JTBD tool can be integrated into the personas.

For companies that already use JTBDs, there is no need to duplicate a task with personas: specific personas can complement existing JTBDs with unique and differentiating information on functional and/or emotional success criteria.
And vice-versa: if these are the personas that already exist within the company, but which do not contain the complex motivations as well as the behavioral data essential for an effective persona, we can start by improving them with information similar to the JTBD. Let's start by enhancing personas with information similar to jobs-to-be-done: instead of listing the user's goals, let's think of them as goals to be achieved. Let's ask ourselves what the user is trying to accomplish. What are the key success considerations (functional and emotional) for these missions?
If there is a lot of resistance within the company to the creation of personas (if our colleagues are skeptical or our hierarchy struggles to give the green light), but it is still possible to influence the design of the application thanks to an appetite and existing means for user-centered design, JTBDs can be a useful alternative. Indeed, the media coverage around this popular tool can arouse a certain enthusiasm among the client. We have also seen that JTBDs can be used in combination with personas in a second step.
 

Take Away

• Use representative users and assign them representative tasks to perform valid tests. A design can be perfect for one group and terrible for another.
• Differentiate the target audiences and their motivations during the design of a product avoids the appearance of bad functionalities during the process. Users and goals: the necessary ingredients for a successful UX Design!
• Understand the usefulness of a well-executed persona makes it possible to represent the specific needs of the users. The complex information it brings together promotes empathy during product design.

Source

Persona vs jobs-to-be-done, Laubheimer Page @Nielsen Norman Group

Projects

• UX Cards by UX Republic
• persona kit by UX Republic

Context: Sébastien Faure, UX Content Manager @UX Republic @sebfaureUX / Phonesavane Soulivong, UX Communication & Marketing @UX Republic @psvn_soulivong / Translation : Eric Bossin

---