Job stories

Author: Matt Carrano | Last edit: December 04, 2024

What is a job story?

Also known as “jobs to be done,” job stories help define user tasks in product design. They are a more generalized version of user stories, with a focus on explaining the triggering situation or context of the task, rather than revolving around who is taking the task (the persona).

“When I'm a parent who needs to provide food for my family and it’s close to meal time and I'm on the road, I want to order take out so that I can make sure food is available for my family when it’s time to eat.”

Why write job stories?

In their most popular format, user stories imply a specific persona has a need or desire.

“As a parent, when it’s close to meal time, I want to order take out.”

There’s nothing wrong with personas and they are useful in many different aspects of the product development process (eg. stakeholder alignment), however there’s risk in associating a specific persona with a need and a task when no –or not enough– research has been executed to inform the persona creation.

In such a scenario, the causality of the user’s need relies on assumptions the designer and the team are making about the supposed persona, and no evidence is provided of the reason why the user might be feeling such a need or desire.

On the other hand, job stories shift the focus to the cause of a specific need or desire: when something happens, the user feels the need or desire to do something else. The focus on causality not only brings center stage the reason why the user might be feeling the specific need, but can also provide important context to the user's situation. For instance what the user was trying to achieve when something happened or when they felt a specific need.

User story vs job story

Wrapping up, why are job stories important?

• They describe the what and the why, by describing motivation and context.
• They allow the team to focus on the how, by not prescribing any particular implementation.
• They make the user’s pain points easily visible and help the team consider problems from every angle.
• Additionally, they prepare the ground for further validation of the cause-effect relationship, through methods like user interviews or usability testing.

When should you write job stories?

User job stories are useful in the Discovery phase of the design process – pre- and post-user-research

Before a user research study, job stories can help get alignment across the team on what user needs and outcomes need to be validated. But it’s actually after user research that job stories can provide the most value by turning user insights into actionable prompts for designers.

Job stories, as well as user stories, are also fundamental in driving the conversation between stakeholders across the product development process, from problem framing, to design of solutions, and implementation. It’s important to accompany design work with job stories not only to get alignment but also to provide context around design decisions when delivering mockups and prototypes to the Engineering team.

How to write job stories

The best way to write user job stories is follow the template:

"When [situation], I want to [motivation], so I can [outcome]."

Be specific, focus on user needs, and articulate clear motivations and outcomes to guide product development effectively.

For example, for a user who wants to purchase something at an e-commerce online store you can write:

“When I visit the homepage, I want to see a list of the most popular products, so I can easily find trending items.”

This format helps to focus on the user’s needs and the context in which those needs arise. It’s a great way to ensure that the product or feature you’re developing is directly addressing a user’s requirements.

Pro tip:

• Start broad and add details little by little, but make sure to add as many as you can! (eg. I want to see a list of the most popular products > I want to see a list of the most popular products available in my country)
• When you are provided a user story or a vague product requirement (eg. users want to see the most popular products in the homepage) ask yourself and your stakeholders basic questions such as when and why (eg. why do they want to see the most popular products? When do they want to see them? Which previous screen is the user coming from?)
• While in the process of expanding your user job story with further details you might end with multiple valid options for outcome, motivation, or situation, and that’s totally fine! Time has come for you to branch your initial job story into multiple job stories. By doing so, you’re going to map more granular user needs and you’ll be able to provide a more comprehensive user experience.
• The job stories template does not include the persona, but if you and your team have a good understanding of persona details and rely heavily on them in product conversations you can always attach the persona or role to your job story (eg. As a platform engineer, when I visit the homepage…)

Examples

Here are a few examples of job stories for a user who is looking for help. Please notice how you can start from a very broad and generic story and add details little-by-little to turn it into a more specific and focused job story.

Additional resources

• Replacing The User Story With The Job Story
• 5 Tips For Writing A Job Story
• Job Stories - Datopian Playbook
• User Stories vs. Job Stories: What’s Right for You?
• Job Stories Offer a Viable Alternative to User Stories
• Better stories with “Job Story” 😎

Get in Touch!

Spotted a typo? Any feedback you want to share? Do you want to collaborate? Get in touch with the UXD Methods working group using one of the links below!

Drop us a message on the #uxd-hub Slack channel

Submit Feedback