Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

  • No labels