The use scenario may be the most important artifact of the requirements document. They go by many names depending on your company’s nomenclature: goals, tasks, usage cases, whatever. The use scenario provides the details of the question “what is the customer attempting to accomplish?” Or said another way “Explain the entire experience from beginning to end.”
I have a personal blog–updated information about what’s happening with me, my family, and especially my son’s band The Alternate Routes. I use the blog to update my extended family and friends without having to send emails to all of them. I frequently want to post a picture in the blog, which shouldn’t be hard but actually is. Here’s what I used to do: resize and copy the desired picture to a shared folder on my Mac that was synchronized with my .Mac account on the web; then I would link to the picture in my public folder which actually involved using an undocumented URL. It was convoluted but easy enough once I figured out how to do it. I later found that I could accomplish the same thing a little more easily via Flickr but it was still rather convoluted. Nowadays I add the picture to my photo program, which can export to Google’s PicasaWeb. Then I click on Embed and PicasaWeb generates the HTML necessary to incorporate the photo into a blog post. Photo resizing, transfer to web, and code-links are all easily done in three steps. If I managed the blog with iWeb (which I don’t for other reasons), it’s even simpler: drag and drop the picture onto a placeholder. That’s it.
What I’ve been describing are all of the individual tasks necessary to achieve my goal: I want to include a photo in a blog post. Use scenarios explain “Steve wants to have a photo in his blog post.” Or perhaps “Steve has taken a dozen pictures of the winter storm. He wants to put one of those pictures on his blog with a link to the collection of pictures.”
Instead of saying “the user might want to do” this or that, a use scenario is a specific, illustrative situation. And thus, keeps us from the edge cases of the implausible and from the vagueness of non-specific.
The American Cancer Society defined their use scenarios extremely well; they followed the transaction from the beginning to the end. My office made a donation recently in memory of a family member. The American Cancer Society sent me a notification in the mail and included a ready-to-use Thank You card with a return envelope. Beautiful. Think this through. After a funeral, the bereaved family gets dozens, perhaps hundreds, of memorial gifts. As with a wedding, etiquette requires that you acknowledge the gift. But while a wedding is a period of great anticipated joy, a death usually is not anticipated and certainly not joyful. While the wedding bride may not be completely thrilled with writing hundreds of thank-you notes, a bereaved family after a funeral must dread it. The American Cancer Society has made it simpler to pen a short note and get it in the mail without all the drudgery of addressing the envelope. They looked at the gift from the standpoint of the ‘customer’ and the customer’s usage. After the giver or ‘buyer’ transaction was complete, they also helped the receiver or ‘user’ with their part of the transaction.
We get so caught up with tasks that we miss the goal; we get some involved with buyers that we often forget the user. What is your customer trying to accomplish? Write some use scenarios from their point of view and from beginning to end, and you’ll be delighted with the outcome.