{"id":5117,"date":"2021-01-26T00:00:00","date_gmt":"2021-01-25T23:00:00","guid":{"rendered":"https:\/\/careerfoundry.inbearbeitung.de\/en\/blog\/uncategorized\/personas-vs-jtbd\/"},"modified":"2021-08-05T11:06:24","modified_gmt":"2021-08-05T09:06:24","slug":"personas-vs-jtbd","status":"publish","type":"post","link":"https:\/\/careerfoundry.inbearbeitung.de\/en\/blog\/ux-design\/personas-vs-jtbd\/","title":{"rendered":"Personas vs. Jobs-To-Be-Done: What\u2019s The Difference And When To Use Them"},"content":{"rendered":"

User personas<\/a> and Jobs-To-Be-Done<\/a> are two common approaches taken to user-centered design\u2014and there is some debate about which of these approaches is the most effective.<\/p>\n

Earlier this year, UX pro Jared Spool<\/a> called Jobs-To-Be-Done an \u201coccasionally useful gimmick.\u201d This sparked further discussion on Medium and Twitter (we\u2019ll spare you the drama), which essentially boiled down to which of these approaches is useless and which one actually accomplishes something.<\/p>\n

Does it have to be a battle? Maybe not. Let\u2019s take a step back and break both of these approaches down to understand what they look like, how they\u2019re different, and what they share. This guide will cover the basic elements of user personas<\/a> and Jobs-To-Be-Done, as well as their pros and cons. We\u2019ll also discuss how to blend the best aspects of both to achieve a superior strategy.<\/p>\n

Here\u2019s what we\u2019ll look at:<\/p>\n

    \n
  1. What is a User Persona?<\/a><\/li>\n
  2. What is Jobs-To-Be-Done?<\/a><\/li>\n
  3. Personas vs. JTBD: Which to use?<\/a><\/li>\n
  4. A blended approach to Personas and JTBD<\/a><\/li>\n<\/ol>\n

    1. What is a User Persona?<\/h2>\n

    A user persona, done well, is not merely the profile of a fictional user. It isn\u2019t a random collection of information transformed into a fictitious character that embodies your biases. Rather, a user persona is a thoroughly researched aggregate representation of people who actually use your product (or who you\u2019d like to use your product). Ideally, you\u2019ll use more than one persona\u2014and you might even consider exploring persona spectrums to ensure that your design decisions are accessible and inclusive of all<\/em> your users.<\/p>\n

    Here\u2019s an example of what a user persona looks like:<\/p>\n

    \"\"<\/p>\n

    Here we have an image that represents a user, along with relevant demographic information, a summary of the user\u2019s situation needs, goals, activities, motivations, and pain points as they relate to the product.<\/p>\n

    User personas keep your users as the ultimate focal point as you go about identifying pain points along the user journey<\/a> and defining the design problems you will solve.<\/p>\n

    Personas set the starting point for your design process at the person or people you are designing for. They also help to generate empathy with the people involved in designing, producing, and marketing your product.<\/p>\n

    2. What is Jobs-To-Be-Done?<\/h2>\n

    Jobs-To-Be-Done (JTBD) shifts the focus from a hypothetical or aggregate user to what your actual users want to accomplish by using your product.<\/p>\n

    This approach sets the starting point for your design process at the job your users want your product to accomplish. Rather than creating a representation of your users, you ask what job your customers are \u201chiring\u201d your product to accomplish. A JTBD approach starts by asking, \u201cWhat do our users really<\/em> want?\u201d<\/p>\n

    Unlike user personas, JTBD doesn\u2019t have a defined process or specific artifacts that will uniformly result from its implementation. Depending on which two interpretations of JTBD<\/a> you adhere to, the application, process, and resulting artifacts will look different.<\/p>\n

    Alan Klement, discussing the mistakes you can make when learning JTBD<\/a>, emphasizes that JTBD is not a set framework or method: \u201cJTBD is not the study of how people use products, it\u2019s the study of why<\/em>.\u201d<\/p>\n

    Where user personas are themselves artifacts<\/em> (things you could, for instance, put in your portfolio) that result from a process, JTBD is a theoretical approach that helps you to think differently about your product and what it needs to do.<\/p>\n

    What does JTBD look like in practical terms? The classic example of JTBD looks at a drill. A person goes out and buys a drill. What job is it that they\u2019re hiring that drill to accomplish? They probably don\u2019t just want a drill for the sake of having one (unless they\u2019re a drill collector\/connoisseur\u2014is that a thing?). What do they really<\/em> want? They want for there to be a specific-sized hole in a particular part of their wall, table, or other surface. That is the job to be done.<\/p>\n

    3. Personas vs. JTBD: Which to use?<\/h2>\n

    Let\u2019s get a better understanding of what these two approaches look like in practice. We\u2019ll use a hypothetical scenario to illustrate both approaches separately.<\/p>\n

    The Scenario<\/h3>\n

    You\u2019re in the initial stages of designing a mobile meal planning app.Perhaps you\u2019ve got a low- or mid-fidelity prototype, but there\u2019s a long way to go\u2014and right now, anyone involved in the project can have a strong influence the final outcome. You\u2019ve got the concept and the people to help you make it a reality, and you\u2019ve done enough research to know who your users are likely to be.<\/p>\n

    Approach: User Personas<\/h3>\n

    With a variety of people working on this project, all with varying priorities and perspectives, it\u2019ll take some effort to keep everyone\u2019s vision united and moving the in the same productive direction: meeting user needs. Personas are a great way to keep this vision united. By building users\u2019 actual needs and goals into your personas, you create a measuring stick of sorts that you can use to evaluate the design decisions before they are made.<\/p>\n

    You do your research and gather information about the kinds of people who are likely to use your meal planning app. What do they need the app for? Do they need it to be integrated with any other apps (one to help make grocery lists, for example)? When are they likely to be using the app? How much information do they want to record in their meal plans? Do they need recipes to be part of this process?<\/p>\n

    It\u2019s good to think beyond your own assumptions and biases here\u2014embrace the Paradox of Specificity<\/a>. Design for the needs of a very narrow audience and you\u2019re likely to meet a broader set of needs. Example: The OXO Swivel peeler<\/a> was originally designed by Sam Farber in an attempt to help his wife, who had arthritis. As it turned out, the design was a big hit and not only for his target user, but for a much broader market.<\/p>\n

    Your personas tell your team what your users are thinking and feeling and what they\u2019d like to accomplish on your meal planning app. They give specific contextual details that may influence the features you decide to include (or not) and how to organize workflows to ensure that you\u2019re giving your users the information they need, when they need it, and at the right pace. They will even reveal pain points and influence copy and UI elements that come into play later in the process.<\/p>\n

    Pros:\u00a0<\/strong><\/p>\n