Using Scenarios to Represent User's Needs and to Derive Requirements

Many of you are probably familiar with use cases and user stories (used in agile processes), but I'm finding that many of our clients are still not very familiar with "scenarios" that are used as part of user-centered design (UCD).

So, I thought I would provide a quick description of scenarios and show how they can be used to derive requirements. By using these scenarios to come up with requirements, you are in a better position to both make sure that you have traceability and rationale for features and to help avoid features creeping in only because someone thought it would "be cool" to include them.

While use cases describe interactions between a user and a system, they typically do so in a very system-centric manner, focusing only on the very explicit input/output aspects of the interaction.

User stories purposely lose a little of the detail seen in use cases, and add a pinch of context (e.g., stating the goal of the user), but still really just focus on one low level interaction at a time, and therefore don't give a good sense of the context of use.

What use cases and user stories don't provide are the richer, qualitative aspects about the surrounding context of use...e.g., who is the user, and why is she using the system? What we really want is a representation of the user accomplishing things in a way that will lead to empathy for this user...what do they need or want to do, and why...think of how when you're reading a good book, it's easy to picture the characters, and you feel that you get to know them, and what they're going through. We want that...at least as much of that empathy as we can get in about a paragraph or a page for each key situation we think a user will find themselves in. In user-centered design, we create narratives like this called scenarios.

How do you collect information that puts you in a position to be able write these scenarios? If you can, you should use contextual inquiry methods such as observations and interviews that take place in the actual places where users will be doing these activities. In many cases, you're using scenarios to represent situations that don't yet exist, so you have to find creative ways to get as close as possible to these new situations to gain the proper understanding...look for similar situations in other industries, etc. If you were designing the first online music store ever, you'd want to hang out in bricks and mortar music stores and see the types of questions customers ask.

We use scenarios to represent what users need and want to be able to accomplish. These are just simple textual narratives that describe a good user experience that we want to design for. The most important element of scenarios is that they need to be from the user's perspective. If you can't capture and represent needs from the user's perspective, what chance do you really have in ending up with a product that supports these needs? Again, the goal is to allow people to gain empathy for a user's situation.

 

Here is an example scenario related to a couple using a system to compare cities with the goal of trying to decide on a new place to move because of a job change:

 

"Alice just got a job offer from a company that she's been trying to get a job with for a while, but unfortunately, the new job is going to require her and her husband Jeff to move. One good aspect of this is that the company will allow Alice to choose between any of the 9 cities where this company has this particular position available.

Jeff and Alice have two young children that are about to start elementary school in a couple of years, and they don't want to keep moving around once the kids start school. It's really important for them to choose a city that has great schools as well as great job prospects for the future, for both Alice and Jeff. Because Jeff is a teacher, he's not too concerned about being able to find a job, as long as the school districts in the area are typically hiring, which is usually the case if an area's population is increasing.

Jeff bought the issue of Money magazine that comes out every year showing the best cities to live in. Buying the magazine also gave Jeff free access to the online version of the article and accompanying data, but Jeff and Alice were quickly frustrated with how much data there was to keep track of. Both the magazine and the online data just gave table after table of data for each city, and it was really hard to find, re-find, and keep track of the information most important to them.

Jeff heard about a new system you can use to compare cities to live in, and it seems like not only a quicker way, but also a more fun way to figure this all out, at least compared to having to sift through all of that online magazine data. Jeff and Alice go down to the public library to try out this new system.

Alice selects the nine cities that she is allowed to choose from and can see what types of data are available to use. Jeff sees that different types of data are available to help compare the cities Alice has selected. Out of all of the available data they decide to use school information, job growth, and housing information because those seem to be the ones that matter the most. They figure they can look at other things like crime rate and the availability of parks and entertainment later once they've whittled down the list of cities to just a few.

Jeff selects the data about schools, housing, and predicted job growth from the overall set of data available and they see that even each of these sets of data contains further subsets they can use to compare cities.

Even though Jeff and Alice already have a few favorites in mind, they decide to start off by comparing all nine cities that Alice can choose from. Based on the type of data that Jeff has chosen, the system recommends a few ways to visually compare the data. Jeff chooses a [bar graph] because it looks like something he's seen before, and Alice isn't as comfortable with charts and graphs anyway.

The system shows how each city compares across the three sets of data they've selected, schools, jobs, and housing. The comparison is showing the information sorted based on the order that Jeff selected the information in the first place. Because housing was selected first, it is currently used to sort the data, but they care more about schools. Jeff rearranges the order so that schools are most important, then housing, and then finally jobs. The system now shows the information that makes it easier to compare the cities based on Jeff's arrangement.

With this information so clear, they can easily see that there are about three cities that stand out as the best options. Alice reduces the number of cities being looked to these three and creates a summary of the information in a format that they can use to discuss the options."

 

An important aspect of the scenario is that you can't tell what technology the system uses...you don't see any specific mention of mouse clicks, finger taps on a touchscreen, etc; the focus is on what the couple is accomplishing, not on a given technical solution. This allows you to make sure you have represented what users really care about before committing to any specific solutions.

And if we take just a snippet of this scenario, we can see how initial high level requirements can be derived from it:

"The system shows how each city compares across the three sets of data they've selected, schools, jobs, and housing. The comparison is showing the information sorted based on the order that Jeff selected the information in the first place. Because housing was selected first, it is currently used to sort the data, but they care more about schools. Jeff rearranges the order so that schools are most important, then housing, and then finally jobs... Alice reduces the number of cities being looked to these three and creates a summary of the information in a format that they can use to discuss the options."

...could lead to the following requirements:

• 1. Ability to compare multiple cities at the same time.
• 2. Default sorting of data based on the order the user selected the data.
• 3. Ability to rearrange the sort order of the selected data.
• 4. Ability to change (add, remove) selected cities during city comparisons, without disturbing the comparison parameters selected.

Now the goal would be to use these requirements to drive the design process. By using scenarios to derive requirements, you will have more confidence about why a given feature has been designed...because it supports a requirement that comes from a clear understanding of the user's situation.

So, the next time someone on your team says "hey, I just saw Microsoft's new XYZ tool and I think we should put that in the product...," you can respond with "Can you show me which of our agreed upon scenarios this supports?"