2. Web Usability Strategy
The author recommends a three-step process for creating a usable site or improving the usability of the existing one:
- Generate all realistic scenarios of use
- Specify interface objects and actions for given contexts
- Specify user actions from the wetware perspective ("userview")
Each concept is discussed in further detail in this chapter.
2.1 Scenarios
A "Scenario" answers four basic questions:
- Where and under what conditions will the Web site be used?
- For what purpose will the site be used?
- Who will use the site (the target audience)?
- How will the site be used?
There answer numerous possible scenarios when you consider the various answers to each of these questions in combination, though some combinations will be improbable.
2.2 Context
Scenarios define specific actions performed with the site (e.g., "The site is accessed from a library to do research by an elementary school student who will use the search engine to find matching news articles."). Once the various scenarios are enumerated, the next step is to consider how each scenario will play out given five levels of context:
- The environment context - Attributes of the physical location from which the user accesses the site
- The user context - Attributes of the user himself
- The genre context - Attributes of sites in the same category
- The site context - Attributes of the Web site, as a whole
- The page context - Attributes of each individual page a user visits to perform their task(s)
Design decisions made at higher levels supersede decisions made at any lower level. If we decide that the user is color blind (user context), this will preempt the use of certain colors to highlight content (page context).
2.3 The Userview Process
The "userview" process involves a series of tasks that will define a usable interface. Before getting into the tasks, the author provides some information on the underlying principles:
- User-centered approach. Consider each user's unique characteristics (level of expertise, cultural expectations, etc.)
- Human factors input. Consider the physical, behavioral, and cognitive capabilities of human beings.
- Iterative design. The design task is not once-and-done, but involves constant improvement.
- Continuous testing. As with iterative design, the performance is constantly measured and tested in various ways to identify areas where improvement is needed.
- Integrated design. A bit hazy, but it seems to consider how a single task requires multiple interfaces, which should be considered as parts of this process rather than isolated elements of the site.
2.3.1 Goals and Requirements
Each Web site development project begins with a goal in mind - but importantly, this goal is derived from the needs and interests of the prospective user - not the site owner. From the owner's perspective, they choose which goals they are willing to fulfill, based on their perceived interest in helping the user achieve them.
It seems a bit like doublespeak, but a focusing on a site that helps users purchase books will ultimately attract more customers than a site focused on helping a company to sell books. The priorities must be aligned with those of the user in order to succeed in helping the user fulfill their needs, and profitability for the company is a result of successfully empowering the user.
Functional requirements are therefore defined from the user's perspective - what must be provided to enable the user to accomplish their goal. The more clear, complete, and unambiguous, the easier the following tasks (defining how to meet those requirements) will be to achieve.
A second set of "nonfunctional" requirements may arise that set constraints and standards. For example, a fast response time isn't necessary to accomplishing a task, but it is nonetheless important to the user.
2.3.2 General Goals
General goals affect the operation of the Web site as if affects all users. Examples are providing consistent and reliable information, being easy to use, etc.
2.3.3 User-Specific Goals
User-specific goals serve the needs of specific individuals or user groups. Not all users have the same goals, so the site must meet a myriad of different goals, some of which may be in conflict with one another.
2.3.4 Functional Requirements
Functional requirements describe the full set of actions the site must provide for users to accomplish their goals (note that not every action is used by every user). Each requirement should begin with "The user must be able to _____," then go on to describe the action in detail.
2.3.5 Nonfunctional Requirements
Nonfunctional requirements provide constraints and qualifications - e.g., the site should be accessible via cell phone.
2.3.5.1 Requirements Document Structure
He suggests the following structure for a requirements document:
- Introduction: a general overview of the site, stressing its high-level goals and strategic objectives
- Web site model: Provides a model of the site (duch) - I suppose he means an outline or UI diagram.
- Functional requirements: the complete set of functional requirements
- Hardware: the necessary hardware and interfaces to systems
- Information structure: The navigation structure of the site
- Nonfunctional requirements: See 2.3.5 below
- Maintenance: Describe the nature of maintenance (both content and hardware) the site will require
- Glossary - Definition of terms
- Index - A quick-reference guide, possibly in multiple formats.
2.3.5.2 Requirements Table
He suggests using a tabular layout, with functional requirements listed in rows, and the user groups they affect listed in columns.
2.3.6 User Culture
A short statement that the users' culture is important, with a promise that it will be detailed later (chapter 12)
2.3.7 Audience
The audience for a site should be defined in detail so that the site can be designed for their use (rather than the site owner's or designer's individual preferences). More detail on this in chapter 4
2.3.8 Environment
The environment (palce where the user will access the site) is also worth considering. Details forthcoming in chapter 3.
2.3.9 Task Analysis
This is defined as the process of decomposing functions into tasks and subtasks the user will perform on the site. There is no analysis at this point, merely an objective dissection of the task.
2.3.10 Task Identification
Task identification examines the way in which people perform similar tasks in other environments (comparing the way one locates merchandise in a store or catalog to the way it is found on a Web site). This seems to be differentiated from task analysis (above) in that it is more involved with the "what" and "why" of a task than the "how" it is performed.
The author suggests that natural observation (observing real people performing a real task in a real environment) would be the preferred method. He doesn't mention the value of laboratory experimentation or interviews, but the issues with those two methods are fairly obvious - at yet, they may be necessary where natural observation is not possible or feasible.
2.3.11 Task Structuring
The information on task analysis (multiple analyses of different tasks) can be arranged in a tree structure, representing the different choices made by individuals at different points.
2.3.12 The Users' Task Representation Analysis
By looking at the task structuring, the sequence of steps in which users are likely to perform a task can be ascertained (no details on how, but it occurs to me that the "tree" structure could be annotated with percentages).
It is also possible to define metaphors for common practices. For example, the task of assembling a collection of items for purchase online can be described as placing items in a shopping cart, and this mental model carried forward and extended.
EN: The author seems focused on analyzing the way things are actually done, without an eye toward where a designer might alter a task to make it more efficient. I think I get the reason - a usable site accommodates natural behavior and does not make people change the way they act - but by the same token, it would seem wise to analyze tasks with an eye toward helping people do things better (more efficiently or accurately, with a better experience).
2.3.13 Web Interface Guidelines Specialization
The author mentions that design guidelines are published in various places. He suggests that they come from psychological research, conventional practices, and the consensus of experts ...
EN: I think this is a bit idealistic (many "guidelines" are the baseless opinions of amateurs, or the misapplication of research conducted in other media). Finding reliable sources, and examining the evidence upon which their recommendations are based, is essential.
Moreover, he author suggests these guidelines are "an important first step" to take, but the iterative design process (measuring performance, identifying problem areas) will lead a designer to deviate from general guidance to do that which is best for his specific users and site.
2.3.14 Constructing Storyboards
The author advocates "storyboards," with an example that shows the way the user can navigate from page to page. However, the example is pretty facile, showing a site that has a neat hierarchical content layout and showing only the flow from the home page "down" to a specific content topic.
2.3.15 Metaphor Design
EN: The author begins with "Web technology is still relatively new," and suggests that the majority of users draw upon meatspace experience when approaching the Web. This seems a bit dated, but is arguably worthwhile to consider when designing a site that involves new tasks, not previously done online. Even so, it seems to me a better alternative would be extending the users' online experience and drawing upon conventions learned in performing other tasks.
The author uses "metaphor" in the literary sense. If an online process seems to be analogous to a real-world process, it may be possible to use the real-world process as a metaphor. He relies on the shopping cart metaphor a lot, as it's in widespread use as well as the computer GUI as a metaphor of items in a physical office (files, folders, trash can) - not a single metaphor, but a set of related ones. EN: I can't think of any others that have caught on.
A bad metaphor is worse than no metaphor at all, as it will mislead and confuse the user. Also, a metaphoric representation can be encumbering, if following the metaphor conflicts with ease-of-use for accomplishing tasks.
EN: The desktop is a good example of a cumbersome metaphor - expert users often go to the prompt to do their work efficiently, or develop scripts to take care of tasks that are difficult or time-consuming to accomplish via the GUI interface.