User Stories

User Stories are a way of defining the functional parameters of a product or service. They tell the story of how an end user expects to interact with a system and how they expect the system to respond.

There are two general formats for a User Story: Persona-Based and Jobs To Be Done (JBTD). Which format we use will depend on the specifics of a given project. In either format, a User Story describes what a user wants to be able to do and why.

A Persona-Based User Story focuses on a specific, prototypical end-user in a system that might need to accommodate several different user types. For example, a ride-sharing service has passenger users and driver users. In that type of system we might write the following user story:

As a Passenger, I want to be able to quickly select a pre-calculated tip percentage based on my fare so I don’t have to do math after my ride ends.

A JBTD formatted User Story is aimed at projects where we have not formulated as many assumptions about what motivates end users. In these cases, it can be easier to think more about what precipitates an action in the system. Therefore, a JTBD User Story might look more like this:

When I’m ready to purchase a membership plan, I want to see all of the pricing options, so that I can feel confident that I’m choosing the right one for me.

Despite their slight differences, both of these formats share some key attributes:

• They do not mention any sort of functional solution. Nothing about input fields, or buttons, or progress bars. The story just describes what the user wants to accomplish and why. The particulars of how will be left to the team to solve in the design.
• They are often grouped into larger themes called Epics. Epics are collections of User Stories that are grouped according to a common theme. An Account Creation & Sign In Epic might have a dozen or so User Stories describing all of the different tasks a user might want to accomplish.
  • Create an Account
  • Recover a forgotten password
  • Sign In
  • Etc.
• They will likely include a list of additional criteria that define in detail what success looks like. Take the following JTBD User Story:

When I make a purchase with a new form of payment, I want to be able to save it, so that I don’t have to enter it the next time I make a purchase.

We can add the following acceptance criteria that will further define this interaction within the context of an organization’s business rules.

• I can give the form of payment a nickname

• I can set the new form of payment as my default for future purchases

• I can save up to four forms of payment

We have not included any sort of User Story template in this toolkit. Most often, these stories will be captured inside of a project management platform like Basecamp, Jira, or Trello. These platforms make it possible to assign, track and link User Stories that are dependent on each other.