How to Write A Useful Scenario Walkthrough

When you walk into a room with an engineering team, a conversation about building a product can easily turn into a discussion about features, architectures, and implementation details. A scenario walkthrough provides the team with a window looking into the real world where the protagonist is a real person, not the programming language.

Facilitating A Scenario Walkthrough Session

If it’s at the very beginning of the project, when the team is trying to reach a consensus of what the product needs to be, a scenario walkthrough can be a useful team activity. It’s better done after the key persona has been identified and understood by the team.

How it starts: A facilitator, often a designer, writes on the whiteboard, and the people in the room speak aloud what needs to happen in that scenario. The participants may include the key stakeholders, the product owner, designers, product managers, engineers and so on.

The scenario walkthrough is like a scene in a play, a single setting on the stage. We don’t try to include all of the characters nor every cause-and-effect in the play. Scoping at the scene level, not the entire act, is helpful to keep the team focused on the goal of coming up with the MVP (Minimum Viable Product).

Sometimes the team in the room may have difficulties narrowing down to a single scene. In that case, try to write down a quick plot that holds the entirety of the product vision, then encourage the team to focus on the first scene that needs to happen to kick off the play.

The team session usually lasts about 30 minutes to an hour, and produces a couple of paragraphs on the whiteboard. After the team session, the designer and the product manager sit down together and vet the details.

SettingThe Scene

The document we write here at Pivotal Labs usually starts with the context of this project. For example:

It’s the beginning of April and the QR (Quarterly Review) is coming up in a few weeks. Amelia needs to put together a report about last quarter’s marketing strategy, showing how it has impacted the sales. Typically she needs to conduct a T-C (Test and Control) analysis on last quarter’s A/B Testing data so she can draw conclusions. This needs to be done by next week.

First of all, this paragraph explains Amelia’s key problem: to put together a quarterly report. It also implies that Amelia is most likely to use this application occasionally, therefore making it part of her daily life is not a primary goal.

Second, it provides the context of Amelia’s work. This job is to be done in a few days, probably up to a week. It prompts a few questions for us to dig deeper: She can’t be sitting at her desk a few days straight through. What else needs to be done besides working from a computer? What is the most time consuming task for Amelia in this work flow?

Third, this paragraph should introduce as much jargon as is relevant to this product. After this paragraph, the team should have a common understanding of what the jargon means, and how it is used in the context.

Crafting The Scene

Once the scene is set, we give a brief peek into the protagonist’s mind. As software people, we’re likely to have empathized too much with our best friend, the programming language, and have forgotten how humans think. The point here is again, to put the human in the center of the stage. For example, the text below helps the team to understand how the human sees the problem:

To report on the impact of last quarter’s strategy, Amelia lists the questions to answer in her notepad:
1. Is the sales volume rising since we rolled out the new campaign?
2. Is the data from the A/B Testing in alignment with our assumptions?
3. If not, what could be wrong?…

Next, we describe how our product can help Amelia to answer these questions. It needs to have a clear beginning, where the protagonist starts a task with a clear goal in mind. It ends with the protagonist accomplishing her goals and disengaging with this application. For example:

She opens the application, and creates a workbook. She names the new workbook 2016Q1 T-C Analysis and begins. First, she connects to the database of sales. Then she pulls in a generic data table to remind herself about the column names…
…
… She compares the actual sales and projected sales in a line chart and sees the market did respond to the new campaign as expected. She highlights a few data points, and exports the graphs. She has her Powerpoint open next to our application. She switches between the two applications, tweaking the data table and graphs, and assembles the report.

A good scenario walkthrough has these qualities:

It describes the interaction points, but not any specific interface design. It’s probably second nature to us software people to use UI language like, click “Add New”, type in the text box, pick from a dropdown… But it’s important to avoid prescribing a solution at the scenario level. A scenario walkthrough should focus on describing the human behavior. Replacing the UI prescription with more generic verbs (create, connect, open, export…) can inspire designers and engineers to come up with more ideas.

It provides data fidelity for the design mockups that would come later. We know Amelia named her workbook “2016Q1 T-C Analysis”, not “lorem ipsum” nor “workbook_0001”, because we did our user research. We have sat with them, talked with them, and watched how they organize their files and folders. Like a good fictitious story, a scenario walkthrough is fabricated, but your attention to the details makes it believable.

Using Your Scenario

The documented scenario walkthrough should be less than a page long. The brevity gives the team a high level idea of what to build. I highly recommend printing it with a large font, and posting it to the wall so that everyone can comment and ask questions.

We can use the scenario as a context to prevent feature creep. Sometimes a team member or a stakeholder might get excited about a particular solution and says: “Let’s consider a built-in support of Chinese, Korean and Japanese. The application needs to be installed across all of our global branches.” That’s when it’s time to pull out the scenario walkthrough, and ask, “How does that fit into Amelia’s goal of putting together a report? Did Amelia analyze the data from their global branches, or did she collaborate with her colleagues in Korea? Where in her workflow would she need to switch to a Korean interface?”

This kind of reasoning either gets the team back to the initial focus, or reveals a neglected use case that needs urgent attention. Keep in mind: The scenario walkthrough is not meant to be written in stone, instead view it as a living document that’s constantly being questioned, adjusted, and enhanced.

In the example scenario above, we didn’t specify how Amelia pulled in the data tables. It left us space to imagine a graphical UI where she could type in the data table name, choose a column name from a dropdown menu and then pick the data range, all in a consecutive manner.

We built a quick functional prototype and let some of our target users give it a try. It turned out that the data tables were too massive. Interacting with a graphical interface was too slow for the users and all of them were already proficient with SQL. So in the following iterations, we specified that Amelia wrote SQL to obtain the data she needed.

After the initial scenario walkthrough with the larger team, we often need to create complimentary scenes as we go. If not the entire team, at least the designer and the product manager sit together and pair on writing the following scenes.

It’s important to remember that the scenario walkthrough is fictional. While it provides a possible future that we as creators envisioned, ultimately it is still just a set of assumptions. It’s meant to provide some guidelines for the team to build prototypes and MVPs so that we can validate those assumptions.

Building a lasting product is not unlike producing a TV series. At the planning stage, the writers often just have a plot (product roadmap) and a character sheet (personas). It’s important to create a great pilot episode (problem statement), and get picked up by the network (funding). It’s also important to air some trailers to gauge the audience response (prototypes). From there on, you can enrich your story lines (enhancement features), or introduce more characters (segment expansion). If your audience still loves you after the first season (MVP launch), you get to produce the next season (finding market fit). Or you need to pivot.

As any good fictional writer or avid reader could tell you, a story often takes on a life of its own and develops in a direction the writer never thought of. It’s the same way with software. That’s the beauty of creativity, it can take you to some surprising and novel places.

Disclaimer: the scenario example is modified to protect the client’s privacy.

Want to join Labs? We’re hiring designers, software engineers, and product managers.