Context-Rich Scenarios Make UX Projects Manageable

by Jared M. Spool

Imagine we’re working to improve the customer service reservation system for a major international hotel chain. Here’s a scenario we started with:

Angelique, a successful salesperson whose region is in the Western US, has an existing reservation for next week at the Denver property to attend the company’s annual sales meeting. She’s decided to spend an additional two days visiting Denver-area customers, so she needs to extend her stay.

She calls the Platinum customer service number. The system routes her to Eduardo (an 18-year call center veteran), and brings up her account information and next week’s existing reservation automatically on his screen.

When Angelique asks for the 2-day extension to her reservation, Eduardo notes that the hotel is fully-booked because of another event coming in, but that event’s reserved block isn’t completely allocated.

With Angelique still on the phone, Eduardo contacts the property’s event manager and receives permission to transfer the room from the block to Angelique. He also arranges it so she won’t have to change rooms mid-week.

In Scenarios, Every Detail Must Matter

When we create scenarios like this one with our clients, we’re careful to make sure every detail we describe is important to some aspect of the design. For example, we listed two personas, Angelique the salesperson with a Platinum loyalty card (which means she spends a minimum of 75 nights a year in our hotels) and Eduardo the long-term customer service agent.

Knowing that Angelique is a Platinum customer means that Eduardo’s mission is to go to practically any length to make her stays perfect. By identifying Eduardo as working in the call center for 18 years, we’re telling the team that he’s experienced and has survived major reservation system redesigns, including that revision two years ago that was a complete UX disaster (almost causing a walkout). We’ll need to make sure that our new features are easy for Eduardo, so he can do whatever is necessary to make Angelique happy.

It’s important to also note what’s not called out in this scenario. For example, there’s no persona for the Denver hotel’s event manager because we’re not working on the design of that person’s interface, though that could come in a future design initiative. If it’s not important to a decision we’re facing in our current design project, then we leave it out of the scenario. This keeps the scenarios short and focused.

The Formula for Behavior: User + Design + Context

As designers, our medium is behavior. Three elements manipulate the outcome of using our designs: the user, the design itself, and the context. We can keep two of these the same, but if the third one changes, then the behavioral outcome is likely to change too.

For example, if we kept Angelique’s situation the same and had the same design, but Eduardo was a brand new customer service representative, then he might not know to check the event’s block allocation or contact the property manager. If we kept the same design and Eduardo the same, but changed Angelique’s extension request to a family vacation where she needs an additional room for her kids, then we need to deal with getting an adjoining room for the extra days.

Teams are usually pretty good at cataloging the design differences and the user differences. Where they get into trouble is with changing contexts.

For any sophisticated design challenges, there are usually a large number of variations in contexts, which can be overwhelming. Some are very important to the success of the design and some are edge conditions that happen rarely and won’t make or break the project’s success. Identifying which is which becomes the big challenge for the team.

Picking Out the Happy Path

The Happy Path is the user’s simplest path to success, guaranteeing happiness. It should be obvious every step of the way and have the least number of steps. Nailing the Happy Path is critical. If we don’t get that right, every other use of our design will be worse.

To identify the Happy Path, we want to simplify all the contextual variables. For the hotel stay extension scenario, that might mean removing any complications from the new event coming into the hotel. If the Denver property has plenty of room for the extra days, then extending Angelique’s stay should be simple for Eduardo.

How many clicks and how much time should that Happy Path scenario take? How much can we shorten it? That’s what we need to focus on first.

We like to work on the Happy Path scenario first, before everything gets complicated. When we present our designs to others in the organization, we like to start by walking through the Happy Path. Since we’ve done a good job at making it super simple, it’s fast and easy, setting the stage for the complexity we’re about to introduce.

Enumerating Variations in Contexts

Once we’ve clearly identified our Happy Path scenario, we start to work collecting variations in the contexts.

What if she needs to put the extra two nights on a different credit card because the sales meeting will only cover the first three nights?

What if a coworker is joining Angelique for the two extra days, but not going to the Sales meeting at the beginning of the week, and Angelique wants both rooms billed together?

What if Angelique isn’t visiting clients, but taking a family vacation with her husband and two pre-teen children? (This implies a need for a king bed instead of double beds in her room adjoining another room for the kids. This complicates Eduardo’s desire to save her from having to change rooms mid-stay.)

What if Angelique needs to travel down to Colorado Springs the fourth day, but wants to return to the Denver hotel on the fifth?

Each of these variations are simple changes to the original scenario. Each one implies functionality in the design that we might have to include. The question becomes, which are within the scope of our current project and which ones should we leave out for later?

Driving Priorities by Researching Scenarios

We’ve found that once we have the variations listed out, it’s easier to put together a research project to determine how often each one occurs. In this example, a simple diary study or interviewing customer service representatives could quickly yield frequency data. Having reps keep a tally sheet on when certain contexts occur could be helpful. Even asking seasoned reps, “Does this scenario happen often?” can give a good first estimation.

When we know what the high-frequency variations are, we can come up with a threshold for including them in the project’s scope. Maybe we only work on those variations that happen more than once per hundred calls? Or are likely to happen every day?

But we shouldn’t stop there. Sometimes, there are variations that are strategically important that don’t happen very often.

To identify which of those variations should be within the project’s scope, we can often use a KJ Analysis. When we’re done, we’ll have surfaced the most critical infrequent contexts to include in the current project.

By starting with a context-rich scenario, identifying the Happy Path, then enumerating the other variations, we can begin to see what a great user experience can be. Using research techniques to prioritize the context variations we’ll tackle first makes it all manageable. Manageable projects produce great results and you know how much we love producing great results.

Published here on August 8, 2012.