Milestone 5: Scenarios


Scenarios: are narratives describing foreseeable interactions of types of users (characters) and the system or between two software components. Scenarios are often used in usability research. They include information about goals, expectations, actions and reactions. Scenarios are neither predictions nor forecasts. (



The team began this milestone by reviewing our previous, non-product based, scenarios drafted during persona development in Milestone 3. Building upon our initial scenarios enabled us to maintain continuity with our previous work and give a basis to understand how our product may fit into a pre-existing life routine. Along with reworking our scenarios, we established and updated life goals for each persona and through the scenario design, attempted to demonstrate how those goals may be met.

Each team member was re-assigned their previous persona to further develop a scenario and goals. After a couple of group review and comment sessions on the scenarios we determined that our product will not fit every persona's needs. This effectively eliminated two of our previous personas (Ethel and Rita, an elderly woman and a bus driver) from further study.



We paid close attention to the persona goals in this milestone. The scenarios we developed are a hypothetical, yet realistic demonstration of how an average user may interact with our product to achieve both specific and vague life goals. While some of our goals are more directed towards transit needs, others are more broad and weakly linked to a transit decision tool. Our team felt it necessary to understand both the potentials and the limits of our product through this scenario analysis. Examining the limits of our product helps us to focus our product development on the core features users may need in order to achieve common goals.

Team members had some flexibility in determining the best way to represent the scenario. While some scenarios simply incorporated a product experience into the previously drafted scenarios, others show a two or three phase process to understand how our product may affect a persona's routines in a typical day. We found the diversity in our formats to be helpful in realizing routine changes a product user may encounter. This, in turn, assisted the team in designing the next user experience test: a mid-fi set of prototypes to accurately test user response.



Below are the scenarios and goals we created. Using these scenarios and goals we brainstormed ideas about how to best test the user response to our product experience without actually designing and creating a hi-fi prototype.

And the stories continue:


Next Steps

As the scenarios and goals exercise carried into the next round of mockups, our team tried to pinpoint the exact product experiences we are trying to understand and how best to capture them. We laid out a set of "user responses" that clearly indicate to us how well our product addresses user needs as well as our own goal to intervene before or during a transit decision and trigger user action. The user responses are listed below with a brief description of their application to our product:

  • Emotional Response: Test the user's emotional response to both the images and information we provide in the initial intervention (i.e. financial, environmental, community, health, and temporal). This emotional response is a pathway to draw the user into our product.
  • Logical Response: Test the user's logical response to the information and feature sets we provide in the next stage of product use (i.e. route finding, detailed transit comparison, community forums, route saving, etc.). This logical response indicates what kind of information is useful to the user as well as which feature sets connect together to enrich the user's experience.
  • Active Response: Test the user's active response to the decision-making tools we provide in the final stage of product use (i.e. transit comparator, mobile use, mapping, route selection, etc.). This active response measures how well our product actually triggers user action.