Use Cases, User Stories/Statements, and Jobs to Be Done
Making the case for the user, not the thing you are building.
I was recently asked in an interview what my past experience was with Jobs to Be Done. The interviewer asked the question in a way that made me feel like they were making the assumption that I a) knew what Jobs To Be Done was, and b) used the methodology at work. I proceeded to answer the question by expanding on my own process at work, and didn’t address the Jobs To Be Done question.
In retrospect, I should have made it clear at the beginning of my explanation that in the previous work I had done, I never used JTBD, although I am familiar with the general concept. I wrote Use Cases and User Stories, and used those to communicate with developers and the rest of the product team what to work on, and what to set as priorities. In theory, I know what the Jobs To Be Done framework is about, but haven’t tried to adopt it in my own workflow and didn’t really see any need to do so up until now.
One of my design students asked me this very question, “Doesn’t everyone just use Jobs To Be Done now? Why do we even need personas?” This was early on in our course, and I think that particular student has now come around to the benefits of creating personas, writing user stories, and has also investigated further the use of Jobs To Be Done in their practice. I hope that they have found a good way of working that suits their needs.
These two anecdotes just made me think about the pros and cons of these methods, and how and when to use them. Are they in direct conflict with each other? There seem to be some areas where they overlap. In this post, I will try and explain the differences between Use Cases, User Stories, and Jobs To Be Done, and hopefully at the end of this, we may have a better understanding of what each term represents, and what we might be comfortable adopting into our own workflows.
Full disclosure: I have never been part of an effective team that utilizes the Jobs To Be Done method, and although I am approaching this writing with an open mind, I would love to be enlightened on how JTBD can help design teams work better. Please leave comments or write me a message if you are using this method effectively at your place of work.
Use Cases
A Use Case is primarily a set of scenarios that are associated with each other by a common goal.
To describe what a use case is, we first need to understand what a scenario is. A scenario is a sequence of steps describing the interaction between a user and the system they are using. A typical scenario on an e-commerce site might be:
The user browses the catalog and adds desired items to the shopping cart. When the user wishes to pay, the user clicks on the shopping cart to review their items to be ordered, and proceeds to enter the shipping and credit card information. The system checks the authorization and confirms the sale immediately and with a follow-up email.
This is one path that the user might take in their purchase flow, however, any number of things can go wrong, or prevent the user from completing the flow, such as the credit card authorization failing, shipping address validation errors, and these are separate alternate scenarios.
A use case then is a set of these scenarios tied together by a common user goal. In systems engineering, a UML (Unified Modelling Language)diagram might illustrate the various roles and their interactions with a system at a high level.
Getting into more detail, one format a use case can be written is in the form of a sequential list, often numbered, that describes the steps the user will go through in order to achieve their goal. Use Cases can be quite granular in detail when compared with User Stories, and when brainstorming new features or future state ideas with existing users and other stakeholders, it would not be advisable to go to this level of detail. With an existing product or system, the frequent users of that product tend to focus only on what their current steps and processes are — this is more true for products that have been in existence for a longer period of time without drastic changes. If you are a designer/researcher on an existing product, it might be a good idea to write out several key Use Cases of current state for analysis, but be cognizant of the fact that these steps are dictated by the existing product design and limitations, and where a use case might be useful is in describing requirements for developers, when more solid understanding of a user-system interaction is in place and has been designed.
User Stories or “Statements”
I think that the word User Story is a misnomer. The word story implies that there is a plot, and there is a clear beginning, middle where something exciting happens, and an ending. This just sounds an awful lot like a User Journey, and I don’t want to mix those two together, and further confuse a non-design audience than they already are with the distinction between Use Cases and Stories. I want to do what little I can to change the term to User Statement, and propose that we use this term going forward. If you look at the structure of what a User Story is, in essence it is simply a statement. But the subsequent details the team adds around that statement to give it purpose and context is what really drives innovation, experience, and effective product design.
On its own, a User Story is fairly simple, and follows this structure:
As a __________ (role) I want to __________ (action) so that I can __________ (rationale).
Example:
As a Caseworker, I want to send a message to the Applicant so that I can notify them that their application has moved on to the next stage.
The benefit of this statement is that it helps to communicate to the project team and stakeholders what the user’s intentions are. That context is embedded in the statement itself, and as more User Stories are written in the same way, yes they might start sounding repetitive, but with every task or action you want to make the product perform, there is rationale from a user standpoint, and it is not lost in the shuffling process of prioritization.
If you, the designer or product manager, have a chance to engage with end users of your product, and they are part of a larger organization with different roles, it might be vitally important to have them write out several of these user statements based on tasks that they want to perform to conduct their work on a daily basis. If you are a service designer, the User Statements may extend beyond what these people use a product or system for, and can even be about their interactions with other employees, customers, ergonomics, etc. Whatever is important to them. Sometimes this activity may require multiple workshops to first get down all the wants that users have, and then to ask those same participants to share and prioritize their wish list in groups. Having several users in the same role give their own User Statements can shed light on some common patterns that emerge and also individual unique nuances in work habits and behaviours.
The job of the designer/researcher is to collect the User Statements gathered, organize them and map them to the stages in the User Journey or Service Blueprint, making it easy to reference both. Then communicate these stories with the rest of the team, the product manager and developers preferably, and collectively determine the priority of the User Statements, course of action on each, all the while documenting your decisions.
As the User Statements begin to have more detail added, they will inevitably have more technical notes, comments, revisions, and wireframes added. Or they may be deemed low priority, unneeded, or redundant and archived or discarded. Use a project management tool such as JIRA to track User Statements, assign priority, and manage their workflow.
Jobs to Be Done
Jobs to Be Done theory stems from discourse on consumer action. It describes how a consumer adopts an innovation. The consumer buys a product to complete a job that needs to be done. The process starts, runs, and ends. It hinges on the idea that “progress can only happen when we attach and integrate new ideas and new products into our lives.” — Alan Klement
The theory goes on to describe how a consumer wishes to change. It is about how a consumer wants to change an existing life situation into a desired one, but may have obstacles in the way preventing them from getting there. There appears to be two different interpretations of JTBD currently out there, and one is Jobs-As-Activities, and the other Jobs-As-Progress.
Here we can get mixed up in a heated debate about what JTBD really stands for, and whether or not the Jobs-As-Activities is Use Cases repackaged, and whether Job Stories are better than User Stories but I would rather not go there. Needless to say, users have tasks they are motivated to perform, and whether you are mining for the tasks they perform, wish to perform, or the motivations behind why they want to perform such tasks, you are still the design researcher trying to unearth what is in their mine (pronounced: mind).
A JTBD Job Story can take the following structure proposed by Alan Klement:
This way of phrasing the story gives more context to the overall situation the users might find themselves in, or the obstacles that need to be overcome.
Job actions can be mapped to goals and needs for desired outcomes similar to how User Statements can be mapped to a Journey Map.
Having learned more about JTBD and looking at the framework from the perspective that Alan Klement proposes in his writing, along with looking at several examples I found online, I can see how this perspective can be vital to the design process. Taking a consumer-centric viewpoint, looking at their goals and motivations to drive the product from a marketing perspective can create some very actionable items for the project team to work on. I like that the idea of “definition of done” is also more concrete within the JTBD framework. It is not only in the name, but the attributes of the framework speak to the emotional impact on the consumer/user and their desired results, making the design tasks quite measurable.
Whatever methodology you and your team adopt, these are essentially tools for helping designers and other team members break out of their own psychological biases when designing and building products or systems. I hope that this writing serves to clarify some of the terms presented above, and help you to investigate these methodologies on your own so you are well informed on how you might integrate them into your own practice.
