To begin your entire web design process, begin by defining your audience. Who do you hope and expect to be visiting your web site? Define this as precisely as possible. This audience specification can be used for recruiting potential users for surveys and user testing, so the demographics should be clear enough to reproduce accurately.
Define age, gender, income, education, occupation, computer experience, and anything else that would affect who you would recruit and how they would use your web site.
After your first brush at defining your audience, you need to do research on what your audience is really like and what they need.
You can find statistics about your users from a wide variety of marketing resources including the Census Bureau, industry analyses, and online surveys.
If the information is not available, you’ll want to conduct your own surveys and user interviews. Even when information is available, you’ll often need to develop a more detailed understanding of your users.
This is especially true when you have a very specific, target audience with specialized skills or interests, such as when you’re developing intranet or extranet applications.
Why is it so important to talk to users at this stage?
After all, we’ll be conducting user testing later on. Early discussions with users are helpful because it’s common to learn at this point that your assumptions about your users are wrong. You may learn that you’ve targeted the wrong market.
You may learn that user are or are not worried about their security and anonymity, significantly affecting the entire structure of your application.
Perhaps they’re prepared for one payment model but absolutely reject another. The types of information you learn may radically alter your plan.
Learning this information at a later stage can involve substantial and costly reengineering to fix, if it’s even possible to backtrack at that point.
In understanding your target audience, you not only need to understand specific personal attributes, you also must understand what types of computers and software they’re using – that is the target platform.
There are differences in user preference settings, and international differences. Beyond differences in people, there are hardware and software differences in the areas of operating systems, monitors, browsers, and networks.
A good way to get started is to write down specifically who you believe your target audience is. A scenario is an approach for clarifying exactly who these people are.
Scenarios
Your web site needs to work for somebody if it’s going to work for anybody. The goal of a scenario is to make sure the site is not merely theoretically usable, but that it actually serves the needs of specific people in real life.
You do this by describing how your web site will be used by specific individuals in specific circumstances.
This helps make sure you’ve considered the small details necessary for actually accomplishing real tasks with your system.
It also ensures that you’ve considered the design in context, in the way that it relates to the lifestyle and work environment of your users.
For instance, by carefully considering the needs of a home user who may want to buy a product from your site, you realize that the home user is not likely to call an 800 number to order the product because the user probably has only one phone line, which is currently being used to access the Internet.
A scenario brings additional functional requirements and ideas for the user interface that are driven by user profiles and context – ideas you wouldn’t have thought of from an abstract consideration of the design.
A scenario also provides a rationale for design decisions that can be useful in presenting designs to the development team or to decision makers.
Keeping scenarios posted on your wall during web site development helps ground your work by holding the development in focus and personalizing the design as you grapple with how your decisions will impact specific people.
It’s convenient during a design debate to be able to say, “You know, I think Bryce would prefer if the web site worked like this.”
Typically you need three to four scenarios as a good starting point to cover the standard users of a web site, though many more may be needed if your site has a diverse audience with very different needs.
For example, the post office might not need very many scenarios because the number of common tasks on such a site is relatively limited; by contract, a federal government portal would require numerous scenarios to cover a wide variety of needs.
Whenever possible, you should validate the scenarios by asking the users they represent to review each scenario.
Three Parts of a Scenario
The typical scenario has three parts: a profile of the user, a schedule and interaction episode, and a sketch or photo of the user in the setting in which the web site is used.
In profiling the user, it is best to describe a specific person.
You can base this profile on an actual user you’ve encountered during interviews (but protect his or her confidentiality if the profile will be shared outside the design team). Give the person a name.
Describe all of the demographics: age, occupation, gender, education, family, hobbies, disabilities, type of computer and network used.
If you’re basing this on discussions with a real user, include information about his or her browser settings, feelings about online privacy, and design tastes. This user profile is also sometimes called a persona.
The schedule and interaction episode describes how your users work each day. What are their work hours? Do they carpool? When do they use their computers? How do interactions with friends, family, and co-workers influence their use of the web site? Describe what they do with the web site and why it’s important to them.
If you can’t think off a convincing reason why they would use your web site versus engaging in some other activity, then they probably wouldn’t.
This part of the scenario addresses the users’ motivations, and real life problems that determine their priorities.
In addition to working out a typical day, you should include some relevant exceptions: infrequent events, emergencies, special times that involve using the web site, or special problems that may occur on the site (such as dealing with a reject credit card).
A sketch or photo of the user in the setting in which the web site is used can helpful. While not strictly necessary, a ketch of the person in context helps remind you of factors you may otherwise overlook.
You can draw this by hand, compose it with clip art, use a photograph of an actual user you’ve visited, or use a photo clipped from a magazine.
Don’t worry about a well-drawn picture, just get a rough sketch that captures the type of person and his or work environment. Is the user’s desk cluttered?
Are other people around? Is it a noisy environment? What type of lighting is available? Are the user’s hands busy with work tasks that make keyboard use difficult? What tools does this person use?
When To Use Scenarios
Scenarios are a relatively inexpensive technique. They are most useful when grounded in actual data about real users based on surveys, interviews, focus groups, or observations of work environments.
Their utility is limited when you user populations is extremely diverse and you don’t have the time to generate enough scenarios to have good coverage.
They are most useful when the user’s work environment will have a big impact on the use of the web site – which will be true, for example, in many business-to-business transactional systems.