A famous economist once said about consumers, “People don’t want a ¼ inch drill. They want a ¼ inch hole.” While not formally a designer, Theodore Levitt understood the difference between identifying the problem and coming up with the right solution for a customer.

Most people accept without question the tools or solutions that are designed for them, until that solution becomes more of a pain or detriment than it’s worth. Your customers always want to get their outcome as quickly and painlessly as possible. Occasionally, they want to arrive at their outcome with a smile on their face, but it’s mostly about getting the job done. As such, it is critical to understand the user’s actual problem, and job stories are an effective way of uncovering the problem and designing for it.

Traditional User Stories

Here’s the problem: traditional user stories fall short as a tool to aid designers in arriving at the best solution for the user, given all of the existing constraints. Why? Traditional user stories, as they are written, presuppose or imply a solution without question. Assumptions are embedded in many user stories and the team blindly follows them or inserts their own meaning, often without there being a full discussion about these assumptions and presuppositions.

In the case of the drill example above, a typical user story might read:

As John the handyman, I should be able to drill a 1/4 inch hole into the wall.

Firstly, the most descriptive users stories start with a persona; however, in practice, most people just revert to writing “As a user…”, which is even less helpful. Including “As a user…” to every user story doesn’t provide much actual value to solving the user’s problem.

After framing the persona, a typical user story will then suggest a solution. “I should be able to drill…” “I should see a notification…” “I should be able to view a list of…” “I should be able to confirm…” Like I mentioned, this is one of the big problems with the typical user story: the solution is assumed and implied. For the designer, we should never start here. The solution is arrived at through open-ended questions and understandings of the user’s needs, their motivations, and their intended outcome.

Traditionally, user stories lack a lot of information about the user’s actual problem. Because of this, it becomes too easy to imply a default solution which may not actually be the right one. This is where the JOB STORY comes in.

Job Stories

The job story began with the work of Harvard business school professor, Clayton Christensen. To better understand how to improve and market products (even milkshakes), his team began asking “What job do people hire this product to do?”. In order to really understand the consumer (the user) better, the team wanted to deeply understand what motivated the consumer to buy a product. By understanding the consumer’s motivations and their context, the team was able to optimize the product in the best possible way.

The job story is about context, motivation and causality – can we design a solution that works for the situation and causes the expected outcome that the user needs and expects?

The format of a job story is critical, but it’s a pretty simple format to follow:

When ____[SITUATION]____,

I want to ____[MOTIVATION]____

So I can ____[EXPECTED OUTCOME]____.

In the above example, the job story might go something like this:

When I’m ready to hang a shelf, I want the shelf to be secured into the stud, so that my shelf can hold many things of varying weight without falling off the wall.

There is a pretty established set of solutions for this everyday example, so much so that it is difficult to avoid vocabulary like “screw”, “drill”, and so forth. If we’re trying to innovate and disrupt the drill and shelf industry, then we need to eschew many of the usual industry assumptions and solutions.

The above example is about a physical product, but the need for authentic innovation is especially critical in digital products. The established solutions to things like profile views, settings, notifications, search, composing content, etc. could stand for original thought. Of course, we want our users to recognize familiar UI patterns, but by using job stories we can challenge certain assumptions. For example, does your app even need a profile view? Many social media apps rightfully have a profile view that caters to the user’s needs; however, these profile views have begun cropping up in payment apps, weather apps, and just about anywhere else you could imagine it being useless. By posing the problem instead of the previously designed, junk-drawer solution, you can challenge this status quo with a solution that targets your user’s specific problem.

In the context of a digital product, a job story might state:

“When my credit card expires, I want to be able to change my credit card so that I can continue purchasing without any problems.”

This job story helps us plan for the user-initiated credit card expiration. It also doesn’t assume that the credit card information MUST be part of a profile view. It allows the designer to try many options for where and how the user accesses their credit card data. Additionally, this job story could spark in us the idea that maybe the user should be notified, as in:

“When my credit card expires, I want to be notified so that I can update my information without any disruptions to my service.”

In order to think through the context and situation, think about the user’s motivation. This will help create the best solution for the user, and also helps to identify gaps in the design that need to be addressed either now or in the future.

Design for the Problem Instead of a Solution

Agile software development advocates for writing good user stories, but in my experience, many user stories are hastily written and imply a solution without the problem being fully understood yet. To designers, job stories are the most effective tool to understanding the user and the problem that they need solved. We should never think that the app we are designing is, in and of itself, the thing that the user wants or needs. What we can only hope to do is to provide them with a tool that is the best, given all of the constraints, at delivering the outcome the user desires. At the end of the day, a person hanging a shelf wants a ¼” hole in the wall, not a ¼” drill.