Job Stories for Interface Design

Original author: Alan Klement
  • Transfer


Modeling the target audience (characters) and writing “user stories” (user stories) were effective when customers and product developers were far apart. Now everything is different. This post talks about how one development team applied the Job Stories method to create a user profile page.

Traditionally, obtaining information about who the site users are and what their preferences are, refers to the tasks of the marketing, business development, or sales departments. After this information is received, it is compiled and transmitted to the development team that is involved in the creation of the product.

The disadvantages of such a cascading model are related to the nuances that must be understood in order to create a quality product: these are the reasons for user behavior, what excites them and what motivates them. The second step, after the development team realizes the need to “get closer” to users, is to find the best ways to evaluate the user attitude to the product.

A similar approach, fixed on the causes of behavior, user problems and their motivation, is the essence of the method called Jobs To Be Done (the concept of the “work” that the product “performs”), and one of the effective ways to apply it is to use the Job Stories method when site development, user interface and interaction experience.

Character modeling problem


The most basic and most common problem that arises when using the character modeling method is this: the characters are fictional and include characteristics that do not take into account the real causes of user behavior. These characteristics, which are mainly demographic data, do not bring developers closer to understanding customer preferences regarding their product.

Characteristics of the characters (age, gender, race, or way of spending the weekend) do not explain why the client, for example, ate the Snickers bar. But the fact that it took him 30 seconds to buy, and having eaten the bar, he managed to drown out the hunger for 30 minutes, on the contrary, gives an explanation.



Title: “Why did Peter buy Snickers?”

left column: “To satisfy hunger”;

right column: “He is 35 years old, he has a marketing diploma, he loves peanuts, chocolate, nougat and caramel, he loves Snickers bars and eats one each day. He leads an active lifestyle, he has 2 dogs. He rests at Jack in the box, but buys food at Taco Bell. He dislocated his toe. ”


User stories method issue


As a user, I can partition folders so that my backup drive is not filled with files that I do not need to store. User stories, as in the above example, have three big problems:

  1. They are based on characters.
  2. They do not take into account the difference between the execution of an action, motivation and the results of actions.
  3. They do not take into account the context of the situation, circumstances and problems of users.

Often, some functionality or interface element is ineffective. If they were developed using the User Story method, then it will be difficult to find out the reason, since the implementation process, user motivation and the results of the action were “piled in one heap”. How in this situation to understand what was done wrong? Was there a mistake in accounting for the implementation, or were the assumptions about motivation incorrect? Learn more about the complexities of using the User Story method.



What is Job Story?




This term was first mentioned by Paul Adams and is described in more detail here . The Job Stories method is a different way of working with product functionality, user interface, and interaction experience. But how can the development team apply it in their work?

Here is one approach:

  1. Start by completing the most important task.
  2. Identify secondary tasks, or tasks that will help you accomplish the more important.
  3. Analyze how users are currently solving their problem (what work they are doing at the moment)
  4. Create one or more Job Stories that identify objective causes of behavior, motivation for user actions and the difficulties that accompany them.
  5. Develop a solution (usually a change in functionality or user interface) based on the resulting “history”.

To demonstrate how this can work, let’s look at how one development team prepared UX and UI user profile pages in an application that helps people who sell cars give loans to customers who want to buy a car.

Profile Page Development




Pyramid from left to top: “customer profile, motivation, anxiety, circumstances”; text of the small bracket on the right: “experience of interaction”; the text of the big bracket on the right: “a task defined by context and circumstances”.

That is what the project was at an early stage. The developers discussed what the toolbar and start page would look like, and what elements they would contain. At some point, Joe, one of the developers, got up and drew the simplest diagram on the board. He pointed to one of the blocks and said:

This is a profile of a car seller.

The team listened to his arguments regarding the appearance of the profile page, but he could not immediately convince them. They asked him a series of questions regarding each element of the diagram and the appearance of the profile page. But even after all the questions asked, the team could not decide whether they support Joe’s idea. And then the following question was raised:

Why should our application have a profile page? Why should she be in this place or somewhere else? What information should it show? What circumstances does it take into account and what task does it perform?

To solve these issues, the functionality was adjusted using the Job Stories method.

Note: For brevity, this article will mainly deal with only one “story” for the profile page. In fact, several Job Stories were prepared.

1. Start with a task of a higher level.

The task of the highest level for the product in question is to help the car seller in securing a loan that his customers use to buy a car. Traditionally, the buyer as well as the seller needs to fill out a lot of serious documents.

2. Define minor tasks

In order for the loan document to be filled out correctly, the seller and the buyer need to enter a large amount of information regarding the car and the conditions for issuing a loan, as well as the confidential financial data of the buyer. Since this information is confidential, the buyer needs to know that when working with a particular seller, his personal data is kept safe.

3. Analyze the process

(how users solve the problem at the moment - what work they are doing now)

Typically, when entering this type of data, the buyer analyzes (most often visually) who the seller is and what the dealer agency is, and then makes a conclusion about their competence and whether they can be trusted. Also, usually, when specifying confidential information, the buyer fills in paper documents in private with the seller and does not trust the document to unauthorized persons.

This allows him to feel confident that the data is filled in correctly and that people who should not see it will not receive it.

4. Formulate one or more “stories”

(which reveal objective reasons, motivation for user actions and the difficulties that accompany them)

When the seller and his client interact with each other through this application ...

  1. ... customers need to feel that they can trust the organization, the buying process, and the seller.
  2. The seller needs to be sure that the process of selling a car is comfortable for buyers ...
  3. ... so that customers feel that they can safely transfer their financial data during the purchase process.

The foregoing forms a “history" in the context of a specific situation. It can be detailed by adding more information about the circumstances of the purchase, for example, about where and when documents will be filled out (at home or at a dealership) - and the difficulties that both parties will experience when creating and viewing a profile.

5. Develop a solution

(usually it’s some change in functionality or interface that takes into account the problems reflected in the “history”)

In order to complete the above tasks, the team decides what functions the profile page should have and how it should look . Lack of information on the page will not allow you to complete the specified task, but its excess can have negative effects. Here is what we finally decided:

  1. In the process of using the product, the seller’s profile should be constantly available (in order to reduce the customer’s anxiety that he is not near the seller).
  2. Such a profile will have to contain a photo of the seller, position, number of cars sold and the term of work in the company (in order to reduce the customer’s anxiety about whether the seller is competent and whether to trust him).
  3. This profile should allow easy contact with the seller. For example, it may contain a phone number, email address and a button that says “Ask a question [Seller’s name]” (this reduces the customer’s anxiety that he can fill out the form incorrectly without assistance).

Here is an example of a solution:



Here is a parsing of the user interface, the tasks that each element of the interface performs, and the problems that it solves.



Figure:

Photo caption (“Your Sales Manager”), profile photo and seller’s name: all this reminds the customer who Joey (Filgood) is and reduces anxiety that he is not next to the seller.

Position of the seller: chief sales manager, number of cars sold (500) and commentary (“8 years at Great Sales”). This confirms that Joey is competent and that other people trust him.

The phone number, mailing address and the “Ask a Question” button are easy to contact Joey, and this reduces the client’s anxiety that he will not be able to fill out the form on his own.


In the course of designing user interaction, all elements should serve the fulfillment of one task: ensuring that the client feels safe when transmitting personal information.

Designing applications taking into account the real conditions of their use


Creating successful products involves analyzing how real people solve their problems at present, studying the circumstances of the situation in which they are, and understanding the objective reasons for their behavior, doubts and motivation.

Abstract user characteristics and a mixture of concepts of implementation, motivation and the result of an action - all this distracts the development team from the essence of the work. If the team goes further and explores “Tasks for which the user“ hires ”the product,” she gets the opportunity to make better decisions.

Using Job Stories to create features, user interfaces, and experience is one way to achieve this. About other decisions in this area and not only - inour translation of the book of the MailChimp UX team .

Also popular now: