Usability Testing
This appendix lists guidelines you can check off during usability testing. If your company has usability test plans, you might want to add use cases that test whether the application follows these guidelines.
Data Input
All labels are understood by a majority of users.
Links are underlined. Nonlinks are not underlined.
Links use standard colors to indicate whether a link was followed (pink) or not (blue).
Actions or commands are initiated with button controls, not links.
Jumps to informational pages are indicated with links, not buttons.
Background colors are white, black, blues, greens, or yellows. Color usage is appropriate for human physiology (no red on blue, for example) and for color-blind individuals.
Icons and pictures use ALT text descriptors.
Required fields are indicated in some way, and the indicator is understood by the majority of users. Defaults are supplied whenever possible.
Fields that are required need to be required. Fields that are not necessary for the activity of the application are not required.
Note: Majority should be defined during early design sessions and checked during test-design sessions. However, 80 percent is usually a reasonable cutoff point. Keep in mind that user profiles (novice versus experienced users) also affect the levels.
Data Retrieval
The sophistication and complexity of the application’s Search, Filter, and Browse options are appropriate for the types of applications, users, and workflows.
The approach—search filter, browsing—is appropriate for the user population and the task.
On a complex search or filter in a frame, the command buttons appear at the bottom of the frame or in a position separated from the entry areas themselves.
The search entry area and button are highly visible.
All labels are understood by a majority of users.
Links are underlined. Nonlinks are not underlined.
Links use standard colors to indicate whether a link was followed (pink) or not (blue).
Background colors are white, black, blues, greens, or yellows. Color usage is appropriate for human physiology (no red on blue, for example) and for color-blind individuals.
Data Output
Test whether users need to compare products or records. If the answer is yes, provide methods for allowing comparisons.
Find out what makes novice report users become expert users. In other words, what makes someone decide to create ad hoc queries or change
report formats? If necessary, change the documentation and training to promote the change from novice to expert.
If users are having trouble formatting reports, consider offering wizards in addition to palettes or design environments. But make sure there is a nonwizard path and options for more experienced users.
Track usage of and changes to preformatted reports; incorporate the best changes into the default versions. Eliminate underused reports.
Find out if users need to share report formats as well as the generated reports. If the answer is yes, provide a secure method for posting, validating, and sharing the most useful formats.
Graphs
Obviousness: Are the goals of the graph apparent? For example, if the graph is supposed to highlight out-of-range data points, can users spot them immediately? Is the title too generic—can the users recognize the use or contents of the graph from the title?
Affordances: Do the users recognize the graph type. If so, does it help them understand the data more easily?
Heuristics: Do experts agree that you’ve formatted the data correctly? Check with people with expertise in statistics and mathematics.
Many industries and business domains have specialized types of graphs. As well as developing lists of subject-matter expert reviewers, collect standard reference works and textbooks in the domain for which you’re developing graphs. Expect expert users such as stockbrokers and doctors to be visually literate and to prefer windows full of complex graphs and charts. Check the designs against the standards.
Different cultures have different levels of visual literacy. Unlike mass-audience U.S. readers, for example, Japanese readers expect and can understand highly complex pictures, charts, and graphs (Kohl et al. 1993, pp. 63–73). If you expect to internationalize your applications, check all graphical and data-analysis requirements with your international experts and marketing departments.
Mechanical: Users often prefer to see preformatted graphs as their first experience with a graph program. Later, if they need to, they can fine-tune the display. Have you made it easy for the user to get an interesting
Diagrams
Obviousness: Are the goals of the diagram apparent?
Affordances: Do the users recognize the diagram type. If so, does it help them understand the situation more easily?
Heuristics: Do experts agree that you’ve formatted the data correctly? Check with people with expertise in the relevant domains.
Many industries and business domains have specialized types of diagrams. As well as developing lists of subject-matter expert reviewers, collect standard reference works and textbooks in the domain for which you’re developing diagrams. Check the designs against the standards.
Different cultures have different levels of visual literacy. Unlike mass-audience U.S. readers, for example, Japanese readers expect and can understand highly complex pictures (Kohl et al. 1993, pp. 63–73). If you expect to internationalize your applications, check all graphical and data-analysis requirements with your international experts and marketing departments.
Mechanical: Users often prefer to see preformatted diagrams as their first experience with a diagramming program. Later, if they need to, they can fine-tune the display. Have you made it easy for the user to get an interesting diagram the first time he or she uses the application(perhaps with a wizard, if the display or data are complex)?
Visualizations
Users must have a running story of what the data is trying to tell them as they move through each step of inquiry. They need to understand what parts of the picture tell what aspect of the story. Then they have to fit their progressive intentions for subsets into this picture. When users experienced errors in progressive complex queries, they tended to correct them by backing up almost tc the start of their querying in order to shift from thinking formalistically to pictorially (Barbara Mirel 1999, p. 6).
Even though visualization is at least as old as the cave paintings in Lascaux, France—30,000 years old1—the usability of maps, graphs, diagrams, and three-dimensional images or environments is not as well defined as that of other software elements, like buttons, windows, online help, and so on. However, researchers have identified a few of the usability problems characteristic of visualizations. When designing programs, test your solutions against the guidelines in Table C-1.
1See “The Cave of Lascaux“ at http://www.culture.fr/culture/arcnat/lascaux/en/.