Back to Methods page

Table of Contents

Contributors

Te Ma

Jenn Giardino

Sim Dhaliwal

Additional tags

No tags are assigned to this entry.

Job stories

Author: Alessandro Contini | Last edit: May 01, 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

User story

Job story

As a [persona], I want to [action], so I can [outcome].When [situation], I want to [motivation], so I can [outcome].
A user story provides a persona.A job story provides context.
Personas are hypothetical, don’t represent actual users, and designers could make assumptions based on a persona that are false.Knowing what the situation is and any conditions that apply are critical to 
understanding why a user wants to complete a task.

 

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 productsI 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 outcomemotivation, 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.

“When…”
(situation)

“I want to…”
(motivation)

“so I can…”
(expected outcome)

When I need help,I want to quickly find a call-to-action to ask my questionso I can get unstuck.
When I am a new user and I need help,I want to easily spot a call-to-action in the UI that would allow me to ask for support so I can find my way around the app to complete my task.
When I am an experienced user and I want to file a bug,I want to quickly trigger a call-to-actionso I can open a support ticket.
When I am an experienced user and I am opening a support ticket to request support,I want to be able to identify myself with my job role (eg. engineer or PM)so that customer support can provide the right detail of information.
When I am a paying customer and I am opening a support ticket,I want my email address to be automatically provided along with my questionso that customer support can eventually reroute the request to the Solution Architect assigned to my company.

Additional resources


methods process

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