Jobs to be done

Background

I first heard about Jobs to be done as an alternative to user stories as a method of defining deliverables at Defuse 2015 conference. Emma Meehan presented how the team at intercom use Jobs to be done to make better design decisions.

Intercom are probably one of the most high profile advocates of this method with their own ebook available on this topic but it was a method they learnt from the Rewired group (http://www.therewiredgroup.com/ )

One of the fellow architects of JTBD, Clay Christensen has said,

“In hindsight the job to be done is usually as obvious as the air we breathe. Once they are known, what to improve (and not to improve) is just as obvious.”

The biggest distinguishing factor here is that approach to describing a tool, service or method as a “job”. I won’t even attempt to explain what Job stories are or how effective they are. I have already mentioned some key names and influencers in this area who have kindly documented and shared their experiences. In this blog post I hope to summarise how I plan to use Job stories in my major project.

Key Takeaways

After spending some time reading the Intercom eBook and watching a video by Sian Townsend entitle, “Jobs to be Done: from Doubter to Believer by Sian Townsend at Front 2016 in Salt Lake City, Utah” available here.

There are a couple of key takeaways I have picked up. In summary these would be;

Takeaway 1 – The Job to be done timeline

As mentioned above the fundamentals of Job stories is understanding the concept that people hire your product or service to get a job done.

Once your mind switches to this method of thinking and you begin to really look at how people currently get jobs done you are already opening up to this new method of thinking.

How do I apply this to my project? If for instance I hypothesise that people will book a hair appointment with a messenger app as they find it more convenient, more appropriate and a better solution I have to ask more than why? If the persons goal is to “get a new hair style” then the jobs to achieve this starts much earlier than just booking the appointment. I have to breakdown all the jobs along the journey. As a researcher and designer you can get to understand this full journey through the JBTD interview. When you document and understand this it is referred to as the Timeline.

1-5tBFYTOOBCrczOj7J4B-5Q

More on this can be read here.

When I define the high level job I am hoping to tackle I aim to complete a series of JBTD interviews to understand the full timeline.

Takeaway 2 – The Job Story

Job Stories are one element of the Jobs to be Done framework. The belief here is that user stories are not effective or realistic ways to define features.

Alan Klements medium post sums up the issue with user stories in this nice graphic:

“the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality.”

Basically there is no room to ask why? The job story is all about context and causality. When you structure the job story as ,

“When …, I want to…, So I can…”

It puts the focus on the motivations of the user and drives the reaction or change of consequence in using the job. One of the biggest changes here is that there is no persona or user attributes mentioned. This is another big feature of Jobs to be done and Paul Adams has written extensively on why personas no longer work.

How we accidentally invented Job Stories

In my major project I hope to push my design solutions forward by focusing on the motivations, causalities and anxieties. If I do reach a point of looking at features of the product I hope to be able to use job stories to describe each feature.

Takeaway 3 – Observation

There is a nice “6 step guide” to determining a Job story and can be used to help you think innovatively in your area. These are as follows;

1. Start with a high level job
2. identify a smaller job
3. Observe how people solve the problem currently
4. Interview
5. Come up with a Job Story, or Job Stories, that investigate the causality, anxieties, and motivations of what they do now.
6. Create a solution

One of the key steps here I believe as a designer lies in the observation stage. How do people currently get the job done? What are the substitutes or in other words your competition? What I like about the thinking here is that your job could be replaced with something that you traditionally wouldn’t even consider in the same area, never mind even user story.

There is a case study referenced over and over again around JBTD and it involves a milkshake. It explains how they discovered for a popular fast food company that people at 8am in the morning were using milkshakes as a job to fill hunger on their commute. Now this may seem surprising and i’ll leave all the magic and intrigue when you read the case study yourself. What I found interesting here is the realisation that they were now competing with other alternatives (sometimes healthy) like a banana, coffee, donuts, breakfast cereals, etc etc. It was winning because it had ease of convenience of storage in a cup holder, a straw for non messy consumption and it was very filling.

Only through observation was such a result discovered. I will be taking this onboard as I move forward with my major project. I have always valued good solid user research and I am eager to focus this research around a particular use case or job!

As I mentioned in the opening of this blog post, this is by no means a full understanding of JBTD. I would encourage you all to read and consume all of the links and articles mentioned here. To get started you should visit the main site https://jtbd.info/ for more resources, case studies and experiences shared.

Experience Prototype – Version 0.2

I quickly moved on from the first prototype to start thinking about what would be valuable to test in the second iteration of the prototype. Using the creative thinking design method cards I pulled together the following assumptions to test.

  1. How successful are the structured responses which Facebook messenger can offer?
  2. What do users think of interacting with a business in this manner?

Dreaming up a business

Joe's Wing Palace

To test these assumptions I had to think of a business which could be used for this experiment. With my fondness for chicken wings I quickly created a new Facebook page for ‘Joe’s Wing Palace’ – a restaurant that solely focused on delivering the best chicken wings in Dublin 🙂

I found a really great service called ChatFuel that allows you to build up Facebook messenger chat flows. The really great thing about this service is to ability to integrate much richer media like images, links, maps, etc. So the whole conversation is that bit richer for the user.

Let’s make a reservation and learn…

I setup a test for my user group to find Joe’s Wing Palace in Facebook messenger and to make a reservation. I was keen to see how they interacted with the UI, how they found the experience of interacting with a business and what opportunities or challenges did they see.

The tests were carried out over a few days and I picked up the following big insights.

Structured responses failed

This was the most surprising insight of all the testing. Thinking back on it I don’t know if it was because of the previous test I carried out or if it was people’s natural instinct to just chat to the bot. The majority of users (at least 75%) initially responded to the first interaction by not using the button UI. Luckily the system was setup to capture this and the user did not know any difference to complete the reservation.

Paper Trail

When I spoke to Michael Owen Liston he had mentioned a really key insight he picked up in his project. That for businesses there is an ‘explicit paper trail of intention’. Which for me was most obvious in this task. Through Facebook messenger I could see each and every conversation in real time of when a user was speaking to the bot. You could see what interactions they took, what questions they asked and how they went reached their goal (or not in some cases). There is a huge opportunity here for businesses to work closer with their customers.

Users wanted more

The majority of the users I tested with got very excited with the potential of this UI. In the post experiment interviews they were keen to share what else they would like to see,

This is Awesome. It would be great if you could share the conversation with someone else. I would like to setup an event for the booking and message it to my friends

You can see the test version of this app here:

 

Prototyping Conversational UI – v 0.1

I have committed to build up a range of experience prototypes throughout my major project and this week I began the first of these prototypes. After a great interview with Michael Owen Liston he spoke about how he used TextIt for his major project with refugees in Denmark. I won’t do his project any justice in this quick blog post so I would encourage you to read more about it here

Eating the Elephant

I hate business clichés as much as the next person but I learnt a valuable lesson this week. I knew what I wanted to test with this first prototype – The assumption that people instinctively know how to chat with a bot and also know what a bot is.

However I got carried away and tried to design the context in which this would make sense. Would I be a business? Would I be an AI assistant? Would I be a service? Would I work in a group chat? Would it be one to one interaction? I got bogged down in the details and technical challenge each of these questions brought about and lost a couple of days trying to answer these. Number one issue here being my assumption that I could pick up a new tool like TextIt and just get working with it. I was at this point beginning to lose time and focus on my initial question.

Learning Curve

Another lesson learnt is to not under estimate the time required to pick up a new tool like Textit and start working with it quickly. I will say that the service is easy to use, straightforward to get a test up and running and has an immediate impact on seeing it’s application. Where it gets tricky is twofold – One to figure out the integration with Facebook Messenger and second is to design a scenario that makes sense to the user.

I won’t bore you with the details of how to integrate it successfully with Facebook messenger. More so as there is a pretty decent post here about to do it. The one section it took me time to figure out was that for each user you wish to test with you need to set them up as a ‘Tester’ in your Facebook developer portal. This is assuming you have not had the app published for public consumption by Facebook. This requires submission for approval by Facebook and in the context of my fake business it didn’t make sense to do.

Questions to answer

Textit is a service to allow you to build complex flow’s which a user can respond to through multiple channels – SMS, FB, Telegram etc

In order to start answering my initial assumptions I designed a flow which would question a user on their previous knowledge or experience with chat bots. The flow is built up in a series of questions that the user answers with ‘YES’, ‘NO’ or free text responses.

Release the bots!

I sent out the this initial prototype to 10 users for testing. The feedback and engagement was overwhelmingly positive. With only one failed test (the user was unable to access the bot due to geo-location reasons) I had some very quick and early insights.

In answering the question – How would you feel about interacting with a chat bot, I had several responses along these lines:

“I would rather talk to a human. I feel like they could answer my question better…”

There was a clear hesitation about the quality of response one would get with talking to a bot.

However many users were equally impressed with the convenience, speed and supposed accuracy of the chat bot.

In the post experiment interviews conducted I was able to gather some really valuable insights. People were about to imagine the context in which this UI would be successful;

Speed of access to a response is the biggest advantage. Most phone calls for example you have to listen, press this, that and the other key, wait 10 mins to be connected to someone etc. I find that really hard with (a) how busy I am and (b) kids killing each other in the background. With a text type service I can deal with it whilst I’m doing another task and it doesn’t matter where I am. If it’s a really noisy place I don’t have to worry about back ground noise interrupting the call and if it’s a really quiet place (cinema) then I don’t have to worry about me being quiet.

You can view the prototype below

Talking to industry – Emmet Connolly

My secondary research to date has been very focused on reading blog posts, medium articles and twitter comments around conversational commerce. So it was with some excitement that I was able to line up an interview with one of those that i’d been following for some time.

I had an opportunity to speak to the super smart and extremely generous Emmet Connolly head of digital product design at intercom. I was really interested in his view as he has spoken on numerous occasions about the power of conversational UI in this landscape. His blog post on Principles of Bot design  is also hugely informed think piece. Here are a few of the areas covered in our chat.

Micro Interactions

We started by discussing and reviewing the landscape of apps in this space – quartz news app, peach app, WeChat and Facebook messenger to name just a few. It was here we the conversation moved on to how different each of these apps have approached this same UI pattern.

The micro interactions were really the defining difference – Peach has it’s magic words, Quartz uses structured responses with emoji’s and WeChat has developed a whole new UI pattern with dropdown menu’s present onscreen. It’s not clear what is more successful but Emmet is sure that some form of structured response is definitely required. The affordances it offers the user are more successful in a better user experience.

Appropriateness

We also discussed the appropriateness of conversational UI. As a business you need to think about where and when to use this form of interaction design. For instance Emmet questioned the use of conversational UI when a user would traditionally be browsing shelves of a store – let’s take fashion for instance. In this case the more appropriate mode of interaction is a mobile website where the user has time to click around, compare and come to a conclusion through their own decision making methods.

A hugely fruitful conversation with Emmet and much more insights gained than can be shared here in this short post.

User Centred Design Canvas & Major Project Idea Iteration 0.1

Scrolling through my twitter feed recently I stumbled upon a new tool for user experience designers called the “User Centred Design Canvas”. Had it been another time I may have swiped on by but after our recent module on Social Entrepreneurship at the Smurfit Business School something piqued my interest. I am also at a point where I felt I needed to start defining my project idea. I was on the search for some tool to help me get their. To some respect it did and let me explain how.

During our Entrepreneurship module we had the opportunity to put a business idea through the Lean Business Canvas which is an adaptation of the Business Model canvas. This tool or methodology is favoured by startups who wish to start defining business goals quickly and action them. These are all extensions of the original ‘Business Plans’ but are much quicker and dirtier to get you moving. I really liked it and pushed our team to put our Environmental project through some tough questions we hadn’t considered previously.

UCDC Canvas

So back to today and the User Centred Design Canvas. This is a natural extension of the Lean Canvas created by designers Alina Prelicz and Lezek Zawadski. From their site they describe the canvas as;

USER CENTERED DESIGN CANVAS was created out of need for an easy and effective tool facilitating user experience design process. Heavily based on user-centered approach and inspired by other great tools such as Business Model Canvas or Lean Canvas, the tool enables a comprehensive analysis of users’ and business’ main goals.

As I mentioned I was struggling to define my project. I knew my general focus was going to be around chatbots and/or conversational commerce. I wanted to see if I could put this loose concept through this model and see what would come out.

Although I know the method should be reserved for when you have completed user research or have a business/product idea. I thought it would be a useful exercise to see what I could tease out of my idea at this stage.

The principal is straight forward and I won’t go in to much detail here as it can be read in much more detail on their site or look at this use case here on UX Mag.

To summarise though – you start with your product/idea and you bring it through a set of questions to see if you have considered various elements to your product, with the ultimate hope that you can frame a unique value proposition.

The key takeaways for my project idea are:

  • The idea needs to be focused around an existing platform like Facebook Messenger, WhatsApp or Slack
  • The idea will consider the motivations of the user – are they using this potential service just because it is new?
  • The idea cannot be complicated or make the task harder in any way
  • Potential solutions and design considerations would be to look at Google Cards, Card carousels and WeChat implementations
  • The service must meet the users where they are at now

These all may be fairly obvious but it has helped me frame my project idea to it’s first iteration. It goes;

This is an opportunity to design a solution that can bring existing services or businesses to where their customers are now – social messaging apps.

As I said – This is version 0.1 but we got to start somewhere… right?