How to write scenario

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.

How to Write a Scenario that Actually Engages Your Learners

Picture this: you’re sitting down to write a storyboard for an eLearning module—one that’s important to your organization, but one that you know will bore the socks off of your learners. You stare at the blank screen. What do you do?

In this case—and many others—we’d opt for scenario-based learning. Scenarios are a highly effective learning strategy for engaging learners and helping them practice skills and build confidence in realistic environments. Plus, everyone loves a good story: writing scenarios for training leverages the power of storytelling to simplify complex topics and encourage learners to reflect on what they’ve learned. More often than not, scenarios are the most interesting, relevant, and engaging choice you can make for your learning experience.

But not all scenarios are created equal. It takes practice to learn how to write a scenario that keeps learners engaged and helps achieve your learning goals. We’ve been putting in the work to learn what makes a scenario successful—here’s a quick overview of scenario-based learning and a few simple steps for how to write a scenario that engages your learners.

What is scenario-based learning?

Scenario-based learning is an interactive instructional strategy that uses real-life situations and narratives to actively engage learners. While we’ve learned a lot about how to write a scenario ourselves over the years, we have to give credit to Cathy Moore, a thought leader in the learning space who wrote Map It, one of our favorite books.

There are two types of scenarios that we tend to use: standalone scenarios and branching scenarios.

Standalone scenarios

Standalone scenarios are more basic, with the learner engaging in just one question per scene. Rather than walking your learners through a step-by-step tutorial, a standalone scenario prompts the learner to think through the impact of their decision.

Standalone scenarios can also be used consecutively to create what we call a “building scenario” with multiple narratives and questions back-to-back that build throughout the content and refer back to the previous scenario. Building scenarios offer an intermediate option between a standalone scenario and a true branching scenario.

Branching scenarios

This form of scenario-based learning allows for branching possibilities based on the choices learners make in a given situation. Branching scenarios typically cover more complex topics with multiple decision points, where the outcome changes depending on the decisions the learner makes. It’s also a great option when you want learners to understand the best possible choice they can make among several good options—seeing it play out is often the best way to grasp the nuance of the scenario.

In both cases, the best scenarios replicate actual decision points learners will experience in real life.

So, why use scenario training in your learning? Writing scenarios allows learners to picture themselves in a potential future situation and test out their decision-making skills (without consequence!) in a relevant, relatable environment. Scenarios are a stickier learning experience with high engagement and a great track record for triggering behavior change. Who can argue with that?

It all sounds great on paper, but it’s worth noting that a poorly-executed scenario can seriously damage your learning outcomes. If your scenario doesn’t read as realistic to your learners, you run the risk of losing your credibility with them, which can lead to disengaged, checked out learners. Here are a few common pitfalls that can throw your course off track:

Now that you have an idea of what can go wrong in a scenario, let’s get to what makes one successful. Here are four steps (and a bunch of pro tips from our ID team!) for how to write a scenario that really resonates with your learners.

How to write an engaging scenario

A lot goes into how to write a scenario, but it comes down to four basic guidelines: make it relevant and challenging, keep it realistic, mind the details, and bring your scenario to life. Here’s how to apply each step in your own scenario-based learning.

1. Make it relevant and challenging

Don’t waste learners’ time

Relevancy is key to any effective learning experience. What will learners gain from this scenario? A good guideline is to take a step back and consider your learning objectives. What are the most important behaviors learners need to walk away with? What scenarios can you create that have learners practicing those behaviors?

Make them stop and think

Learners appreciate a good challenge, so try not to make your scenario too easy or obvious. There’s no reason to actively try to confuse them, but there’s nothing wrong with making learners stop and think—if your scenario is too easy, they may tune out.

Show (don’t tell) the consequences

A great scenario shows learners the consequences of their choices by continuing the story. This form of feedback gets the learner to infer whether they made the right choice, rather than simply telling them if their choice was correct or incorrect. After showing the consequence, that’s when you can include instructional text or direct them to a job aid to provide additional feedback.

2. Keep it realistic

Strive for accuracy

There’s nothing worse than creating a scenario that your learners will roll their eyes at. In many cases, your learners have been working in this role or doing similar tasks for years. When thinking about how to write a scenario, relatability is top priority. Use the language they use, capture the nuances of their day-to-day lives, and depict difficult situations that they’ll actually run into on the job. What might tempt them to make the wrong choice? Learners will notice these details and appreciate them.

Understand the context

Strive not only for accuracy in what you’re trying to teach, but also in context. Time and place add realism to your scenarios, but only if that context truly feels authentic to learners. If you aren’t familiar with the context of the decision point, do your research: find firsthand accounts online or, better yet, schedule time to interview actual learners themselves.

3. Mind the details

Don’t add distractions

While it’s critical to include details that will help learners visualize and relate to the scenario, too many unnecessary details can be distracting. And don’t use details to try and trick learners or throw them off the trail—every detail should add to the logic of the scenario and move the narrative forward. If you find yourself getting bogged down in the details, focus on the decision point: set the scene and create a logically complete scenario with a clear beginning, middle, and end.

Choose the right POV

It may seem like a matter of preference, but point of view (POV) can influence how learners relate to the story you’re telling. Part of deciding how to write a scenario is choosing between the second-person (you are in the scenario) and third-person (you are an observer of the scenario) point of view.

Consider to what degree the learner will see themselves in the scenario. Second-person POV is a good choice when you want learners to place themselves in a scenario, but only if you’re fairly confident that they’ll actually identify with the scenario. If not, this could cause a sense of dissonance (“I would never do that!”) that distracts learners. Third-person POV is a safer bet for situations where learners may not relate to the content, or your learner audience covers multiple roles.

4. Bring the scenario to life

Choose your medium

It’s showtime, and you’re looking for the right modality to bring your scenario to life. You can create great scenarios through writing, audio, video, still image—or any combination of the above. Be sure to follow the guidelines outlined above for how to write a scenario, and keep learner context in mind to maximize engagement.

Consider branching scenarios

If you have the ability to create it, consider incorporating branching or multi-part scenarios into your learning. It’s the most immersive approach to scenarios: learners not only see the consequences of their actions, but also make new decisions based on the previous choices they’ve made. That said, not all scenarios call for this. Branching scenarios require a lot of time and effort for both the instructional designer and the learner, and standalone scenarios are often enough to get the job done.

Engaging scenarios lead to better learning outcomes

There’s nothing worse than enduring a boring, irrelevant learning experience. With scenarios, learners get to take an active role in their learning and put their skills to the test in a relatable, low-risk environment. When done right, scenarios are a powerful tool for challenging learners and inspiring real-world change that they can put to use right away.

Learning is so much more than conveying subject matter—it’s also understanding people and how they learn.

Our Learning Principles are a powerhouse of practical, strategic guidance that shape and enhance every experience we create.

An onboarding app serving learner needs

Southwest’s onboarding app helped new hires better navigate their first months on the job

How to Write Good Task Scenarios for User Testing

A task scenario is the number of steps a user has to take to complete a goal. It describes what the user is trying to achieve by giving context with the necessary details to accomplish the goal without being too prescriptive.

Task scenarios accompany user tests and are used as a way to check whether a user story is effective, efficient and satisfies the user needs. The following tutorial will explain how to write a good task scenario.

What Makes a Good Task Scenario?

In my experience, writing a good task scenario is more of an art than a science. I’ll use an example, and then go into each principle of good task scenarios and how they relate back to that example, so that you have a better idea of how to create your own.

Task Example: Find Lodgings on Airbnb

Say you have an international flight to Kathmandu, Nepal in October. You arrive on the 5th, but your friend will only be available to host you from the 8th onwards. Find a place on Airbnb from the 5th to the 7th for less than the average price per night ($58).

You could always bunk up with this macaque?

The steps in this scenario might look like this:

Good Task Scenarios Give Context

A good task scenario gives you a bit of context, so that users can behave as if they actually need to perform the task.

In the example above, I have given a realistic backstory to give context “You have an international flight to Kathmandu, Nepal in October. You arrive on the 5th, but your friend will only be available to host you from the 8th onwards”.

Good Task Scenarios Provide Details

A good task scenario provides specific details that the user needs to know. These may be model numbers, prices, items, categories, dates etc

In the example above, I have given dates (5th to the 7th of October). I have also included a location (Kathmandu, Nepal) and the average price per night ($58).

Good Task Scenarios Aren’t Too Prescriptive

When setting a task, you should aim to provide details and context without telling the user what to do (otherwise, what’s the point of doing a usability test?)

For example above, I have stated, “Find a place on Airbnb from the 5th to the 7th for less than the average price per night ($58).” And not “Click on the calendar at the top of the screen to find your booking”.

Good Task Scenarios Have a Correct Solution

Conclusion

A good task scenario is critical to running a valid user testing session. Without framing the question correctly you may get biased or inaccurate data. This tutorial isn’t an exhaustive list, but more of a fundamental overview. There are many factors to consider. In my experience, if you give context, have a strong backstory with details, and provide a correct solution, you are likely to get a smooth user testing session.

Do you have any other tips of how to write a good task scenario? Leave them in the comments below!

Further Reading

To learn more about user testing, check out these articles on Tuts+:

An Introduction to Remote Usability Testing

Quick Tip: How to Run a Guerrilla Testing Session

Usability Testing Tools for Quick and Early Feedback

How to Write a Script (Step-by-Step Guide)

So you want to write a film script (or, as some people call it, a screenplay – they’re two words that mean basically the same thing). We’re here to help with this simple step-by-step screenwriting guide.

Writing a script? Then you need a storyboard. Try the #1 storyboard software for modern video teams.

Lay the groundwork

1. Know what a script is

If this is your first time creating movie magic, you might be wondering what a script actually is. Well, it can be an original story, straight from your brain. Or it can be based on a true story, or something that someone else wrote – like a novel, theatre production, or newspaper article.

A movie script details all the parts – audio, visual, behaviour, dialogue – that you need to tell a visual story, in a movie or on TV. It’s usually a team effort, going through oodles of revisions and rewrites, not to mention being nipped ‘n’ tucked by producers, directors, and actors. But it’ll generally start with the hard work and brainpower of one person – in this case, you.

Because films and TV shows are audiovisual mediums, budding scriptwriters need to include all the audio (heard) and visual (seen) parts of a story. Your job is to translate pictures and sounds into words. Importantly, you need to show the audience what’s happening, not tell them. If you nail that, you’ll be well on your way to taking your feature film to Hollywood.

2. Read some scripts

The first step to stellar screenwriting is to read some great scripts – as many as you can stomach. It’s an especially good idea to read some in the genre that your script is going to be in, so you can get the lay of the land. If you’re writing a comedy, try searching for ‘50 best comedy scripts’ and starting from there. Lots of scripts are available for free online.

3. Read some scriptwriting books

It’s also helpful to read books that go into the craft of writing a script. There are tonnes out there, but we’ve listed a few corkers below to get you started.

4. Watch some great films

A quick way to get in the scriptwriting zone is to rewatch your favourite films and figure out why you like them so much. Make notes about why you love certain scenes and bits of dialogue. Examine why you’re drawn to certain characters. If you’re stuck for ideas of films to watch, check out some ‘best movies of all time’ lists and work through those instead.

Get the Ultimate PDF Storyboard Template Bundle

10 professionally designed storyboard templates as ready-to-use PDFs.

Flesh out the story

5. Write a logline (a.k.a. brief summary)

You’re likely to be pretty jazzed about writing your script after watching all those cinematic classics. But before you dive into writing the script, we’ve got a little more work to do.

First up, you need to write a ‘logline’. It’s got nothing to do with trees. Instead, it’s a tiny summary of your story – usually one sentence – that describes your protagonist (hero) and their goal, as well as your antagonist (villain) and their conflict. Your logline should set out the basic idea of your story and its general theme. It’s a chance to tell people what the story’s about, what style it’s in, and the feeling it creates for the viewer.

In the olden days, you would print your logline on the spine of your script. This was so producers could quickly glance at it and decide whether they wanted to read the whole script. A logline does the same thing, but you usually tell people in person or include it when you give them the treatment.

6. Write a treatment (a.k.a. longer summary)

Once your logline’s in the bag, it’s time to write your treatment. It’s a slightly beefier summary that includes your script’s title, the logline, a list of your main characters, and a mini synopsis. A treatment is a useful thing to show to producers – they might read it to decide whether they want to invest time in reading your entire script. Most importantly, your treatment needs to include your name and contact details.

Your synopsis should give a good picture of your story, including the important ‘beats’ (events) and plot twists. It should also introduce your characters and the general vibe of the story. Anyone who reads it (hopefully a hotshot producer) should learn enough that they start to feel a connection with your characters, and want to see what happens to them.

This stage of the writing process is a chance to look at your entire story and get a feel for how it reads when it’s written down. You’ll probably see some parts that work, and some parts that need a little tweaking before you start writing the finer details of each scene.

7. Develop your characters

What’s the central question of your story? What’s it all about? Character development means taking your characters on a transformational journey so that they can answer this question. You might find it helpful to complete a character profile worksheet when you’re starting to flesh out your characters (you can find these for free online). Whoever your characters are, the most important thing is that your audience wants to get to know them, and can empathise with them. Even the villain!

8. Write your plot

By this point, you should have a pretty clear idea of what your story’s about. The next step is breaking the story down into all the small pieces and inciting incidents that make up the plot – which some people call a ‘beat sheet’. There are lots of different ways to do this. Some people use flashcards. Some use a notebook. Others might use a digital tool, like Trello, Google Docs, Notion, etc.

It doesn’t really matter which tool you use. The most important thing is to divide the plot into scenes, then bulk out each scene with extra details – things like story beats (events that happen) and information about specific characters or plot points.

While it’s tempting to dive right into writing the script, it’s a good idea to spend a good portion of time sketching out the plot first. The more detail you can add here, the less time you’ll waste later. While you’re writing, remember that story is driven by tension – building it, then releasing it. This tension means your hero has to change in order to triumph against conflict.

What is Script Writing? The Essentials to Writing Great Screenplays

W riting a screenplay can be daunting, and there is a ton to consider. However, before you even think about what goes into the document, what is script writing anyway?
Script writing is a very different beast than writing in any other format. Knowing what it entails is critical if you want to have any semblance of a career in the field. So let’s dive into the fundamentals.

the essentials

What do we mean by script writing?

So you have an idea for a movie, but it’s all in your head. You want to get it all on paper, what do you do?

SCRIPT WRITING DEFINITION

What is script writing?

Script writing (or screenwriting) is the process of writing stories in the screenplay medium. Script writing is writing down the movement, actions, expression and dialogue of the characters in screenplay, in screenplay format. The process of writing a novel, a poem, or essay, is entirely different than script writing. In order to express yourself effectively for the screen, particular formatting methods are required. Screenplay format is used to express the story visually. Scriptwriters or screenwriters write for film, television, video games, and now even online web series. Script writing can be done for hire or on speculation in hopes to sell their screenplay or find an agent.

SCRIPTWRITING CONSIDERATIONS

The process of screenwriting is the constant reminder that you are writing for the screen.

So if you write the line, “he remembers their past fights…” what would that look like on screen? In actuality, it tells us nothing. Why?

Well, no one can see his thoughts, so that’s not an effective form of communication when writing for the screen. Externalizing the internal is critical to telling a story visually.

What could you do in this scenario? One way to externalize this would be to add in a montage scene or a series of flashbacks of all the times they fought.

With that in mind, let’s move on to why we have this medium to begin with. Why couldn’t we just write down our movies like we write down our novels, essays, and poems?

WHY Script Format

Why script writing format?

Thinking visually isn’t always easy. Breaking the habit of describing what the characters are feeling doesn’t always come second nature. And knowing how to pace a scene for the screen is equally as challenging.

Luckily basic screenplay formatting helps remedy this.

First things first, formatting helps with geography.

Sluglines or scene headings tell the reader where the action is happening. And action lines tell us what the actors are doing.

This formatting tells the reader where the characters are, or even where you’re taking your audience—a major component of learning to write for a visual medium. See the graphic below to get a better idea.

Notice too, how the characters’ names are indented clearly identifying who is speaking when.

Script writing means writing in screenplay format

One page typed, in this standard screenplay format represents about one minute on screen. Why should I know this?

Well when we’re writing, this is helpful to understand scene pacing. We could think something is working, but a fight lasting for a few pages may not translate well on screen, and could feel drawn out.

Also, knowing how to format your screenplay makes it easy to read and therefore easier to sell. Formatting helps agents, managers, and studio readers visualize your movie.

Pro Tip

Be careful with overdoing dialogue. Get creative with action lines. How a character acts is usually a better indicator of how they feel than what they say out loud.

Writing a screenplay is hard enough, don’t waste time in Word, formatting it yourself.

RELATED POSTS

Up Next

How to Write a Movie Script

You can now answer what is script writing, and hopefully feel a bit better about the next step. Our next post, dives deeper into formatting rules, page count, and other tactical concerns you may have at the beginning.

So open up your software, and read our step-by-step guide on how to get your vision down on paper.