At Pixelpillow, we've been working with User stories for years, known to most readers as a way of defining - from the user's perspective - what functionality software should contain: 'as [user], I want [action] so I want [outcome].'
At Pixelpillow, we increasingly noticed that this method was inadequate. We therefore switched to writing Job Stories.

Why don't User Stories work?

User stories have been standard practice in product development for decades. But we systematically ran into the following problems:

• User stories assume a 'type' of user. They are often based on predetermined 'personas (John, 42 years old, installer, 3 children, etc)'. But personas are not 'real' people, and so in establishing them we make all sorts of assumptions about users. And as great philosopher Steven Seagal once said, 'assumption is the mother of all f*ckups'.
• Although never conceived for that purpose, personas have become an easy excuse for many organizations to avoid talking to real users.
• The user story describes what the user wants, but not why the user wants it. So the UX designer has very little context to determine which solution will help the user the most.
• Data analysis (e.g. at facebook) showed that the behavior of different types of user was often more similar than different. So the [user] piece of a user story doesn't matter that much.

In short: a user story makes too many assumptions about the user and gives too little information about "why" a user wants to perform a task.

The Job Story as a better alternative

Since User Stories didn't work, we switched to Job stories. Job stories were developed by Intercom, and stem from the "Jobs To Be Done" philosophy, which assumes that users don't want features or products, but that they want a problem solved. Job stories are then a way of identifying these "problems" and describing them as user tasks.

Intercom itself describes it as follows:

If we understood the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a great outcome looks like, we were confident that we would be building valuable product for our customers.

Intercom

In the shape of a Job Story, this looks like this:

• When [situation: what is the user's context]?
• Do I want to [task: what does the user want to do?]
• Because [motivation: and why?]
• So that I [outcome: what does the customer want to achieve?]

A small difference with a big effect

At first glance, a "job story" looks pretty much like a "user story. So why does this small change make such a big difference? That's because Job stories shift the focus from customer-oriented to task-oriented. With that, we no longer focus on a - often fictional - user, but on the task the user has to do. This makes the story more objective, more concrete and - if we write it well! - much more context about why the user wants to perform this task.

Writing a good job story

Writing job stories is not easy. But if you do it right ¹, it yields a useful, practical list of tasks that are easy to translate into concrete features and components.

01.Talk to your users

Always start with real people. Find out who you are developing the application or site for and find people you can interview or - even better - observe performing their tasks. It is crucial for your product or service to find out what problems your users are trying to solve, and why.

Ask your user two questions:

• what task do you want to perform?
• what is your biggest frustration in doing so?

02.Rewrite your users' input into Job stories

Here it is important that in addition to naming the task (do I want), you also clearly name the situation the user is in (where and when) and the motivation (why does the user want to perform this task?).

When writing user stories, we always tried to be as concise as possible, but that is precisely not the intention when writing Job Stories! After all, we want to give the UX designer as much context as possible about the situation the user is in at the moment he or she wants to perform the task.

So don't write: When I'm hungry, I want,
But instead write: When I am hungry, almost running late, and don't have time to make my own food, I want ...

03.Translate the Job Stories into design solutions

Because Job Stories are more concrete than User stories, they lead faster to the right (design) solution and it is easier to estimate in advance how much time it will take to realize them. This helps prioritize functionality (is it worth this effort to solve this problem for a user?) and makes the final product more user-friendly and valuable to the user.