You can get the Just Ask book from www.uiAccess.com/accessucd/print.html
Accessibility in User-Centered Design: Scenarios
Scenarios are created during Workflow Analysis, which is covered in the Accessibility in Analysis chapter. This section provides information on the following:
- Background: Scenarios in User-Centered Design (UCD)
- Including Accessibility Considerations in Scenarios
- Detailed Examples of Scenarios
Aspects of the examples that specifically relate to accessibility are highlighted, and surrounded by transparent images with alternative (ALT) text "start highlight" and "end highlight" for screen reader users and others who don't see images.
Background: Scenarios in User-Centered Design (UCD)
Scenarios, which are built on the information gathered in UCD Workflow Analysis, vary widely. Some focus on the functional level, while others provide task-level detail. "Use case" is used to mean many different things, and some types of use cases are very similar to scenarios as described here. Generally high-level scenarios are used in the Analysis phase for new products and more detailed-level scenarios are used later in design of new products and when redesigning existing products.
Just as personas are individual, fictional accounts of user group profile data, scenarios are individual, fictional accounts of workflow data. A scenario is a description of a persona using a product to achieve a goal. [1] Scenarios are usually narratives that tell a story describing one or more tasks in a specific environmental situation.
Developing scenarios often identifies important aspects of using a product in the real world that were not otherwise identified and considered; for example, that the workflow is likely to be disrupted by a phone call. Scenarios are useful throughout the design process, particularly in developing task descriptions for usability testing.
Scenarios can cover high-level product usage or can focus on detailed product interactions. A detailed scenario that includes specific user and product interactions might start out something like this:
Scenario #1: Changing an employee's job title
Hanna Reed-Smith, Human Resources Specialist, receives an email request to change Josh Anderson's job title from Personal Lines Analyst to Personal Lines Manager.
Action: She opens HRWeb and clicks on Search for Employee. Hanna then uses the task bar buttons to get back to her e-mail to get Josh's employee number from his e-mail message. She uses the mouse to highlight the number, copy it, go back to HR Web, paste the number in the
Employee IDfield, and activate the Search button. She clicks on Employment Information, and then is interrupted by a phone call.
- Hanna:
- This is Hanna in HR.
- Caller:
- I found an error on my vacation time listed on my last paycheck.
- Hanna:
- I can help you with that.
Including Accessibility Considerations in Scenarios
Scenarios that include accessibility provide details on how a persona in limiting conditions interacts with the product using adaptive strategies, often including assistive technology. Scenario developers usually observe several people with disabilities interacting with a previous version of the product or with other similar products to understand how people interact differently with the product under limiting conditions.
We found that many people didn't set up the software themselves. Often an assistive technology specialist would set up the software for a person with a disability. For seniors, it was common for their kids to set up the software for them. Therefore, we included a third person in our set up workflow.
As discussed in "Individual Differences" in the Analysis Phase chapter, including a note about the variability among people with disabilities helps designers remember variability among users. An example note is:
Remember that people are diverse. Be careful not to assume that all users, including users with disabilities, use your product the same way. People use different interaction techniques, different adaptive strategies, and different assistive technology configurations. People have different experiences, different expectations, and different preferences. This scenario is just one example of a user in this user group.
The following is an example of a scenario similar to the one above, with accessibility considerations included:
Scenario #1: Changing an employee's job title
Hanna Reed-Smith, Human Resources Specialist, receives an email request to change Josh Anderson's job title from Personal Lines Specialist to Personal Lines Analyst.
Her screen reader is running since Hanna opens that as soon as she boots her computer each morning.
Action: She opens HRWeb and tabs to Search for Employee. Hanna then uses the Alt+Tab to get back to her e-mail to get Josh's employee number from his e-mail message. She uses the keyboard to highlight the number, copy it, go back to HR Web, paste the number in the
Employee IDfield, and presses Enter to activate the Search button.
- Hanna:
- This is Hanna in HR.
- Caller:
- I found an error on my vacation time listed on my last paycheck.
- Hanna:
- I can help you with that.
Detailed Examples of Scenarios
The next section, Example Scenarios, provides more detailed examples of scenarios that include accessibility considerations.
References
- Cooper, A. The Inmates Are Running the Asylum. Indianapolis, Indiana: SAMS, Division of MacMillan Computer Publishing, 1999.
Some of information in this section was previously published in:
- Henry, S.L., Martinson, M.L., and Barnicle, K. Beyond Video: Accessibility Profiles, Personas, and Scenarios Up Close and Personal. Proceedings of UPA 2003 (Usability Professionals' Association annual conference), 2003.