When defining stories it’s important that we frame every design problem in a job, focused on the trigger event or situation, the motivation and goal, and the intended outcome:
When ______, I want to ______, so I can _____.
The Problem with User Stories
User stories make too many assumptions and doesn’t acknowledge causality. Often, the individual writing a user story will replace “user” with their own needs or motivations.
When a story is put in the format of a user story (As a [type of user], I want [some action], so that [outcome]) there’s no room to ask ‘why’ – you’re essentially locked into a particular sequence with no context.
|
Irrelevant |
How do we know this is the best action to take? | |
|---|---|---|
|
As a ________ |
I want to _________ |
So that ________ |
|
Persona |
Action |
Expected outcome |
|
Too many assumptions
|
|
|
The first problem is that we start with a Persona, which is a very bad idea, and then add in an action which we think should be taken in order to achieve the expected outcome. Doing this allows you and I to attach our own interpretation of what a persona is or why they are in a particular context. It also attempts to remove user testing and validation from the product development process, which ultimately can have negative consequences.
The Job Story: All About Context and Causality
Job stories describe the behavior and provides critical and very informative information which provides as much context as possible and focus on motivation… instead of just implementation.
The job story applies to everyone who is doing a similar action (so it’s not important to know the person doing this is _____).
When… I want to… So I can…
A situation arises Action or motivation Expected outcome
Job Story
The focus is on the problem space. Your customers’ situation, motivation, and their deserve to make progress. No mention of how. The focus is on Why, When, and What.
Examples
User Story:
As a trader, I want to search by order number so I don’t have to waste time locating barge by name or company.
Job Story:
When searching for a barge with the barge tracking card, I want to enter an order number so I quickly locate the barge to locate it and understand demurrage charges.
–
User Story:
As a Lead Trader, I want to set an alert, so that I’m notified when the price goes down to $15 a bussel.
Job Story:
When looking at the market, I want to set an alert on price, quality, and other factors, so I can be notified and make a trade that meets my needs.
As you can see in both cases the job story is more specific, provides greater detail and also are actions that a customer would be performing in the product.
What About Multiple Roles & Events?
Sometimes it’s helpful to include Roles, or Characters, as part of the When_ clause.
Products with Multiple Roles
Roles / Characters are most helpful when the product has multiple roles, e.g. an IT product (Admin, Manager, Contributor…) or in a marketplace product (Buyer, Seller). The reason is just to clarify who we’re talking about.
Example:
When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter but notification, so they can have enough time to evaluate and update their own bid.
Using Events Instead of Roles
Sometimes however, there might be a situation when an event effects al the roles or groups of roles: such as needing to get a password
reminder. In this case these’s no reason to have a specific role, rather, try to keep it event based and general by using terms like customer or someone (but not user):
Example:
When a customer is on their computer and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their computer, so they can continue to sign in and access their market information.
Why not user? User feels very lifeless and sterile, instead, customer reminds us that we have people who need to be served and respected.
Define Motivations, Don’t Define Implementation
Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.
