We have used user stories as part of our design and development process for many years. You could find several mentions of them throughout our playbook. We used user stories to give designers and developers context to the problems that the user is having and give space for them to solve that problem while building the product.
A typical user story resembles the following:
As a [persona/role] I want to [action] so that [outcome/benefit].
During our last few Philly based projects, we have altered the format of the user stories to instead utilize jobs stories. Jobs stories slightly revise the format to be less prescriptive of a user action, and thereby give more meaningful information for the designer and developer to build for the user’s expected outcome.
A typical jobs story resembles the following:
When [users work/life context] I want to [motivation] so that [outcome/benefit].
Here are a few examples of the same feature story in user story and jobs story format:
User Story: As a developer, I want a badge on my profile that when I am a top poster, so people know I am a top poster.
Jobs Story: When I am one of the top posters for a topic I want it to show on my profile so that people know that I am an expert in a subject.
User Story: As a developer, I want to see the number of posts in a topic for another user, so I can see where their experience lies.
Jobs Story: When I visit someones profile page I want to see how many posts that they have in each topic so that I have an understanding of where they have the most knowledge
User Story: As a developer that has used the application multiple times, I should get an alert to contribute
Jobs Story: When I have used the application multiple times I get nudged to contribute so that I am encouraged to contribute.
There is a very slight but meaningful difference between the two. By removing “As a __ ” from the user story, we remove any sort of biases that the team might have for that persona. Personas create assumptions about the users that might not be validated.
In my experience, user stories have a tendency to be easily manipulated to proposing a solution rather than explaining an expected outcome for that particular user. In particular, I’ve found people leave off the “so that __” in a user story with the feeling that it is optional. This leaves off the benefit that the user would get from adding new functionality.
In a jobs story we replace “As a __ ” with “When __ ”. This gives the team more context for the user’s situation and allows us to share his or her viewpoint. Next, the “I want to __” is transformed into situational motivation in the job story, as opposed to a prescriptive solution for a persona in the user story.
Because the differences in wording are negligible, it was an easy transition to shift from writing user stories to jobs stories. During this process, I noticed that the entire team had more empathy for the user. By placing the user’s situation upfront, our team had a better understanding how it felt to be in the user’s shoes, as opposed to thinking about a particular persona. This allowed for more discussion of the expected outcome and how to best go about achieving said outcome for the user.
When we first started using jobs stories, I was a skeptical that a small change in language would make such a difference in the way we build applications. Jobs stories have far surpassed my expectations and will be the way I write feature stories for all project moving forward.
Big thanks to Alan Klement, whose articles on Medium and Intercom helped educate and lead to the change.
