Writing Scenarios

In the last chapter we learned how to create a persona to encapsulate important information about our prospective users. In this chapter we will put those personas to work, developing realistic scenarios in which they use our application.

What is a Scenario?

When we develop an application in an Agile way, we like to think that the users' needs motivate the development of the functionality. We want to always provide valuable software to our end user, and by focusing on what the user actually wants to accomplish (rather than what we think is cool, or a good idea) is the best way to align our software with our user.

Using personas has helped us define one or more prototypical users and has also helped us understand their needs, wants, and motivations. They let us step into the users' shoes and think like they think. We can use our personas as actors in little stories or scenarios that further define how the user interacts with our application. "Specifically, we need to be thinking through every design decision based upon a need > experience > outcome narrative. What does the user need? What kind of experience does our solution create? Does our solution work?" (Source: https://www.newfangled.com/how-to-tell-the-users-story/)

"A user scenario is like a short story of a person who visits an application with a certain motivation and a specific goal in mind. A good user scenario includes all information that is relevant to the process the user undergoes in order to reach his or her goal, and nothing more." (Source: http://blog.usabilla.com/how-user-scenarios-help-to-improve-your-ux/)

Why are Scenarios Important?

Without getting too deep into philosophy and biology, the fact is that, as humans, we are very good at relating to stories. We've been telling tall tales, as an educational activity, since we were cave dwellers and reciting oral history long before it was written down. When we tell a story, so much more can be conveyed beyond just the facts. We understand perspectives, motivations, subtle needs, background. In short, we begin to empathize.

Scenarios are a way of applying this important characteristic to our development process. By providing deep context, we help define the nuances of our application and prioritize functionality when we are further along in the planning process. "Elaborate scenarios give more details. These details give the development team a deeper understanding of the users and users’ characteristics that may help or hinder application interaction. Knowing this information, the team is more likely to develop content, functionality, and site behavior that users find comfortable and easy to work with." (Source: http://www.usability.gov/how-to-and-tools/methods/scenarios.html)

How do we Write a Scenario?

"Your scenarios should anticipate the user’s goal, specify any assumed knowledge, and speculate on the details of the user’s interaction experience." (Source: https://www.newfangled.com/how-to-tell-the-users-story/) "Scenarios can be very detailed, all the way to very high level but should at least outline the ‘who’, ‘what’, ‘when’, ‘where’, ‘why’, and ‘how’ of the usage." (Source: http://www.uxforthemasses.com/scenario-mapping/) Generally we want to write the story describing the need, the experience, and then the outcome.

Other than the above there are not hard and fast rules about writing user scenarios. This is the time to put your creative writing hat on and write plausible interaction stories for your application idea, using your personas as characters. Let's work through a few examples for our persona Janet:

Scenario 1: Recording a Todo

Janet is a busy soccer mom with two kids and lots of responsibilities, she is often on the go and is constantly bombarded with requests for her attention. While she is watching her childrens' soccer game, she runs into a colleague that asks about the reports that are due the following week. Janet knows these are important and wants to jot down something to remind herself of these reports. She takes her iPad out of her purse and launches our Todo application, she types in a message about checking up on the reports and saves it.

Scenario 2: Viewing Todos

Janet is at her office and reading over her emails and catching up with co-workers over the inter-office chat. It's the morning and she likes to get an overview of all thing things that could require her attention this day. She fires up our application on her work computer and sees a list of all the todo items she has entered. Very quickly she is able to identify important tasks and start working on them.

Scenario 3: Setting Reminders

Janet has a very important deadline for a report she is writing. It could make or break the program on which her team has been working. While she has lots of things on her todo list that she "could get around to", this is not one of them. She needs to review the final edits on Friday, no matter what. She creates a todo item to "review final report edits" and then attaches a time reminder for "Friday at 8 a.m.." On Thursday night she has to cook the kids dinner and help them both with their book projects. She is so frazzled by the end of the night that she isn't prepared for the next day. When she checks her email Friday morning she sees a reminder email from our application telling her to "review final report edits." She does so and is thankful that our application keeps her on top of things.

Scenario 4: Organizing Todos into Lists

Janet has lots of things to keep track of at work, at home, with her kids, and some times she has missed important todo items because they have been cluttered up with less important ones. She finally has a little free time while waiting for her kids at the school's pick up area. She pulls our her iPad and launches our application. She creates a few "lists" for different areas in her life: work, kids, finances, errands, dog, and home. Then she starts moving all of her existing todos into each of the lists. When she is done her todo list is very organized and at a glance she can see what needs doing. At work she focuses on the "work" list, and when she is talking with her children she is sure to add any relevant items to the "kids" list.

Scenario 5: Sharing Todo Lists with Friends

Janet is relived that her husband is home for a few days from one of his many business trips. He has a few days off, but its a particular busy week for Janet and she is hoping she can offload some of her typical todos onto her husband. The house is out of a ton of groceries and the kids need materials to build a science project. She creates a list for "groceries" and jots down all of the items they need from the store, she also moves in the todo item "construction paper" from the "errands" list and "dog food" from the "dog" list. She then shares this list with her husband. He receives an email and is able to view and mark things completed on this todo list. He goes to the store and gets everything that they need.

Have some fun! If you notice, the above scenarios are not dry, just-the-facts, types of stories. Instead, they have interesting details and background information that helps you identify with the user. Also, note that there really aren't specific implementation details at this stage of the game. We don't know much about what the user clicks, or drags, or sees, we just know about general actions and outcomes. We will get into specifics later; right now the details will just get in the way.

Focus on the Core

When you are coming up with scenarios, there will be lots of use cases represented. We detailed 5 above. Some of these use cases can depend on others. For example, it's hard to set a reminder for a todo if there is no way of adding it! Or, you can't share a todo list with a friend if the idea of a list doesn't exist yet. We call these types of relationships dependencies and once you recognize them, you will start to identify the core of your application.

You can think of "the core" in two ways. First, you can think of the core of the application as the thing that really solves the majority of your end user problems. Second, you can think of the core as "that, on which the rest of my application depends."

At the heart of our todo application we really just want to record todos, then shortly thereafter view a list of them. This task of simply taking down todos may solve 80% of the user needs. If we get this right, we will have a lot of happy users and we can build more interesting features on top of this core to solve other use cases. But without a good core, or foundation, it will be hard to grow our software.

It can be really valuable to write lots and lots of scenarios, describing the basics all the way to the complicated use cases. Exhaust yourself, get out all of those good ideas. But then step back and remember your users, and what problems you are trying to solve. Organize your scenarios in terms of "solving most users' most frequent problems." Also organize your scenarios in terms of dependencies:

• We will probably need the "sign up" scenario, before the "log in" scenario.
• We will probably need "add a todo" before we can "view todos"
• We will probably need "create a todo list", before we have "share a todo list"

Focusing on the core can save you a lot of time and effort. There is an idea called Pareto's Law or the 80/20 principle. With software applications, it is commonly found in research that 80% of the users use 20% of an application's functionality. (Source: http://www.allaboutagile.com/agile-principle-8-enough-is-enough/). So once you have a deep understanding about what the core of your application is, you can build that core and leave the rest "for later."

What's Next

In this chapter we build several scenarios describing basic use cases for our application. We don't really know what the application could look like. In the next chapter we will expand the scenarios into storyboards and ultimately wireframes to transform our ideas into something tangible.