Designing Features Using Job Stories

How one team used Job Stories to design a Profile

Product Design’s Waterfall

This article first appeared on insideintercom.io — where the intercom team writes about design, customer experience, start-ups, and the business of software.

Personas and User Stories made sense when customers and product teams were far from each other. Traditionally, who the customer was and what they needed feel within the responsibility of marketing, business development or even sales. After this information was gathered it would be synthesized into a portable format and then pitched over the fence to a product development team, who was then responsible for building the product.

The casualties of this waterfall process are the subtleties which are necessary to understand when creating great products: causality, anxieties and motivations. As development teams recognize that they need to be close to customers, it’s also appropriate to consider better ways of leveraging customer empathy to create products.

This philosophy of focusing on causality, anxieties and motivations is called Jobs To Be Done and a granular way to bring this concept into a product is to use Job Stories to design features, UI & UX.

Want more? Download a free PDF book about JTBD or buy it in paperback & kindle

How, exactly, Personas fail

The biggest, and this article’s most pertinent, problem with Personas is this:

Personas are imaginary customers defined by attributes that don’t acknowledge causality.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race and weekend habits) does not explain why they ate that Snickers bar: having 30 seconds to buy and eat something which will stave off hunger for 30 minutes, does explain why.

Snickers promotes a job to be done.

How, exactly, User Stories fail

“As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.”

User Stories, such as the one above, have three big problems:

1. They use Personas.
2. They couple implementation with motivations and outcomes.
3. They ignore context, situations and anxieties.

Often, a feature or UX will fail. If it was defined by a User Story, then discovering why it failed will be difficult. Discovering why it failed will be difficult because implementation was coupled with motivations and outcomes. Because of the coupling, how can anyone know what was wrong? Was the implementation wrong or were the assumptions about motivations wrong?

Learn more about the challenges of User Stories here.

Enter the Job Story

The job story

First mentioned on insideintercom.io and developed here, Job Stories are a different way of thinking about defining features, UI and UX; however, how does a team implement them into their workflow?

Here is one approach:

1. Start with the high level job.
2. Identify a smaller job(s) which helps resolve the higher level job.
3. Observe how people solve the problem now (which job do they currently use).
4. Come up with a Job Story (stories) that investigates the causality, anxieties and motivations of what they do now.
5. Create a solution (usually in the form of a feature or UI change) which resolves that Job Story.

To demonstrate how this can work, consider how a team crafted a Profile View’s UX and UI for a product that helps car sales people get loans for people wanting to buy a car…

Designing A Profile View

It was early in the design process. The team was discussing what the Dashboard / Home View would look like and what features should exist there.

At some point Joe, a team member, stands up and draws a simple wireframe on the whiteboard. He pointed to a box and said:

This is the sales person’s profile.

The team listens to his rational for the profile view but are not immediately convinced. They asks a series of “why’s” for each particular part and circumstance for the profile view. Even after all these questions, the team wasn’t coalescing for or against the idea.

At this point the question was asked:

Why should the product have a profile view? Why should it be in one place or another? What information should it display? What situations is it resolving?…What job is this profile view doing?

To resolve this, the feature was reframed in a process with Job Stories.

For brevity, this article will focus on just one job story for the Profile View. In reality there were several job stories related to the Profile View; however, including those would also make this article about 5x longer.

1. Start with the high level job.

The high level job for this product is to help a car sales person secure a car loan when someone buys a car from them. Currently, the buyer has to fill out a lot of difficult paperwork along with the car sales person.

2. Identify a smaller job(s) which helps resolve the higher level job.

In order to get the loan application filled out correctly, the sales person and buyer need to enter a lot of information about the car, terms of loan as well as the buyer’s (sensitive) financial information. Because the information is sensitive, the buyer needs to feel she can trust that her personal information is safe with the car sales person.

3. Observe how people solve the problem now (which job do they use).

Currently, when filling out this type of information, the buyer analyzes (usually visually) the sales person and car dealership and deduces if they are reputable and can can be trusted. They also generally fill in their sensitive information in close physical proximity, on a piece of paper, with the sales person. This helps them feel confident that the information is filled out correctly and won’t get passed around to people who shouldn’t be looking at it.

4. Come up with a Job Story (stories) that investigates the causality, anxieties and motivations of what they do now.

1. When car sales people and their customers interact with each other via the product…
2. Customers are going to want to feel like they can trust the organization, process and the sales person…
3. Sales people are going to want to be confident that their process makes their customers feel comfortable…
4. So that clients will feel safe entering their financial information into a process.

The above frames the situation into a Job Story. It can be fleshed out more by providing more situational context such as where & when it’s being filled out (e.g. at home or at the dealership) and anxieties each party will have about having and viewing a profile. More tips on creating Job Stories are here.

5. Create a solution (usually in the form of a feature or UI) which resolves that Job Story.

To resolve the above job, the team then decided on what features the Profile View should have and how it should be presented. Too little information and the Profile View won’t solve the original job, too much information could have negative effects. So, we decided:

1. When the customer uses the product, the sales person’s profile view would always be visible. (Eases customer’s anxieties about not being physically with the sales person)
2. The profile would have a picture of the sales person, job title, cars sold and years at the company, (Eases customers’ anxieties about whether the sales person is reputable and can be trusted)
3. The profile view will enable easy ways for the customer to get in touch with the sales person. Examples are their phone number, email address and a button that says “Ask [sales person] a question”. (Eases customers’ anxieties about filling out the form themselves and getting something wrong)

Here is an example of a solution:

Here is a breakdown of the UI, the job each UI element is doing and what situation(s) it’s resolving.

With the UI complete, we now have a UX in which every element can be traced back to resolving a job: ensuring the customer feels safe when exposing personal information.

Design For Real People, Design For Causality

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in and then understanding causality, anxieties and motivations.

Abstracted attributes and coupling implementation with motivations & outcomes are distractions for a team. If the team digs deep and learns about a customer’s Job To Be Done, they can then more effectively craft solutions… and using Job Stories to design features, UI & UX is one way to do it.