ux research

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.

“People don't want to buy a quarter-inch drill, they want a quarter-inch hole.”

​

• 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.

• Assesses the customer’s real needs and creates solutions to fulfill them.

• Rather than focusing on a list of features for a product, the framework forces designers to think about outcomes - would users be able to (happily and easily) complete the job they “hired” the product for?

• Captures functional success criteria, such as the objective and clear requirements for the job to be successful.

• JTBD has become a more popular tool than personas because they go beyond the personal and demographic details.

JTBD & Personas

• While JTBD are recommended to be backed by qualitative user research, they can be started if a product is in development. Because there will be specific “tasks” that already exist within the product, it is quite easy to start identifying the main jobs to be done prior to qualitative studies. However, the context surrounding those tasks, such as the functional criteria, success criteria and emotional criteria, end up being assumptions, which can be dangerous if not validated with research.

• The ability to craft well articulated and detailed personas (such as inclusion of goals, motivations, behaviors, etc.) is based largely on rich characteristics that come from a lot of data. Personas require a heavy amount of research with real users - like qualitative studies - to uncover the why behind a user’s goals, needs and behaviors.

• JTBD and personas are compatible - they can be used together, or JTBD information can be integrated into personas. Often, JTBD are created first because they are a less expensive and useful way to articulate specific user needs. Personas, when there is enough time and resources to conduct a multitude of research studies, can be backed by and reference the already existing JTBD.

JTBD Workshop

I conducted a design workshop with my team to start establishing user roles. The workshop consisted of 3 phases.

​

Phase 1 - Role Creation: create as many “role” or “task” cards that you can think of that relate to the consumer user

​

• Once ideas slowed down, vote on what roles should be prioritized first and second to begin taking them through the criteria checklist

Phase 2 - Role Description: Take each role through the checklists of context, characteristics, criteria, considerations

​

Use checkmarks against the items that the specific role may apply to.

​

• Checklist:

  • CONTEXT

    • Overall job, workflow, or activity within which the role is played

    • Social situation in which the role is played

    • Physical environment in which the role is played

    • Relationships with indirect users in the role

    • External sources of information, such as paper forms, phone, email, visual observation, in-person interviews

    • Background of role incumbents in terms of training, education, or experience

    • System knowledge expected or required within role

    • Domain knowledge expected or required within role

    • Distribution of user skills in terms of novice, expert, and intermediate usage patterns

    • Required or discretionary nature of role

  • CHARACTERISTICS

    • Orientation, attitude, or emotional state typical within the role

    • Frequency with which role is played

    • Regularity with which role is played

    • Intensity of interaction in the role

    • Duration of interaction in the role

    • Complexity of interaction in the role

    • Volume of information handled in the role

    • Direction of information flow to or from system

    • Criticality of role

  • CRITERIA

    • Ease of learning

    • Retention of learning

    • Efficiency of interaction

    • Reliability of interaction

    • User satisfaction

    • User convenience

    • Accuracy of input

    • Clarity of presentation

    • Safety from error or social repercussions

    • Accuracy of input

    • Clarity of presentation

    • Safety from error or social repercussions

    • Speed

    • Enhancement of proficiency

    • Comprehensibility of presentation

  • CONSIDERATIONS

    • Functions

    • Features

    • Facilities

    • Capabilities

    • Content