I’m currently in the process of creating a new product (mobile app) from scratch, and decided that being the product designer, this would be a good opportunity to trial out job stories. Here are my two cents on using them and incorporating them into the overall product development cycle.
If you’re not familiar with job stories, the following post from Intercom – designing features using job stories, is a good starting point to get the details down. The central conceit being that traditional personas pigeon-hole user types too much, and you end up designing system functions based around an archetype user. When in most instances the same function is utilised by many of your personas in various contexts.
For example, a traditional user story for a photo management app might might be – “As a professional photographer I want to be able to search through all my photos by date”. Designing this feature for a pro photographer isn’t particularly pertinent, even the amateur or casual photographer would use this feature. Designing a function for a persona doesn’t always mean you’ll build the most appropriate and best solution.
Before we start diving into carving up job stories, lets take a step back …
The Value Proposition Canvas
I decided to use the Value Proposition Canvas as my starting point. If you’ve not come across the VPC, it’s a simple and clear way to identify your target customers by their problems, expectations and desires alongside the intrinsic value your products/services generate for this customer segment. The following five minute video, explains it all very succinctly.
You can download a PDF of the Value Proposition Canvas from Strategyzer – the Value Proposition Canvas. I do recommend reading the Value Proposition Design book if you’d like to understand value proposition design further, it’s a worthy read for anyone in UX and product development.
I find the most effective way to build the canvas is to draw it on a whiteboard, and collaboratively use post-it notes to fill up each section. As you’ll see – the first step in creating the value proposition canvas is to identify customer jobs (these aren’t quite job stories, but you’re laying that foundation for them).
So once you’ve built out a value proposition canvas, you’ll have at the very least considered your key customer segment and the value your product creates for them. This is the first draft bigger picture view of your product’s value proposition, many product developers and UX teams overlook this crucial step.
The next step is to create job stories that drill that bit further that help identify the really essential features you need to build – this is particularly helpful in prioritising features for your initial MVP.
The Job Story
I’m not going to argue the pro’s and con’s of job stories vs. user stories in this post, both have their merits and weaknesses – i’m assuming you’re along for the ride and want to give job stories a shot. If you want to understand details on how to write job stories – I suggest reading Alan Klement’s excellent post on writing Job stories.
You can now take your customer jobs from the value propositions canvas which effectively are your outcomes and use them as starting points for building out job stories – the key elements you’re adding is situational context and motivations.
Job stories take the following format,
When … a situation
I want to … the motivation
So I can … the expected outcome
Returning to our photo management app, an example job story might be, “When I’m going through my holiday photos, I want to find photos for a particular date, so I can share these with my friends.”
Take note there is no mention here of a “professional”, “amateur” or “casual” photographer archetype, do we really care about the individual’s socio-economic background, or what they do in their spare time, to help us build a product feature? Having that information adds no real value at this stage (good for marketing, yes), in fact having these persona details produces more noise we need to filter out.
Conversely, adding more context does help us to understand the problem, and the goal the individual is attempting to achieve. The more context or motivational elements we add, the better we can build this feature, and prioritise it into the overall user experience.
Alan Klement uses the concept of “forces” in expanding out job stories, I’ve founds these particularly useful in focusing on the crux of the feature and making sure it works in context. Let’s revisit the job story with some added forces.
When I’m going through my holiday photos, I want to find photos for a particular date, so I can share these with my friends.
Force: I am getting frustrated having to sift through so many images…
Force: I just want to share a handful of photos…
Force: I don’t want to spent too much time doing this…
So now with forces identified – you have got more contextual and motivational information. Good solutions, remove or alleviate these negative forces, to make the process of finding and sharing less painful to achieve the user’s desired outcome.
In this instance negative forces can be reduced by helping to narrow the photoset quickly to remove the frustration a user feels by being overwhelmed by having to deal with so many images; furthermore the process needs to feel quick as they don’t want to spend too much time doing this mundane filtering task – they want to share the photos and move on in their lives.
You can begin to see the importance of context, and the impact it can have to shape your overall functional design. This becomes even more apparent with mobile and tablet apps – where a user’s situational context can vary massively.
Tying it all together
I find taking the VP canvas and building the job stories from here helps you to revisit and rethink your customer profiles and the jobs they need to do. It also helps to make sure your product features serve an actual purpose and aren’t just there for the sake of it.
Translating the customer jobs into job stories, allows you delve deeper into the functional detail you’ll need to when crafting the product’s UX. This process affords you some level of filtering so you’re not having to consciously block out wider person elements that have little bearing on what you’re actually designing.
Finally – building up customer jobs from assumptions is a good start, to get your initial concepts and ideas together; but it’s just the beginning and you need to start validating your job stories and customer profiles as soon as possible. Start speaking with your users, observing them performing key tasks, and elicit those pains they want to remove and the gains they want to achieve really understand their motivations and situational contexts. Reiterate over your product/customer map, validate your assumptions and challenge your initial value proposition and whether it need to be strengthened or radically altered.
Changing your value proposition can be daunting, but so can clinging onto a building a product that doesn’t work for your customers. Remember, be honest with yourself and at every iteration ask – does our value proposition still hold true for our customers?