- He asks the customer for her name and information, including the ship-to address, and adds this customer info into the order.
- He reads her the final price with tax and asks her for her credit card number. She reads it to him over the phone while he types it in directly.
- John asks how she'd like the order shipped and offers her a couple of options and the price for each. She chooses one.
- "Everything looks complete," John confirms. "We'll get these out today."
- John prints the sales order, walks over to the shelf, and pulls the headphones.
- He takes the order back to his shipping department to ship. The printed order has everything they need to prepare the shipping package and print the FedEx air bill.
Notice that sprinkled throughout the steps are the goals of the software's primary user and its secondary user, along with commentary that gives us an idea of how often this process occurs, how long it might take, and what's going on in the real world while the primary user is using the system. These things make the scenario tangible and memorable.
Try Writing Your Own Blockbuster
Pull together a group of people that includes end-users and those familiar with the features in scope. A group of three to five people is a good size. Start by discussing the hero of the story and the opening scene. Describe the person, the place, and the situation, and then proceed to describe the scene that plays out. Describe what actually happens; don't generalize.
As you discuss it, write the scenario out large on a whiteboard where everyone can see it. Revise and rewrite as necessary. Draw pictures that support the scenario if it helps. Try to write the scenario in such a way that it doesn't restrict any options in the user interface (UI).
When you're done and everyone feels comfortable that your scenario describes a believable, typical use of the software that leverages functionality in scope, then shoot a quick photo of the whiteboard to transcribe later.
A lot of good things happen when you write a scenario. Those implementing the software clearly understand the context of use--where the user is and the kinds of features that need to be in the software to help him succeed. The reader can sense how fast the system might need to respond to be useful to its user.
Scenarios offer an excellent starting point for building and validating a low-fidelity UI prototype. A UI prototype set to a user scenario is referred to as a storyboard. Scenarios also make good tests. Once the system is built, we can validate that scenarios like this work smoothly in the finished system.
There are caveats to using scenarios. It's tempting to engage in creative writing that doesn't accurately reflect the type of users using the system or the situations they commonly engage in. At times the scenario can draw attention to a detail that is actually insignificant.
The next time you're neck deep in a pile of features to design and build but you're not sure that you're building something your users can use, consider writing a couple of user scenarios. Tie all the features together in a way that helps you and your users feel more confident that the software really addresses their problems.
- "Usability Engineering: Scenario-Based Development of Human Computer Interaction" by John M. Carroll and Mary Beth Rosson
- "About Face 2.0" by Alan Cooper and Robert M. Reiman