When developing user stories for new projects, I seem to run into the same problem. My team and I always start off strong. We put a lot of rigor into collaboratively arriving at a good set of user stories. Everyone feels pretty good about choosing the right stuff to build and the order in which to build it. But when we start building the story, it's hard to figure out how everything hangs together.

The Villain
As we start to build the functionality, the individual pieces look and work OK, but the software feels like "Frankenware"--lots of pieces stitched together into something that neither looks nor feels good. End users acknowledge that the software has all the features they prioritized as high, but there aren't enough features to do something useful with the software. This seems hard to believe, considering how long we've been adding features to the software, but sadly it's true. What we need is one big story that makes sense of all the little user stories.

The Hero
A user scenario was the big story we were looking for. It's a fairly simple; a narrative description of a person utilizing our software to successfully reach a goal. In the course of telling this story, the fictitious user (the hero) needs to leverage many of the features our software has in scope.

Let's look at an example. Say we're writing software for use in a retail environment. We're working on new order management software that allows customers to purchase items over the phone and pick them up later with the aid of a sales associate in the store. Some of our features in scope look like this:

• Create open order
• Identify customer and add to order
• Add products to order
• Add delivery information to order
• Add applicable sales tax to order
• Accept credit card payment over the phone

A user scenario of these features might go a bit like this:

John (our hero) works on the sales floor at Mega Electronics. Between helping customers in the store, he takes phone calls from customers asking for prices on specific items. John is paid on commission, so he wants to close every possible sale. If he can help the customers buy over the phone, that helps him, Mega Electronics, and maybe even the customers, since they may not need to visit the store to pick up their purchases. One of these business transactions might go as follows:

1. During a short break handling walk-in traffic, John answers a holding phone call. A woman asks him if he's got a particular brand of sound-deadening earphones.
2. John quickly looks up the earphones in the order entry system using the brand name and parts of the description. He tells her, "I've got two on hand."
3. "How much are they?" she asks. John reads the price from the screen, "We have them at $169.95." "Ouch," she says, "that's more than I thought they'd be."
4. John notices that on the screen near the description is a reference to recent good reviews and some prices from his competitors. He tells his customer about the reviews and lets her know his price is competitive. She says, "I'm rushing to get out of town and don't have time to shop around."
5. "I can set them aside for you, or if it would help, ship them to where you're going," John offers.
6. "Wow, that might be helpful. Could you ship them to my hotel?" asks the customer. John says, "No problem, let me get your details."
7. John clicks a button to turn the headphones item into a new sales order.
8. He asks the customer for her name and information, including the ship-to address, and adds this customer info into the order.
9. 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.
10. John asks how she'd like the order shipped and offers her a couple of options and the price for each. She chooses one.
11. "Everything looks complete," John confirms. "We'll get these out today."
12. John prints the sales order, walks over to the shelf, and pulls the headphones.
13. 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.

Happy Endings
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.

References:

• "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