Writing Context Scenarios? Start at the End

If you’ve watched as many YouTube videos as I have, you’ve inevitably seen some ads for Master Classes. These are online classes taught by some of the most renowned names in their respective industries—Ron Howard on directing, Gordon Ramsey on cooking, Steph Curry on dribbling and shooting, etc.

In the ad for Malcom Gladwell’s class about writing, he offers this bit of advice: Don’t start your story at the beginning. Start it at the end, because when you have the end figured out, you know what you have to do in order to get there.

This same idea can be used for writing context scenarios: With the end goal in mind, work backward, step-by-step.

The Goal has Nothing to Do With Software

So often in writing context scenarios, we start and end with the experience of using the software in which we are designing. Take booking airline tickets, for example. We might start with the user opening the [insert airline] app on their phone and searching for round-trip flights from Boston to Grand Rapids for February 2–7. The user might select two adults and press search. Many, many, many more steps later, the user clicks on a boarding pass generated from the flight details and scans it at the gate to board the plane.

The problem with that scenario is that we are hyper-focused only on the experience of using the app. The user’s goal is not to use an airline app; it’s to get to and from Grand Rapids safely.

How different could this story look if we started it this way instead? The user walks through their front door on February 7th with their luggage in hand and a smile on their face.

Working backward, we can say they got out of their car and removed their luggage from the backseat. If they are getting out their car with luggage in hand, obviously, they must have been somewhere.

Since we are developing software for an airline, let’s go with the scenario of returning home from the airport. And as we work backward, we can get all the way back to booking a flight, capturing all of the necessary steps in-between.

When the Scenario Includes More than Software, Maybe the Software Can Do More

If we begin to capture all of the necessary steps for the user to return safely from Grand Rapids, we will inevitably find areas where we assume the software plays no role. These are amazing opportunities to look at the scenario and ask if we can improve it through the use of our software, or if it’s an area we simply just need to understand for context.

For example, our user opens a boarding pass from the app when they are about to board the plane, but what if there were an opportunity here to send them a push notification when their boarding zone was called? Opening the notification could take them directly to their boarding pass without the extra step of opening the app and finding the pass themselves.

Capturing Diverging Scenarios

The other problem with a forward approach is not capturing exceptions or diverging scenarios. In our original example, we assumed the user is using the app to book tickets. But if we work backwards, maybe the user has already booked their tickets. We can then ask, “But how?”

They could book them through a native app, a mobile site, a desktop site, a third-party site, at the ticket counter, etc. These could all be possible diverging scenarios that we need to capture.

On top of that, working backward exposes additional systems that could affect the software we’re building. How are all of these communicating? Who’s responsible for that? What’s the source of truth?

Mapping out all of the different inputs and outputs into the context scenario can help us understand the overall experience from an ecosystem level as well. You can read why I believe starting with an Ecosystem Map could help begin any project.

Capture it Backwards, Then Play it Out Forward

Once you’ve captured the context scenarios starting at the end, try playing them out in a forward progression. Does the timeline hold up? Are there any critical missing steps? Playing it forward can expose details that may have been overlooked.

As an extra logic check, try to bring in other people who weren’t a part of writing the scenarios backward. If your progression makes sense to them, it’s a good sign that your thought processes make sense.