London Web Design & SEO Services

What is a scenario?

A scenario is a short story about a specific user with a specific goal at your site. Scenarios are the questions, tasks, and stories that users bring to your Web site and that your Web site must satisfy.

When should you use scenarios?

Scenarios are critical both for designing Web sites and for doing usability testing.

For designing Web sites: Of course, you can’t write down every scenario that every user will have, but if you write down 10 to 30 of the most common scenarios before you start to put the site together, you’ll find yourself focusing on users and their tasks rather than on your organization and its internal structure. You’ll know what content the site must have and which pieces of content must be easiest to find and understand.

In a usability test, you can ask users for their own scenarios. Why would they come to your site? What do they want to do? Or you can give users scenarios to do.

This article focuses on pre-design scenarios. See the article on Create Final Scenarios for more about scenarios in usability testing.

How detailed should a scenario be?

Scenarios come at different levels of detail.

• Goal- or task-based scenarios in which you state only what the user wants to do. Scenarios at this level do not include any information on how the user goes about completing the scenario.
  • Example: A parent who is worried about a ten-year old refusing to drink milk wants to know if it really makes a difference that the child is getting very little calcium.
  • Example: You are traveling to Seattle for your job next week and you want to check on the amount you can be reimbursed for meals and other expenses.

  Scenarios at this level should drive your site architecture and content. This is also the type of scenario that you give users in a usability test. It gives them a reason and a goal for going to the site but it lets them show you how they would use the site to accomplish that goal.

• Elaborated scenarios in which you give more details of the users’ stories. Scenarios at this level give the Web development team a deeper understanding of the users. With that deeper understanding of what is important to users, of users’ motivations and fears, and of users’ ways of working, the team is more likely to develop the right content at the right level so that users find it comfortable and easy to work with.
  • Example: Mr. and Mrs. Macomb are retired schoolteachers who are now in their 70’s. Their Social Security checks are an important part of their income. They’ve just sold their big house and moved to a small apartment. They know that one of the many chores they need to do now is to tell the Social Security Administration that they have moved. They don’t know where the nearest Social Security office is and it’s getting harder for them to do a lot of walking or driving, so they would like to do this on the computer if it is easy and safe enough. However, they are somewhat nervous about doing a task like this by computer. They never used computers in their jobs; but their son, Steve, gave them a computer last year, set it up for them, and showed them how to use email and how to go to Web sites. They have never been to the Social Security Administration’s Web site, so they don’t know how it is organized. Also, they are reluctant to give out personal information on Web sites, so they want to know how safe it is to tell the agency about their new address this way.

Full-scale, task scenarios that include the steps to accomplish the task. A full-scale scenario can either report all the steps that a specific user takes today to accomplish the task, or it can describe the steps you plan to set up for users in the new site. Scenarios at this level are very similar to Use Cases, but they lay out the steps from the user’s point of view rather than from the Web site’s point of view. They explain how the site supports the goal-oriented scenarios that you started with.

How do you gather scenarios?

You can get scenarios for your Web site from many sources, including these:

• Questions users ask through contact links or through a question-asking-and answering-application if your Web site uses one
• Questions users ask and stories they tell people who answer phones in your agency or group
• Surveys (Online)
• Contextual Interviews
• Individual Interviews

Next steps

When you have your user and task analysis, personas, and scenarios, you are ready to Set Measurable Usability Goals.

What is a persona?

A persona is a fictional person who represents a major user group for your site.

How do we get information for a persona?

By analyzing what you learned about your users from user research, including:

• Contextual Interviews
• Individual Interviews
• Surveys (Online)
• Focus Groups
• Usability Testing

Using this information, you identify major user groups of your Web site. You then select the characteristics that are most representative of that group and turn them into a persona.

What does a persona look like?

A persona typically includes a fictional name and characteristics that are consistent with one of the main user groups you have identified.

The following example is only a small portion of a larger persona developed by the U.S. Department of Agriculture’s (USDA) Economic Research Service (ERS).

Persona developed by the U.S. Department of Agriculture’s (USDA) Economic Research Service (ERS).

What characteristics are included in a persona?

A persona usually includes:

• a name and picture
• demographics (age, education, ethnicity, family status)
• job title and major responsibilities
• goals and tasks in relation to your site
• environment (physical, social, technological)
• a quote that sums up what matters most to the persona with relevance for your site

How do we select a name and photo?

You make up the persona’s name. Select one that resonates with the team as representing that user group. Be relevant and serious; humor usually is not appropriate here.

For a picture, you can buy or license stock photography, although a more casual photo often resonates more with development teams. Don’t make it a picture of someone the team knows. Make sure you have permission for the photo that you use. You can tell that you have a good picture if the team sees it and says “Oh, yes, that would be Jim, the Press Guy” or “Oh, yes, that’s just what I see when I think of Rebecca, the Program Officer.”

What are the benefits of personas?

Personas bring many benefits, including these:

• Users’ goals and needs become a common point of focus for the team.
• The team can concentrate on designing for a manageable set of personas knowing that they represent the needs of many users.
• By always asking, “Would Jim use this?” the team can avoid the trap of building what users ask for rather than what they will actually use.
• Design efforts can be prioritized based on the personas.
• Disagreements over design decisions can be sorted out by referring back to the personas.
• Designs can be constantly evaluated against the personas, getting better designs into usability testing.

According to Forrester, many companies including Ford Motor Company, Microsoft, and Staples develop and use personas and they report many benefits from doing so, including:

• a better understanding of customers
• shorter design cycles
• improved product quality

Next steps

In addition to developing personas, you should use your Task Analysis to Write Scenarios.