Job Stories in Practice
I’ve previously written on some history of Job Stories and how they relate to User Story format. The main benefit of using Job Stories in product development is to define a greater understanding of the design problem without leading the design. Let’s look at that format again:
Format : When [name situation], I want to [list motivations and forces], so I can [expected outcome].
Example : When I’m looking at perspective campuses, I want to know what the campus looks like so I can envision myself walking to class or studying on the grass.
In practice, I rarely write these long cases out in prose. The narrative form does help communicate among stakeholders the scope of projects, which is useful for buy-in before you do all your hard work finding awesome solutions. For personal use, I enter the meat of the statements into a sortable spreadsheet:
spreadsheet headers: [ workflow ] [ situation ] [ incremental progress ] [ expected outcome ]
As time goes on, each situation statement I run across accumulates in the same spreadsheet. This spreadsheet becomes a location of truth: is this request an attempt to improve a current situation or are we introducing whole new situation into our product space. Spreadsheets help maintain sanity and consistency across a whole product’s situation space. Let’s dive into a hypothetical design situation for practice: a education platform with video content, something similar to Khan Academy or Udemy.
A Walk-through
Let’s dive into students’ use of this platform and in particular, let’s examine a student’s workflow for completing a lesson. Completing a lesson is one of a few various workflows that students might do on this platform. Other workflows for this platform might include ‘complete a class’, ‘enroll in a class’, ‘search for classes’, or ‘share with classmates/community’. All of these are the high-level, independent workflows that do not temporally overlap in usage. Adding a workflow to our story looks like this:
complete a lesson • [ situation ] • [ incremental progress ] • [ expected outcome ]
Within completing a lesson, there are a number of situations the student might want to do or that we as designers might want to impose. These might include consuming a lesson, reflecting on a lesson, sharing within a community, and demonstrating knowledge. Again, this isn’t meant to be exhaustive.
There are, or should be, numerous situations comprising a workflow. Generative research activities are a good way to start figuring these out: watch over a shoulder in a user’s natural habitat, do a top tasks survey, create some mental maps. The wonderful people over at uxdesign.cc has amazing resources describing methods and tools. The Nielsen Norman group provides some good guidance about when to use which technique. Here’s a few situations that might be in our hypothetical workflow:
complete a lesson • hear/see something interesting or insightful • [ incremental progress ] • [ expected outcome ]
complete a lesson • unsure of what was said or bad transcription • [ incremental progress ] • [ expected outcome ]
complete a lesson • didn’t understand something • [ incremental progress ] • [ expected outcome ]
complete a lesson • need clarification on an assessment • [ incremental progress ] • [ expected outcome ]
Granularity
At this point, I often come across the question of granularity. Do I want a workflow to be as broad as ‘completing a lesson’ or do I want to get more granular like ‘watching a video’ or ‘reading a excerpt’. Is ‘Watching a video’ a workflow or a situation?
I’ll let you in on a secret: there’s no right way to do this! As product teams, we can choose how fine we tune our lenses. Over time, we get a feel for how granular to go based on how explicit the specific product team’s needs are. Let’s take the first situation from above and check out a few ways to write it.
complete a lesson • hear/see something interesting in a video lesson •
[ incremental progress ] • [ expected outcome ]
A good rule of thumb is if you start using prepositions in your situation statements: in the video or during the video, it’s a good indication you need to go one level deeper or look at your workflows again. Two different ways to address this are to create a sub-situation (or sub-sub-situation)
complete a lesson • watch video lesson • hear/see something interesting •
[ incremental progress ] • [ expected outcome ]
Or to refine your workflows to be more granular
complete a video lesson • hear/see something interesting •
[ incremental progress ] • [ expected outcome ]
Defining Scope with Outcomes
For simplicity, we’ll use the second option:
complete a video lesson • hear/see something interesting •
[ incremental progress ] • [ expected outcome ]
I find it’s best to skip the [incremental progress] section and go straight for defining the [expected outcome] first. I find myself easily jumping to solutions in my mind when I write out progress statements first, which is the last thing I want to do. Where one outcome can have many ways to progress towards it, I find it less common that a progress statement will have multiple outcomes. So let’s play the empathy game: what outcome might a student expect or desire when they hear or see something interesting while completing a video lesson? (feel free to add more in the comments!)
complete a video lesson • hear/see something interesting • [ incremental progress ] • study thing x before an exam
complete a lesson • hear/see something interesting • [ incremental progress ] • reference thing x while doing homework
complete a lesson • hear/see something interesting • [ incremental progress ] • ask a friend’s opinion about this
complete a lesson • hear/see something interesting • [ incremental progress ] • receive clarification from the teacher
complete a lesson • hear/see something interesting • [ incremental progress ] • share this with an in-site or external social community
complete a lesson • hear/see something interesting • [ incremental progress ] • internalize this
Whoa, that’s a lot more than I initially expected; it’s a super fun brainstorming activity! If we had started with one possible progress statement, ie ‘mark video location’, we lose the intention of the user to use the video as future reference material, or to communicate with others about a specific part of a video, or referencing a video aspect when asking a question. These intentions — what they actually want — is what we design for and find intuitive ways for users to complete.
When we start with progress statements, it starts to resemble feature-based design. Ruh huh.
This activity is very useful during the discovery phase — now we can state which of these outcomes we do have time/money/motivation to handle and which we do not. Super cool. And we did this with being somewhat ui-independent, meaning we’re not leading with solutions.
Progress towards designs
Finally, to complete this job story, we can start to fill in incremental progress. Let’s look at our story with out ‘study thing x before an exam.’ Back to the brainstorming board, batman!
complete a video lesson • hear/see something interesting • mark video • study thing x before an exam
complete a video lesson • hear/see something interesting • add to study library • study thing x before an exam
complete a video lesson • hear/see something interesting • export snippet • study thing x before an exam
complete a video lesson • hear/see something interesting • create timestamped comment • study thing x before an exam
This is by no means extensive and we’re already seeing very different ways a student can achieve their desired outcome. Progress statements will align to business goals and objectives to different degrees. It’s arguably bad to implement every one of these situation statements.
Read those statements again and notice we’re starting to define ui needs: export snippet implies defining the start/end time and a download button, mark video implies some kind of timeline marking, and possibly navigation or summary of those markers, timestamped comment implies a comment interface with input and showing past comments.
Determining Scope
The benefit of using job stories in a design cycle is to see what design space is possible and be able to weigh options against each other. Each job story will have a different combination of evaluative research for design solution(s), front-end & back-end engineering work, integration with current product, and adherence to long term business goals.
Maybe we as a hypothetical product team, really like the job story with comment approach because it collectively solves/allows/achieves the most outcomes in the least dev time and works towards a more conversational tone that we’re able to use to attract social media partners(read: business goal).
Consistency & Architecture
We just created numerous job stories during a simple and shallow exploration. Our list will quickly become unwieldily once we start building out an entire site. For those data nerds out there, I’m with you in saying: spreadsheets to the rescue! Let’s look at those headers again:
[ workflow ] [ situation ] [ incremental progress ] [ expected outcome ]
So when we’re deciding whether commenting or marking a timeline is a better incremental progress, we can sort [incremental progress] and see if either are currently implemented in our site. We can filter down a expected outcome of ‘ask a question’ and see how we’re providing incremental progress towards this outcome in other parts of the app. This allows us to be consistent in our ui implementations. When we’re looking at site architecture, we can test how accessible each workflow-situation coupling is from each other. This assumes I’ll be doing multiple situations within a workflow at the same time. Setting up job stories in a spreadsheet will become your ultimate testing guide.
Next Steps
Well our work is done, right? From here, there’s three steps:
1. Define success metrics
2. Design multiple UIs implementation
3. Determine which ui performs best through evaluative research
In the upcoming weeks (or months) I’ll dive into how to base testing metrics on specific job stories. Metrics will allow you to state what a successful design is, and measure success over time. They’ll empower you to state whether a job story you’re currently handling is succeeding or needs to be redesigned. They’re essential in evaluative research design, essentially setting the barebones structure of your testing plan.
When metrics define what will be successful, we can now bust open illustrator or sketch or insert-trendy-app-here and start crankin’ with a purpose and designing with touch points that measure what we want. Also coming in the next bit is a article describing how to use these stories to define which ui elements are needed.
