Scenarios

Owned by Daphne Ogle
Last updated: Jun 08, 2009Version comment
4 min read

Designing for scenarios

We want to design for real use.  Use cases are great for fleshing out requirements and understanding the extent of activities the system needs to support.  Scenarios help us understand the details of how we can better support users in meeting their goals.   Scenarios -- stories about users activities as they happen in context and relate to other activities -- define the way a user needs to complete an activity or string of activities, what information they already know and need to know, what mental models and expectations they already have in the space and how their context affects the way they get work done (e.g. frequent interruptions tell us the system needs to help users keeps track of where they are in a process).  Another way to think about them in regards to use cases is as specific instance of *likely* several use cases as they are linked together to get work done.

The ideal is to start with scenarios free of implementation details.  "Context scenarios" focus on the persona mental models, goals and activities.  In "About Face 3", Cooper et al, they also refer to these as "Day-in-the-Life Scenarios". 

Scenarios address questions like (Goodwin, 2002):

  • What is the setting in which the product is used?
  • Will it be used for extended amounts of time?
  • Is the persona frequently interrupted?
  • Are there multiple users on a single workstation/device?
  • What other products is it used with?
  • How much complexity is permissible, based on persona skill and frequency of use?
  • What primary activities does the persona need to accomplish to meet their goals?
  • What is the expected end result of using the product?

Example scenario

From Fluid Engage on mobile device interactivity in museums (written by Clayton Lewis):

Pat loves cats and is a regular visitor to the CATT museum. Pat can't read very well, but fortunately the CATT museum uses Fluid Engage technology. Pat has a profile online with an identity provider that supplies an information presentation preference profile that indicates that she prefers simplified language... this profile is not specific to Fluid Engage, but can be used by any compliant site that Pat visits on the Web.

Pat is given an RFID badge on entry to the museum. Because Pat is a member of the museum, her RFID badge number is also entered into her online account at the museum. Also at that time Pat  selects the Fluid Engage visitor app on her iPhone, and the app accesses the Fluid Engage visit registration site. (If Pat does not have an active session, the phone also establishes a session with the identity provider, so that sites Pat visits can obtain her information presentation preference profile.) The phone provides crude location information to Fluid Engage (it's indoors, but the phone can get a rough fix via wifi address), good enough to tell the site that Pat is at the CATT museum (the Fluid Engage site knows the location of the museum). Fluid Engage queries the CATT museum to get the number of the last issued badge, which is Pat's, and sends this badge number to Pat's phone.

Now Pat's phone knows Pat's RFID badge number, and can query the Fluid Engage site for location specific information for the badge, which is tracked by the location system in the museum.

When Pat approaches an exhibit that has audio commentary, the phone plays appropriate content, delivered in simple language, honoring Pat's information presentation preference profile. Pat does not have to operate any controls or find any control numbers to get the commentary for the exhibit, and she doesn't have to do anything to select commentary that is composed in a style that she can understand.

Pat particularly enjoys the exhibit on Lord Nelson's catts. The exhibit includes a mannequin representing Lord Nelson, with six catts on various parts of his person. As Pat approaches that exhibit she sees a "take photo" button, and her phone plays a message inviting her to stand in next to Lord Nelson and press that button. When she does so a picture of her, with Lord Nelson and the catts, appears on her phone, and is saved when she moves away from the exhibit.

When Pat returns home after her visit, and accesses the museum Web site, she is recognized as a member (because of id and password information stored on her home computer). Information about her visit, including the picture she took of herself with Lord Nelson and the catts, is available to her on the museum site. She can replay commentary about any of the exhibits, or hear commentary on exhibits she did not visit, by selecting a picture of the exhibit on a map of the museum on the site. Because the site accesses Pat's online identity, and  hence Pat's information presentation preferences, the version of the commentary and other information that Pat hears is appropriate to her.

This scenario is good because:

  • It is a good story - it's easy to envision Pat's experience 
  • It includes the details of Pat's experience without getting into implementation
  • Enough context and background are included to understand motivations for the experience - context matters and is included in this story