Empathy is central to most design and development processes. For example, empathy maps help UX designers better understand a user's state of mind when trying to accomplish a task. Similarly, developers employ user stories to provide context for software requirements. In both cases, the goal is to put yourself in the user's shoes.
Of course, user experience design is constantly changing, and there's no shortage of novel approaches to gaining empathy. For example, job stories have become a popular alternative to user stories that 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.
User Stories are non-technical explanations of a software feature written from the end user's perspective. Unlike technical requirements, User Stories use non-technical language to provide context to development teams. The goal is to understand why the feature is necessary and its value 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."
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. That way, it's 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
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 teams siloed.
They spark creative solutions that may not otherwise arise with strict technical specifications that leave no room for creativity.
They create momentum by showcasing actual user-centric accomplishments rather than a checklist of technical tasks with no wider context.
A common criticism of User Stories is that they make some fundamental assumptions. In particular, the "I want to" statement assumes that it's 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 situation or the user's 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."
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 point is much more visible (e.g., the annoyance of asking colleagues about past conversations with a sales lead) than the User Story leads on—and the team can design 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.
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.
Job Stories also work best 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.
If you're interested in learning more about the JTBD framework, you can download Alan Klement's excellent book on the subject for free or purchase a hard copy on Amazon.com. The JTBD blog also contains a wealth of information about the approach to help you better empathize with customers and build great products.
Building Empathy with Users
Job Stories and User Stories are just two tools you can use to better empathize with and understand users. In addition to these tools, there are many other strategies that user experience designers, product managers, and developers can use to ensure that they're on the right track building products that customers will love.
Example of an empathy map canvas. Source: Human Scale Business
User Personas are detailed profiles of potential or existing customers that explore their personality, 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 the user's 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.
The Bottom Line
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!