Empathy is central to most design and development processes. Empathy maps help UX designers better understand a user's state of mind when trying to accomplish a task and, similarly, developers employ user stories to provide context for software requirements.
Of course, user experience design is constantly changing, and there's no shortage of novel approaches to understanding the users. In that regard, job stories have become a popular alternative to user stories as they can add more context to proposed features, enabling developers to explore the best ways to help users accomplish a given task.
Let's take a look at the difference between user stories and job stories and how to decide on the best option for your business.
What are user stories?
User Stories are non-technical explanations of a software feature written from the end user's perspective. The goal is to understand why the feature is necessary and the value it has for users, rather than just a technical scope of work.
The general formula for a User Story is:
"As a [persona], I want to [action], so that [expected outcome]." For instance, "As a sales professional, I want to share notes with my colleagues, so we can more effectively close a sale."
Why write user stories?
Product managers write user stories, and the team decides what stories they'll take on during the sprint planning meeting. In addition, teams may estimate the difficulty of user stories using planning poker or other strategies. It makes it easier for the team to ensure that they can realistically complete their story commitments during a sprint.
Atlassian’s Jira makes it easy to organize user stories in a backlog. Source: Atlassian
User Stories are helpful for several reasons:
They focus on the customer rather than the technical specification. That way, you’re less likely to develop a solution that doesn’t match an actual customer need.
They encourage collaboration between design and development teams to arrive at the best possible outcome rather than keeping them isolated from each other.
They spark creative solutions that may not otherwise arise with strict technical specifications.
They create momentum by showcasing actual user-centric accomplishments rather than a checklist of technical tasks with no broader context.
A common criticism of User Stories is that they make some fundamental assumptions. In particular, the "I want to" statement assumes that it is the best action to take. As a result, the team cannot think outside the box when reading the user story because there's no other context, such as the user's actual motivation for wanting the feature.
Improving with Job Stories
Intercom came up with the idea behind Job Stories, and JTBD ultimately refined the concept and gave it a name. According to Intercom, rather than focusing on what users want to accomplish, Job Stories frame every design problem as a job focusing on the triggering event or situation, the motivation and goal, and the intended outcome.
The general formula for a Job Story is:
"When I [situation], I want to [motivation], so I can [expected outcome]." For example, "When I want to find out more about a sales lead, I want to see conversations my colleagues had with a lead in the past, so I don't have to ask them."
Use Job Stories for additional context
Compared to the earlier User Story, the Job Story provides more context as to why the user wants chat functionality in the application. In particular, the user's pain points are much more visible than a User Story could show — and the team can focus on designing to eliminate that pain.
When writing job stories, product managers should provide as much context as possible, focusing on the motivation behind the feature rather than the implementation details. As a result, development teams may identify better ways to accomplish the job than the proposed implementation in a Job Story.
What's right for your team?
The decision between User Stories and Job Stories depends on your business and team dynamics. For example, if you have a mature product and team, you may not need Job Stories or User Stories to empathize with your users. However, if you have a new team or product, these stories can help your team better understand the user.
When to choose User Stories?
User Stories tend to work best in companies with rigid software requirements. If you don't have flexibility in building a feature, user stories can help provide customer-centric thinking without deviating from the desired specification. However, if you have flexible requirements, Job Stories are better to help the team consider problems from every angle.
When to choose Job Stories?
Job Stories are the most useful when you're already taking a Jobs to Be Done (JTBD) approach. Unlike activity-centric design that focuses on tasks like "store a file," JTBD focuses on customer transformations, like "keep a safe backup copy in the cloud." Of course, you're storing a file in both instances, but keeping a safe backup is the driving customer motivation.
Tips to better understand your users
Job Stories and User Stories are just two tools you can use to better empathize with and understand users. There are many other strategies that user experience designers, product managers, and developers can use to ensure that they're on the right track with creating the product. Some popular tools include:
User Personas are detailed profiles of potential or existing customers that explore their personalities, influences, expertise, goals, devices, relationships, and other information. Most teams use multiple personas to reflect different types of users.
Empathy Maps explore what users are thinking or feeling at various points when accomplishing a task. They may also detail users' pain points and what they're saying or doing when using the product to provide greater context.
Journey Maps are visual stories of a customer's interaction with your product. It provides insight into common customer pain points along the way and a template for running experiments to determine whether workflows will be successful.
User Interviews can help provide valuable insights into user thoughts and actions when you have a prototype ready. For instance, you may watch a user navigate an application while talking through their problem.
Summary
Job Stories aim to provide more context than User Stories—and you can use them in the same way throughout the Agile development process. They work best when paired with other customer-focused development practices, such as JTBD, but you can also use them as a strict substitute to promote outside-the-box thinking by developers.
If you need help reaching product-market fit, Intent can help you with everything from pre-development research to marketing and maintenance. Contact us for a free consultation!
Luiza Stelitano
Senior Content Specialist
