Feature Specifications ("Specs") at Microsoft often start with a scenarios section. These 1-3 scenarios should explain what the feature is and why the feature is important to the customer.

In this post, I'm going to explain how I write scenarios.

Some comments:

  • A future post will define feature more clearly.
  • For an example of a feature, I'll use the the Batch Save Wizard in Microsoft PhotoDraw 2000 V2. I was the Program Manager for that feature and it was the first non-trivial UI I ever helped design.

Imagine, you have a newly-minted PM. He might write the following text as a Scenario:

User selects File / Batch Save Wizard form the menu. The wizard launches. The user picks where the source files are, where to put the destination files, and then any options for resizing the pictures. He clicks Finish and the wizard does its thing. Then when the wizard is finished with the batch save the user clicks Close and the wizard goes away.

This is a terribly-written Scenario

It may be technically accurate or grammatically correct. But, it has failed as a scenario.

Why?

  • It isn't End-to-End. Where did the process start for our user? Did the user spontaneously get the idea to click on this menu item? Is the user really finished? This scenario is unfortunately nothing more than a click-by-click set of steps.
  • It doesn't clarify the value of the feature to the user. What was the user trying to accomplish? How did the feature deliver that value. Sometimes the value is phrased as a user's intention or a reduction in pain. As written, this scenario doesn't address any of it.

A better example:

"The user just took a lot of pictures (hundreds) on vacation with his digital camera. He wants to put them all on his website. Well, the pictures are just too big, they don't fit on his web pages correctly and they take up too much file space on his website. He could do this manually in PhotoDraw by opening and resizing each picture. This will take him hours. He wishes there was a way to just tell Photodraw to just make them all the same size and have PhotoDraw do the hard work. So, while playing around with the File menu he sees and then launches Photodraw's Batch Save Wizard. He tells the wizard where the original pictures are and where to put the new ones and he chooses to make them all fit into 1024x768. When the wizard finishes, he opens his "My Documents" folder and he has all his photos resized. He can now copy them to his web site. We saved him many hours of really-boring work."

Key points about the re-written scenario:

  • The user's motivation is much more clear. You know more about how he arrived at this step.
  • The pain is obvious: hours of repetetive work
  • The feature is clear: it's the wizard
  • The benefit is clear: pain is minimized. hours of work went to minutes of work
  • The scenario is more "end-to-end".
  • And finally ... it reveals that we need to think more about this scenario and the feature. A reader is much more likely to provide useful feedback on this scenario because, for example, he can tell that this wizard only addressed part of the pain. Maybe we should cut the the feature because it is not useful enough in this scenario? 

It's not perfect. But it's much more useful. Someone reading the specification can provide better feedback when the spec frames the feature with a such scenario.

A framework for coming up with scenarios

I formulate scenarios by asking and answering 4 questions.

  • What is the user's pain in the user's words?
  • What is the user's need in the user's words?
  • What is the the thing you are building (the feature)?
  • How does the feature address the need?

I learned this technique during one of our many reviews with a VP. It's worked extremely well for me and I always suggest this technique to other program managers.

Saveen Reddy

2005-09-26