Jobs to be Done
It's a methodology that changes the way we think about product design. Rather than focusing on demographics, JTBD focuses on understanding the goals and objectives that the user faces regardless of the solution.
JTBD helps us understand the real motives behind a user’s actions: going to the gym, opening a banking product, and so on. The methodology answers the question why the user “hires” or “fires” the product.
It is truly a very powerful tool for identifying user motivation and putting users into context of their tasks and goals.
In principle, JTBD deserves a separate article to reflect all its facets. Now let’s analyze it without small details, so that you can form an impression and apply it in your work.
When is it best to use?
In the early stages of designing a product or feature. However, no one is stopping you from rethinking your approach and learning more about users at any given time
What problems does it solve?
- Stop wasting time on unnecessary functionality
- Start to better understand your users or clients
- Prioritize tasks based on their impact on users
It's a methodology that changes the way we think about product design. Rather than focusing on demographics, JTBD focuses on understanding the goals and objectives that the user faces regardless of the solution.
JTBD helps us understand the real motives behind a user’s actions: going to the gym, opening a banking product, and so on. The methodology answers the question why the user “hires” or “fires” the product.
It is truly a very powerful tool for identifying user motivation and putting users into context of their tasks and goals.
In principle, JTBD deserves a separate article to reflect all its facets. Now let’s analyze it without small details, so that you can form an impression and apply it in your work.
When is it best to use?
In the early stages of designing a product or feature. However, no one is stopping you from rethinking your approach and learning more about users at any given time
What problems does it solve?
- Stop wasting time on unnecessary functionality
- Start to better understand your users or clients
- Prioritize tasks based on their impact on users
If you are already using User Story, you can use JTBD in parallel, this will expand your understanding of users and the tasks facing you. Briefly speaking about the difference between the two artifacts:
JTBD: Used during the research and analysis phase of user needs. They help the team better understand what motivates users and what problems they want to solve.
User Stories: Used during the design and development phase of a product. They help the team describe specific features and requirements for the product.
Basic Artifacts
Job Statement
Job Story
First, you need to choose a role whose motives you want to describe. The tasks and needs of the administrator will differ from the tasks of the average user, and the tasks of the seller from the tasks of the buyer. There are no universal solutions. Even within your organization, people have different motivations depending on their position and role.
Then we formulate a Job Statement - this is a short and high-level description of the user’s task.
Job Statement is formulated according to the formula:
Verb + Object + Qualifier
A correctly drafted Job Statement follows these simple rules
Does not mention a specific technology, solution, technique or technique
Does not contain complex concepts. No AND or OR
Contains no observations or preferences
Begins with a verb
Doesn't change over time
Job Story is formulated according to the formula:
When [situation], I want [motivation] so that I can [desired outcome]
For example:
When a new client signs up, I want to be notified so I can start a conversation with them
When I'm preparing to travel to work, I want to check the current weather along the way to minimize the chance of getting wet
When I am one of the top authors on a social network, I want this information to be displayed on my profile so that my reputation as an expert grows
When compiling these artifacts, it is important not to let your imagination run wild and to work only with information that you have received from your users and clients. If obtaining such information is difficult, then treat them as hypotheses that require further testing.
What does USM consist of?
Activities
Activities are the highest-level tasks that the user faces: registration, selecting goods, checking a bank account, etc.
Steps
Steps are a decomposition of Activities into a sequence of more specific actions. For example, the Registration Activity might include steps such as filling out a form and confirming registration, while the Checkout Activity might include “View Cart,” “Enter Shipping Address,” and “Enter Payment Information.”
Details
Details are the lowest level of our USM. Specific actions that the user must perform to complete the step. For example, the details of the “Entering payment information” step can be “Selecting a payment method”, “Entering a plastic card number” and “CVV input”
Now let's divide our stories into iterations. Let's imagine that we have gathered in a cozy grooming area and are discussing our task. As a team, we understand that recommendations are a cool topic, but we currently have neither the understanding nor the resources on how to make these recommendations, so we will send this story to the backlog.
Next, let’s move on to the “Delivery address” step, here we seem to be able to do everything, we know how to do everything, but we believe that saving several delivery addresses is not as important at first as entering one, so we will transfer them to the next iteration.
And finally, enter your payment information. Different payment methods are cool, but for now we can only accept plastic cards. It will take us a little time to connect to other payment systems, so we will take this story to work in one iteration, and adding a few cards will go into the next. The client will have the opportunity to pay for the purchase.
The most common mistakes in using USM
Insufficient decomposition
Fitting specific solutions
Using a form but using a different methodology such as function mapping or CJM
Impact-Effort Matrix
A simple prioritization tool for the entire team. No formulas, arithmetic or unclear parameters. Only items from your backlog and only two parameters Effort and Impact.
Some may not find it as deep as RICE or MoSCoW, but the effort-to-result ratio is unparalleled. It's funny that this is exactly what this matrix is called :)
When is it best to use?
When prioritizing a backlog or planning a project
What problems does it solve?
- Prioritization of tasks
- More efficient use of team resources
- Highlighting “quick wins” and “money pits”
- Helps to better compare functionality with competitors’ offerings
- Increases team cohesion
How to use
The matrix consists of two axes:
Y Axis, Impact
The higher an item is on this axis, the greater the impact it has on users and the business.
X Axis, Effort - Effort
The further to the right an object is on this axis, the more effort we need to spend to implement it
And four quadrants:
Quick Wins - Quick wins
The most desirable quadrant for us. This includes those tasks that have maximum impact with minimal effort. These are the tasks we should do first
Big Bets - Big bets, Big projects
Tasks that are high impact but also labor intensive. These are strategic goals that are too big and complex to accomplish in one iteration or increment, but are too important to give up. Requires proper decomposition and delivery planning.
Money Pit
Tasks with high labor costs and near-zero value. As we understand from the name, such tasks simply suck money from our project and give nothing in return except depression and existential crisis. We must get rid of such tasks immediately, no “later” or “what if it comes in handy” - these are weeds and parasites of our backlog
Fill-ins - Fillers, Fillers
Tasks with minimal effort, but also minimal value. Such tasks are worth taking on if you have already figured out everything that really adds value, and you just want to do some fun stuff
After we found out what the matrix consists of, all that remains is to place our tasks in its quadrants. To do this:
Gather your cool multifunctional team offline or online
Display stories or ideas on the board as sticky notes.
JTBD: Used during the research and analysis phase of user needs. They help the team better understand what motivates users and what problems they want to solve.
User Stories: Used during the design and development phase of a product. They help the team describe specific features and requirements for the product.
Basic Artifacts
Job Statement
Job Story
First, you need to choose a role whose motives you want to describe. The tasks and needs of the administrator will differ from the tasks of the average user, and the tasks of the seller from the tasks of the buyer. There are no universal solutions. Even within your organization, people have different motivations depending on their position and role.
Then we formulate a Job Statement - this is a short and high-level description of the user’s task.
Job Statement is formulated according to the formula:
Verb + Object + Qualifier
A correctly drafted Job Statement follows these simple rules
Does not mention a specific technology, solution, technique or technique
Does not contain complex concepts. No AND or OR
Contains no observations or preferences
Begins with a verb
Doesn't change over time
Job Story is formulated according to the formula:
When [situation], I want [motivation] so that I can [desired outcome]
For example:
When a new client signs up, I want to be notified so I can start a conversation with them
When I'm preparing to travel to work, I want to check the current weather along the way to minimize the chance of getting wet
When I am one of the top authors on a social network, I want this information to be displayed on my profile so that my reputation as an expert grows
When compiling these artifacts, it is important not to let your imagination run wild and to work only with information that you have received from your users and clients. If obtaining such information is difficult, then treat them as hypotheses that require further testing.
What does USM consist of?
Activities
Activities are the highest-level tasks that the user faces: registration, selecting goods, checking a bank account, etc.
Steps
Steps are a decomposition of Activities into a sequence of more specific actions. For example, the Registration Activity might include steps such as filling out a form and confirming registration, while the Checkout Activity might include “View Cart,” “Enter Shipping Address,” and “Enter Payment Information.”
Details
Details are the lowest level of our USM. Specific actions that the user must perform to complete the step. For example, the details of the “Entering payment information” step can be “Selecting a payment method”, “Entering a plastic card number” and “CVV input”
Now let's divide our stories into iterations. Let's imagine that we have gathered in a cozy grooming area and are discussing our task. As a team, we understand that recommendations are a cool topic, but we currently have neither the understanding nor the resources on how to make these recommendations, so we will send this story to the backlog.
Next, let’s move on to the “Delivery address” step, here we seem to be able to do everything, we know how to do everything, but we believe that saving several delivery addresses is not as important at first as entering one, so we will transfer them to the next iteration.
And finally, enter your payment information. Different payment methods are cool, but for now we can only accept plastic cards. It will take us a little time to connect to other payment systems, so we will take this story to work in one iteration, and adding a few cards will go into the next. The client will have the opportunity to pay for the purchase.
The most common mistakes in using USM
Insufficient decomposition
Fitting specific solutions
Using a form but using a different methodology such as function mapping or CJM
Impact-Effort Matrix
A simple prioritization tool for the entire team. No formulas, arithmetic or unclear parameters. Only items from your backlog and only two parameters Effort and Impact.
Some may not find it as deep as RICE or MoSCoW, but the effort-to-result ratio is unparalleled. It's funny that this is exactly what this matrix is called :)
When is it best to use?
When prioritizing a backlog or planning a project
What problems does it solve?
- Prioritization of tasks
- More efficient use of team resources
- Highlighting “quick wins” and “money pits”
- Helps to better compare functionality with competitors’ offerings
- Increases team cohesion
How to use
The matrix consists of two axes:
Y Axis, Impact
The higher an item is on this axis, the greater the impact it has on users and the business.
X Axis, Effort - Effort
The further to the right an object is on this axis, the more effort we need to spend to implement it
And four quadrants:
Quick Wins - Quick wins
The most desirable quadrant for us. This includes those tasks that have maximum impact with minimal effort. These are the tasks we should do first
Big Bets - Big bets, Big projects
Tasks that are high impact but also labor intensive. These are strategic goals that are too big and complex to accomplish in one iteration or increment, but are too important to give up. Requires proper decomposition and delivery planning.
Money Pit
Tasks with high labor costs and near-zero value. As we understand from the name, such tasks simply suck money from our project and give nothing in return except depression and existential crisis. We must get rid of such tasks immediately, no “later” or “what if it comes in handy” - these are weeds and parasites of our backlog
Fill-ins - Fillers, Fillers
Tasks with minimal effort, but also minimal value. Such tasks are worth taking on if you have already figured out everything that really adds value, and you just want to do some fun stuff
After we found out what the matrix consists of, all that remains is to place our tasks in its quadrants. To do this:
Gather your cool multifunctional team offline or online
Display stories or ideas on the board as sticky notes.
Give each participant stickers or some other thing that indicates votes. These stickers should be of different colors so that we can easily distinguish Effort from Impact
Each team member is given a number of votes equal to half of the tasks being evaluated. With 8 tasks, each participant will receive 4 votes. A limited amount encourages a person to spend it only on important tasks.
Initially, the rule states that each team member votes according to their expertise, for example, designers only evaluate impact, and development only evaluates effort. However, the time spent on design is often also important, so here you can divide the stickers in half: 2 for effort and 2 for value
Next, the team votes. You can put several stickers on one story
User Flow
Now we know not only what to do, but also when and in what order. All that remains is to determine how. We use the simplest, cheapest and fastest way for this - we create a flowchart of the user journey.
Most often, such diagrams use a happy path, that is, a linear user path, all steps of which lead to success, however, I do not recommend being so optimistic at this stage; on the contrary, I urge you to consider as many alt-flows and negative scenarios as possible. At this stage it will be fast and cheap.
Many people see this step as a bit of an overkill, but such a flowchart can reveal quite a lot of bottlenecks in your flow without the need to create prototypes, and will also save you from asking questions from development: “what happens if something goes wrong?”
When is it best to use?
When working out the logic for completing a task before creating interface layouts. To analyze bottlenecks in existing interfaces.
What problems does it solve?
- Clearly shows the entire user journey
- Easily allows you to spot potential problems before development begins
- Helps you more carefully compare the functionality of your product with how it is implemented by competitors
- Gives the team a single, clear view of what the user journey looks like
How to use?
1. Determine the main flow
Imagine the most direct path to achieving your goal. Describe this path from start to finish. What does the user need to do to achieve the goal? Before defining the remaining steps of a process, start by defining its starting and ending points. This will help set limits.
2. Identify alternatives
Identify moments at which the user can make choices that influence his actions. These are decisions that affect flow. For example, selecting "Login" or "Continue as Guest" on the checkout page. At this step, you should ask yourself the question “What if?” as often as possible.
3. Create Alternative Streams
For each alternative, create your own thread. Describe what steps and decisions will take the user along this alternative path to the goal. How can he get back to the main path?
4. Identify bottlenecks
Now that you have a detailed diagram of your user journey in front of you, take a closer look at it to see if there are steps that could be eliminated or confusing logic that could be simplified? Are the actions consistent with the user's goals and needs?
5. Share with your team
Like previous methods and artifacts, UserFlow helps the team to be in a single information field and unambiguously interpret business and system requirements. Surely the team will have a couple of good ideas that will make this flow more valuable for the user, more profitable for business and cheaper to implement
Each team member is given a number of votes equal to half of the tasks being evaluated. With 8 tasks, each participant will receive 4 votes. A limited amount encourages a person to spend it only on important tasks.
Initially, the rule states that each team member votes according to their expertise, for example, designers only evaluate impact, and development only evaluates effort. However, the time spent on design is often also important, so here you can divide the stickers in half: 2 for effort and 2 for value
Next, the team votes. You can put several stickers on one story
User Flow
Now we know not only what to do, but also when and in what order. All that remains is to determine how. We use the simplest, cheapest and fastest way for this - we create a flowchart of the user journey.
Most often, such diagrams use a happy path, that is, a linear user path, all steps of which lead to success, however, I do not recommend being so optimistic at this stage; on the contrary, I urge you to consider as many alt-flows and negative scenarios as possible. At this stage it will be fast and cheap.
Many people see this step as a bit of an overkill, but such a flowchart can reveal quite a lot of bottlenecks in your flow without the need to create prototypes, and will also save you from asking questions from development: “what happens if something goes wrong?”
When is it best to use?
When working out the logic for completing a task before creating interface layouts. To analyze bottlenecks in existing interfaces.
What problems does it solve?
- Clearly shows the entire user journey
- Easily allows you to spot potential problems before development begins
- Helps you more carefully compare the functionality of your product with how it is implemented by competitors
- Gives the team a single, clear view of what the user journey looks like
How to use?
1. Determine the main flow
Imagine the most direct path to achieving your goal. Describe this path from start to finish. What does the user need to do to achieve the goal? Before defining the remaining steps of a process, start by defining its starting and ending points. This will help set limits.
2. Identify alternatives
Identify moments at which the user can make choices that influence his actions. These are decisions that affect flow. For example, selecting "Login" or "Continue as Guest" on the checkout page. At this step, you should ask yourself the question “What if?” as often as possible.
3. Create Alternative Streams
For each alternative, create your own thread. Describe what steps and decisions will take the user along this alternative path to the goal. How can he get back to the main path?
4. Identify bottlenecks
Now that you have a detailed diagram of your user journey in front of you, take a closer look at it to see if there are steps that could be eliminated or confusing logic that could be simplified? Are the actions consistent with the user's goals and needs?
5. Share with your team
Like previous methods and artifacts, UserFlow helps the team to be in a single information field and unambiguously interpret business and system requirements. Surely the team will have a couple of good ideas that will make this flow more valuable for the user, more profitable for business and cheaper to implement
Wireframes
So, we are at the finish line, one step before the final decision. And now all we have to do is transfer all our previous solutions to real interfaces. Don’t rush to uncover Figma, we have another cheaper and faster way to test all our assumptions and hypotheses - Wireframes are deliberately rough sketches of interfaces.
When is it best to use?
When developing new ideas. When adding something new to existing solutions
What problems does it solve?
- Saves time on creating layouts
- Speeds up decision making
- Increases synchronization within the team
- Allows you to quickly and cheaply test hypotheses
Wireframes are often reluctant to be used, considering them useless in a situation where there are already established patterns or designs. It would be a mistake to think that wireframes cannot help us in this case.
The main advantage of wireframes is precisely that it would never occur to anyone to perceive them as at least a more or less real design. This means that we can skip that part of the comments that concerns wording, values, and indeed any other details that are important only in production. Now, instead of paying attention to details, people will focus on logic and convenience.
The second equally important factor is speed. Since the wireframe is a priori a rough sketch, there is no point in making it very detailed; we can “paint with broad strokes” and this will not affect the result in any way. Thanks to this, the speed of creating new layouts and making any changes becomes very high compared to if we immediately started creating a High-Fidelity layout.
The third plus is team interaction. In order to draw wireframes, you don’t need any additional knowledge; even a child can do it. This makes wireframes an indispensable tool for exchanging ideas within a team, as well as synchronizing final decisions. Better to see once than hear a hundred times. By giving each team member the opportunity to express themselves in a visual and structured way, you can make decisions much faster and take away the beauty of “I thought it would work like this...” situations.
So, we are at the finish line, one step before the final decision. And now all we have to do is transfer all our previous solutions to real interfaces. Don’t rush to uncover Figma, we have another cheaper and faster way to test all our assumptions and hypotheses - Wireframes are deliberately rough sketches of interfaces.
When is it best to use?
When developing new ideas. When adding something new to existing solutions
What problems does it solve?
- Saves time on creating layouts
- Speeds up decision making
- Increases synchronization within the team
- Allows you to quickly and cheaply test hypotheses
Wireframes are often reluctant to be used, considering them useless in a situation where there are already established patterns or designs. It would be a mistake to think that wireframes cannot help us in this case.
The main advantage of wireframes is precisely that it would never occur to anyone to perceive them as at least a more or less real design. This means that we can skip that part of the comments that concerns wording, values, and indeed any other details that are important only in production. Now, instead of paying attention to details, people will focus on logic and convenience.
The second equally important factor is speed. Since the wireframe is a priori a rough sketch, there is no point in making it very detailed; we can “paint with broad strokes” and this will not affect the result in any way. Thanks to this, the speed of creating new layouts and making any changes becomes very high compared to if we immediately started creating a High-Fidelity layout.
The third plus is team interaction. In order to draw wireframes, you don’t need any additional knowledge; even a child can do it. This makes wireframes an indispensable tool for exchanging ideas within a team, as well as synchronizing final decisions. Better to see once than hear a hundred times. By giving each team member the opportunity to express themselves in a visual and structured way, you can make decisions much faster and take away the beauty of “I thought it would work like this...” situations.
How to use
If in the case of User Flow we wanted to consider as many alternative options for the development of events as possible, here we want to focus on one, maximum two: the best and the worst. Since there is no point in wasting time on the rest at this stage. We will add them on the final layouts.
We take our User Flow and begin to transfer its steps into wireframes. Wireframes can be drawn anywhere: on paper, in paint, in figma, in miro or in special programs such as balsamic
We don’t spend a lot of time on unnecessary details, we detail only the parts necessary to complete the path, but only to the extent that it is clear that they are they
We show it to the team, collect feedback, exchange ideas, generate new wireframes right at the meeting (yes, this can be done so quickly)
We check on users
Conclusion
Using these techniques helps teams better understand user needs, identify key features, and create user experiences that best meet audience expectations.
Using Jobs to be Done (JTBD) helps you focus on solving real user problems, while User Story Mapping allows you to structure and organize requirements into a form that is attractive to the team. The Impact-Effort Matrix helps prioritize development based on cost and benefit, while Userflow and Wireframes are powerful tools for visualizing and optimizing the user experience.
Combining these methodologies provides the team with clear and structured tools to make informed decisions at every stage of product development. Ultimately, this leads to the creation of clearer, more valuable products that deliver maximum business impact.
