How to apply the Jobs-to-be-done methodology to web design

How to apply the jobs-to-be-done methodology in web design

An common methodology in user-centered web design is the a combination of Personas and user stories. A Persona is basically a fictional user archetype. A model that is created from data. Data that should have been gathered by talking to real people.

A Persona typically tries to represent the characteristics you need to know about the “typical” user of a web design. All in order for you to make real and informed design decisions.

Personas works well in a situation where the user-base can easily be segmented into different types of users with different needs. The problem is, that is seldom the case.

Knowing the exact details about a user is somewhat useless if you don’t know what they actually want to do. With web design becoming more about designing product features and less about designing interactive brochures. Basing UX design on personas and user stories is a troublesome premise.

Many web design solutions are better defined by the job they do rather than the customers they serve. This is called the jobs-to-be-done methodology.

In this article we will show an alternative to Personas and user stories. At the same time we’ll investigate how you can use the jobs-to-be-done methodology in your web projects.

The Jobs-to-be-done methodology helps you focus on the job that the user wants done rather than who and how.

Many customers of web-based products have different nationalities, different educational backgrounds, different salaries, different interests etc. The one thing customers always have in common is the job they need done.

Instead of understanding who your users are and what car they drive you would probably do a lot better in getting a deeper understanding of the job they want to get done.

Find out why the job is needed in the first place. Then find out what solutions they “hire” today in order to get the job done.

In order to understand the job our users want done, we don’t need to have any deep understanding of the the different attributes of our users. Personas and user stories doesn’t really help us out much.

How personas & user stories differs from the jobs-to-be-done framework

If your agency typically works with Personas and user stories you’re probably used to this format:

user-story-og

The problem with Personas and user stories is that they’re out-of-context. They never ask why something should be/happen.

Let’s analyse this format a bit more;

Jobs-to-be-done in web design

The problem is that we’re starting with a Persona. After it, we attach an action that we think is logical in order to achieve an expected outcome. This is completely lacking in context. There’s an obvious disconnect between the Persona and the action.

Let’s review some examples of user stories (in this example a multi-user blog):

Jobs-to-be-done in web design

When you read contributor, editor or subscriber, do you feel that that’s adding anything to the context? What is a contributor? What is an editor? We will make our own interpretations of these roles. Not mentioning their attributes which we might have written down in pain-staking details when we defined our Personas. (You know, “Hipster with goatee, studying in cafes, uses skateboard and lives with his mom”…)

The jobs-to-be-done methodology takes a different approach. Using the “jobs framework” you define each new design problem as a Job. In this Job you focus on what caused the event or the situation, the motivation and goal and finally the intended outcome:

Jobs-to-be-done in web design

This format is from the stellar team at Intercom.

 

Can you see what we’re doing here? First, we take the Persona out of the picture and instead add context. Then we focus on the motivation (i.e, answering the why).

It gives us clarity to the whole situation and helps us be more creative in designing a solution.

Okay, let’s dig deeper and rewrite a couple of examples from the user story table listed above . This time removing the Persona and adding context and motivation to each one.

User Story/Persona:
As a contributor I want to be able to write an article and publish it on Blog X so that others can read my article.

Jobs-to-be-done story:
When I have an idea ready for a blog post, I want to be able to publish it on Blog X so I can establish myself as a thought-leader in my field.

User Story/Persona:
As an editor I want to be able to view a list of all blog posts that are queued for publication so that I can control what content is being published on Blog X

Jobs-to-be-done story:
When I want to publish new articles on Blog X, I want to be able to view list of queued articles ordered by topic, so I can publish the one that’s most relevant right now.

As you can see, we really don’t really need the Personas at all. Nothing happened when we cut it out.

Don’t ask for whom and how. Just ask why.

The argument I want to put forward is that Personas and user stories completely misses out on why something should be done. It’s problematic because it focuses too much on how something should be solved and for whom. It reads more as a story about how something should be implemented.

It’s better to shift focus from the who and how towards understanding the context and the motivation. That way you are much better positioned to be able to answer the why. More importantly, it opens up for more creative ways of solving design problems. It’s especially effective for feature design.

For more info on the jobs-to-be-done framework check out these great resources:

 

https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27
http://hbswk.hbs.edu/item/6496.html
http://blog.intercom.io/the-dribbblisation-of-design/

 

Annotate webprojects