Chapter 12
Prototyping and Evaluation of Menu Selection Systems
After following all of the guidelines, incorporating a cognitive theory of control, and involving the users in the clustering of menus, the designer still has to see if it flies. It is too easy to miss the obvious, forget the fundamentals, and overlook the inconsistencies. Published guidelines and research results take us a long way toward good design. However, they can never close the gap between generalization and application. Isa, Ogden, and Wolfe (1986) note, "The only way that an interface can be evaluated is through user testing of that particular implementation." (p. 69). One must prototype the system and evaluate the result. Prototyping is cost effective to the extent that it is rapid, easy, and provides informative results. Prototypes vary from simple paper mockups or story boarding to full blown implementations. The fidelity of the prototype to the final system is of great concern. The type of computer screen and keyboard layout may be critical while system timing may not be. Prototyping provides the opportunity to discover flaws while it is still possible to change the design. Issues and examples of prototyping menu selection systems will be presented in this chapter.
Prototyping must be supported by a careful analysis of the results. Analyses should be based on the measures presented in Table 1.1. Performance measures are important and have been emphasized in previous chapters. User evaluations are of particular importance in prototyping and will be stressed in this chapter. Evaluations of a system vary from open ended questions and informal comments to standardized questionnaires and performance measures. This chapter will consider issues in user evaluation and present several approaches.
Prototyping is not a new idea, and its place in the life cycle of a system is extremely important. But for prototyping to be useful in the development of a computer system, it must be relatively fast and easy to implement and change. Menu selection systems are particularly good candidates for prototyping since it should be easy to change them without greatly affecting the rest of the software. For that matter, when complete fidelity is not required, it is often possible to prototype only the menus without any further program functionality. This is particularly the case with videotext, bibliographic, database, and help systems.
Prototyping a menu selection system requires an initial idea of three major aspects of the system: (a) the menu structure (composed of the selectable items and clustering), (b) screen layout (composed of graphics and text supporting the menu items), and (c) screen-to-screen transitions (composed of input and output dynamics). The menu structure can be prototyped as a database of items and often drawn as a network or hierarchical graph.. Alternative structures can be compared in terms of depth and breadth and expected access times for items of different frequency. Screen layout can be drawn either on paper or on the screen itself. Alternative layouts can be compared side-by-side. The entire set of screens completes the static prototype of the system. However, screen-to-screen transitions which require user input must be prototyped in a dynamic emulating environment. Figure 12.1 outlines the three levels of prototyping associated with the three aspects of menu selection systems: structure, layout, and dynamics.
Prototyping should be done at the structural and layout level using the tools of graphs and storyboarding. However, it is essential in the final analysis to prototype the dynamic system at least at a superficial level. Dynamic prototyping can be done in the native programing language of the destination system. However, it is generally better to use a rapid prototyping system or a system that supports user interface management. Prototyping efforts suffer when menus are written into the program code rather than in a separate driver with an easily modifiable file of menus. Without a separation of the menu driver from the rest of the program code, programs have to be revised and recompiled for each change in the menu. The advantage of current user interface management systems is that they allow the designer to modify menus and menu organization at the same time without necessarily changing the functionality of the program. Changes to screens, additions of items, and links can be made more or less on-the-fly.
For menu prototyping to be cost effective, the system must allow fast and easy implementation and revision. It should provide an authoring system that allow the designer to generate the structure, screen layout and dynamics in a quick and simple format.
Dynamic prototyping can be done on a fully functional system using a user interface management system (UIMS) or on just the "front end" of the system using a menu driver or a UIMS that presents the menus to the user but may not necessarily access actual functions that have been selected.
One of the earliest experimental systems capable of prototyping menus at the dynamic level was ZOG first begun in 1972 (Akscyn & McCracken, 1984). The ZOG system and its predecessor KMS use the basic constructs of frames and links. Frames are screen sized workspaces (see Figure 12.2). Links relate individual items in a frame to other frames.
In recent years user interface management systems (UIMS), windowing systems, and specialized menu drivers have have facilitated the rapid prototyping of menu selection systems. Examples of commercial packages include HyperCard(TM), X-Windows(TM), and NeWS(TM) and a host of hypermedia and hypertext systems (Smith & Weiss, 1988).
The one thing that most dynamic prototyping systems lack is an experimental testing and evaluation environment. Systems should be able to emulate real world tasks and record performance. Without this ability prototypes provide no measurable or quantifiable means of evaluation.
One system, the Menu Selection Prototyping System (MSPS) developed at the University of Maryland (Norman, 1984; Norman, Mantel, & Wallace, 1988), is a menu driver that can be used to (a) prototype menu systems, (b) emulate task environments, and (c) record the behavior of the users and the system. MSPS works by accessing a source file containing the menu system. The file consists of a set of menu frames with directives. Each frame consists of a screen display and a set of allowable response options with associated pointers to other frames or to procedures (see Figure 12.3). Certain frames in the file can be used to present tasks to the user. The tasks generally involve accessing particular target items or series of items. Other frames can be used to check for successful completion of tasks and to provide feedback. The file also contains a set of timer values to simulate system response time (interval between the user response and the presentation of the next menu frame) and time out intervals (maximum time between presentation of a menu frame and the user response).
The MSPS writes a journal file in which records each frame presented, the response option selected, and the user response time (interval between presentation of the frame and the user response). These data allow analyses on
* user response time per screen or item
* user response time to perform overall tasks
* selection errors per screen or item
* selection errors in performing a task
* frequency of access to menu items
* patterns and co-occurrences of menu selections.
These data can be analyzed to determine problem areas in the menu system: (a) items which may be misinterpreted, (b) high frequency items that should be made more accessible, and (c) the need for reorganizing or reclustering items. MSPS has been used in various versions since 1983 in a number of laboratory studies as the experimental workbench for menu research.
Finally, it should be added that usability testing of prototypes should also be supported by video, verbal protocols, and subjective evaluation. Video taping captures user access to auxiliary material (manuals, forms, notes, etc.), vacillation between alternatives, and signs of confusion and/or frustration that cannot be captured using software. Verbal protocols capture the step-by-step thought processes involved in performing a task. They may reveal the need for addition menu items, paths, and user guidance. User evaluation and reaction to the prototype is important and is addressed in the next section.
12.2 Guidelines for Menu Design
At some point it necessary to bridge the gap between the theory and research of menu selection on the one hand and the direct application of results to real problems on the other. The translation of theory and results into guidelines and standards is necessary so that software designers have a target to aim for. Standards and guidelines documents provide a concise summary that aid in the development of human/computer interfaces. Several standards and guidelines documents have been produced in the area of human/computer interaction (e.g., Smith & Mosier, 1986; MIL-STD-1472C, 1981). These documents have helped to avoid catastrophic problems as well as minor frustrations that user have with the interface and at the same time facilitate performance.
There are, however, a number of dangers in setting forth such documents. The specification of guidelines and standards are always suspect due to the problems of generalizability and applicability discussed in Chapter 5.
First, it is possible that a standard or guideline has resulted from theory or research results that do not generalize beyond the specific assumptions of the theory or the conditions of the study. Such a standard or guideline may be irrelevant or simply wrong. Additional research is required to clear up such problems.
Second, standards and guidelines may be incorrectly interpreted and/or incorrectly applied by designers. It is too easy to read a standard or guideline at only the superficial level without having a deeper understanding of its intent, implications, and limitations. Without such understanding, standards and guidelines may be applied in a way never intended by their originator. The application of a guideline is often an issue of interpretation, and the conformance to a standard is often an issue of degree. Consequently, the blind application of guidelines can be a major problem.
Third, standards and guidelines documents generally do not address the problem of importance or tradeoffs of design options. Some standards and guidelines are essential; others are of minor importance. While all of the standards and guidelines may promote principles of good design, some will have little impact on performance and user evaluation of the system. Consequently, designers need to prioritize standards and guidelines. Furthermore, a number of standards and guidelines interact. The application of one may limit the application of another. Designers need to be aware of such tradeoffs and must be able to strike the right balance between them.
Fourth, the application of guidelines and the conformance to standards is often a matter of opinion or expert evaluation. Some guidelines are objective in the sense that it is clear whether a system meets the guideline or not (e.g., "Items in a list should be left-justified.") Other guidelines define metrics that can be objectively empirically assessed and either set criteria to be passed or optimized (e.g., such as by measuring performance). Others are judgment calls and depend on the subjective metrics of an evaluator (e.g., " Items should be given meaningful labels.")
Finally, standards and guidelines may overly restrict the design space, preclude innovative solutions to problems, and lead a premature standardization on less than optimal designs. The problem is that theory, research, and technology are still moving targets. Standards and guidelines cannot be considered as final documents, only as current iterations.
With these problems accepted as caviots and disclaimers, Appendix A is offered as a checklist for menu design. The checklist is presented as a series of questions that should help designers to make sure that they have addressed as many aspects of menu design as possible. The items were intentionally written in a general form without specifying a specific design option but rather encouraging consideration of design issues. Each item has cross reference to a section in the text to allow the reader to gain a deeper understanding of the issue. When reviewing a system, designers should go through the list and check off whether or not each item has been satisfactorily meet.
Evaluation of a prototype cannot rest totally on designers and experts. It is important to solicit input from the user community itself. Experts cannot always be trusted to represent the best interests of the users. A study by Lee, Whalen, McEwen, & Latremouille (1984) confirms this admonition. They had experts design the top index page for an electronic shopping and information retrieval system. A second group of experts ranked the menus produced by the first group for ease of use. Virtually no correlation was found between the rankings of the experts (r = .08). However, when a group of representative users ranked the menus there was high agreement among them as to which menus would be easier to use (r = .49). Furthermore, performance measures were highly correlated with user predictions (r = .72). Users were the best judges of menu design and best predictors of future performance.
Certainly it behooves the designer to consider seriously evaluation of systems by users. The questions is "How?" It is an easy thing to make up a few questions and solicit ratings from users. It is not so easy to validate the subjective measures and interpret the results relative to known user populations. Although a number of questionnaires have been developed to measure subjective satisfaction with computer systems, few have focused on the user interface. Those that have been developed have been highly specific to particular systems, limited in their application across different systems and users, and limited to one shot experiments rather than refined over a number of applications. Reviews of these questionnaires have been critical and have cited the problems of (a) lack of validity (Gallagher, 1974), (b) low reliability, (Larcker & Lessig, 1980; Ives, Olson, & Baroudi, 1983), (c) insufficient sample sizes, and (d) nonrepresentative populations (Bailey & Pearson, 1983).
12.3.1 Standardized User Evaluation of Interactive Systems. What has been needed has been a generic questionnaire, developed and applied over a number of applications, standardized on a wide variety of users, with proven reliability and validity. Shneiderman (1987) originally proposed a "generic user evaluation questionnaire for interactive systems" with the idea that interactive systems share a set aspects that can be assessed relative to one another. Furthermore, each aspect can be broken down into more and more specific aspects.
This questionnaire, now called the Questionnaire for User Interaction Satisfaction (QUIS) has been repeatedly used, refined, and validated over a number of studies (Chin, Diehl, & Norman, 1988; Chin, Norman, & Shneiderman, 1987). The current version of the QUIS measures six aspects of the user's overall reaction to the system and 21 system attributes (see Figure 12.4). The system attributes are clustered into four major categories: the screen, terminology and system information, learning, and system capabilities. In addition, the QUIS includes indicator variables supporting the 21 system attributes. The QUIS is hierarchically organized so that the ratings of the indicator variables impact upward on the system attributes, which in turn impact the overall user reactions (see Figure 12.5). This approach to psychological scaling is rather novel since it involves a hierarchical model rather than merely a set of independent scales. The hierarchical structure reflects the model of both the inherent structure of the system and the way in which users organize their attitudes about the system. Consequently, items in the QUIS have been organized according to a hierarchical format.
Several version of the QUIS have been developed. The long version is shown in Figure 12.4. A short version has been used extensively that omits the indicator variables and greatly reduces the number of items to be rated. Both paper and pencil and online versions exist.
|Click Here for Information on the QUIS|
The generality of the QUIS was developed by having different user populations evaluate different systems using the questionnaire. Additional sections have always been added to the QUIS to characterize the user and the software being evaluation. Users included (a) undergraduate students, (b) computer professionals, (c) computer hobbyists, and (d) novice users. Systems have included (a) programming environments, (b) bibliographic retrieval systems, (c) disk operating systems, and (d) word processors. Furthermore, the conditions under which the questionnaire was administered have varied considerably. Conditions included have (a) strictly controlled laboratory studies in which subjects were exposed to systems for a short time, (b) less rigorous studies in which subjects used systems on a more or less casual basis, and (c) field studies in which conditions and demands varied widely. Over repeated applications items and scales were revised and reworded to produce a more robust version.
The reliability of the QUIS was established by measuring the intercorrelation among items. Cronbach's alpha, which quantitatively measures reliability on a 0 to 1 scale, was consistently in the .89 to .94 range over a series of studies. Thus, the overall reliability of the QUIS is quite high.
The validity of the QUIS was measured in two ways. Internal validity was established by substantiating the hypothesized hierarchical organization of the QUIS. Ratings on indicator items were correlated with higher level system attributes and system attributes were correlated with overall ratings of satisfaction. Data over several studies both supported the hierarchical structure as a whole and helped to eliminate inconsistent items.
External validity was established by using the QUIS to compare different systems. For example, in one study (Chin, Diehl, & Norman, 1988) users were asked to rate one system that they liked and one that they disliked. All of the overall reactions to the system differed greatly between the liked and disliked systems, except for the difficult vs. easy rating. It is probable that the difficulty in using a system depends more on the functionality of the program rather than on satisfaction with it. System attributes having to do with learning (operating, exploring, and performing tasks in a straight forward manner) and system capabilities (speed, reliability, correcting mistakes, considering experience of users) also differed between liked and disliked systems. In another part of that study a comparison was made between a command line system (MS-DOS(TM)) and menu driven applications (e.g., WordStar(TM), Lotus(TM), DBase(TM), etc.). Again, all of the overall reactions to the system differed greatly between the two types of systems, except for the difficult vs. easy rating. The menu driven applications were rated much more favorably. Furthermore, 18 of the 21 system attributes were rated more favorably for the menu systems. These results lend strong support to the external validity of the QUIS.
Finally, the diagnostic power of the QUIS to detect problem areas has been confirmed by a usability study of a menu system for home control (Wallace & Norman, 1988). The system was not being compared to an alternative so no differences could be obtained. However, items scoring exceptionally high or low relative to the mean of all the responses helped to reveal the strengths and weaknesses of the system. The QUIS indicated that like many commercial systems, home control by menu selection was perceived as wonderful and satisfying but rigid with inadequate power. In addition, particular items indicated that additional system feedback and user guidance was needed.
The QUIS has proven to be useful as a generic instrument for assessing interactive systems. As such it taps a number of system attributes related to menu selection. The system attributes of particular relevance to menus systems are
* Organization of information on screen
* Sequence screens
* Use of terms throughout the system
* Messages on the screen which prompt user for input
* Tasks can be performed in a straight-forward manner
However, there are additional attributes specific to menu selection that need to be assessed. These are addressed in the next section.
12.3.2 Evaluation of Menu Selection. Few studies have specifically investigated ratings of menu selection systems or attributes that specifically pertain to menu selection. Recently, Norman (1988a) described five basic factors along which menu systems can vary. These factors attempt to capture the basic dimensions of menu systems that users are sensitive to and are described to users as follows:
Display and Response Time. Systems vary in terms of how long it takes for the menu to be displayed on the screen and how long it takes for the system to respond once an item has been selected. A very poor system keeps the user waiting; whereas, a very good system displays the menu quickly and implements the selection quickly.
Path Efficiency. Systems vary in terms of the efficiency of the path to the goal. Very poor systems appear to lead one along an endless garden path; whereas, a very good system quickly home in on the goal and does not ask for redundant or irrelevant input.
Clarity of Menus. Systems vary in terms of the clarity vs. vagueness of the choice and the particular alternatives. In a very poor system it may not be clear what sort of choice is being made and what the options denote. This may be because of the brevity of the menu or poor wording. In a very good system, the user knows the implications of each choice and he know what each option does.
Sense of Direction Toward Goal. Systems vary in terms of the sense of movement in the direction of the goal. In a very poor system users may get lost in the maze and not know whether they are getting closer or further from the goal. In a very good system, users have a sense of control and accomplishment as they progress.
Recovery from Errors. Systems vary in terms of their capability of allowing the user to recover from errors easily and quickly. A very poor system is "unforgiving." If a wrong choice is made it takes considerable time and effort to restart or return to the point of error. In a very good system, the user can quickly undo the error and start where the error had occurred.
Users are asked to rate how good or poor the system is on each of the five factors. Each rating is made on a line mark scale as shown in figure 12.6. Users are instructed to make their mark toward the left end of the line marked "very poor" to the extent that they dislike the system and toward the right end marked "very good" to the extent that they like the system.
Norman (1988) reports rating data on 229 users. Three different menu systems were evaluated: (1) a hierarchical organization of 256 items in a merchandising catalog, (2) a prototype of a popular time sharing system, and (3) an online card catalog. In addition, a number of computer science students rated various menu systems that they were familiar with. Figure 12.7 shows the profiles for these four groups by plotting the mean ratings on the 5 menu factors.
Both the merchandising catalog and time sharing system received the highest ratings for display and response time and recovery from errors. Both of the these systems had very fast response times and allowed the users to backup the tree or move immediately to the top with one command. Path efficiency was rated lower on both systems. Both of these menus were 4 levels deep. and users made frequent path errors when searching for targets. Furthermore, the wording of these menus left much to be desired as indicated by the low ratings on clarity of menus and sense of direction toward goal. The group rating the online card catalog gave much lower rating for response and display time and recovery from errors. Finally, the group rating a variety of familiar systems showed a similar pattern, except that response and display time was much superior.
These results indicate that the menu rating scales are able to diagnose the weaknesses and strengths of systems. Users seemed particularly positive about fast response times and the ability to recover from errors in some systems. None of the systems fared particularly well in terms of path efficiency, clarity of menus, or sense of direction toward the goal.
Users were also asked to rate the menu systems on 5 combinations of two factors at a time as well as to rate the systems overall as shown in Figure 12.6. These ratings were needed to test the internal reliability of the ratings and also to assess the relative importance of the five menu factors. It was expected that a rating on the combination of display and response time and clarity of menus would depend on the ratings of the single factors and that the ratings of the combinations would lean in the direction of the most important factor of the two. A factor analysis was conducted to determine how the menu factors and combinations loaded on the extracted factors. Table 12.1 shows the factor loadings for a varimax solution.
Table 12.1
Factor Analysis of 5 Factors Using the Varimax Procedure
| Rating Scale | Factor 1 | Factor 2 | Factor 3 | Factor 4 | Factor 5 |
|---|---|---|---|---|---|
| Time | 0.93 | ||||
| Path Efficiency | 0.27 | 0.83 | 0.37 | ||
| Clarity | 0.90 | ||||
| Direction | 0.43 | 0.84 | |||
| Recovery | 0.24 | 0.88 | |||
| T X C | 0.55 | 0.72 | |||
| P X R | 0.54 | 0.30 | 0.68 | ||
| C X D | 0.78 | 0.40 | |||
| D X R | 0.26 | 0.46 | 0.38 | 0.65 | |
| R X C | 0.26 | 0.74 | 0.46 | ||
| P X T | 0.70 | 0.38 | 0.36 | 0.22 | 0.68 |
| Overall | 0.31 | 0.34 | 0.66 | 0.30 | 0.24 |
It can be seen that each of the five menu factors loads highly on one factor. These factors basically correspond to the 5 menu factors that were initially rated. Ratings of the combinations of factors tend to load highly on the two factors composing the combination. This result supports the idea that the ratings were reliable and reflect the underlying factors. Moreover, the loadings on the combinations reveal something about the relative importance of the 5 factors to the users. Whenever clarity was one of the factors in the combination, it tended to load most highly, indicating that ratings were most affected by this factor. Furthermore, the overall rating of the systems loaded most highly on the factor corresponding to clarity. Clarity was the most important factor to the users.
As a general finding, these results suggest that menu prototyping and evaluation should concentrate on the wording of menus. Each menu and each menu alternative should be evaluated and changed based on its clarity and meaningfulness to the user.
12.3.3 Menu-by-Menu Evaluations. The wording of menu alternatives is often an agonizing chore to designers. The questions are: What do we call this function? What do we call this group of functions? Language is limited; terms are ambiguous; and consistency an unachievable ideal. Much of the problem is that naming is best done by the knowledgeable user rather than the omniscient designer. It is interesting that in the Genesis account of creation, Adam (the user) was given the task of naming the animals (Genesis 2:19-20). Whatever, he called them became their name. In a similar way, it might be suggested that users have an input to the names of menu alternatives because they are the ones who must call them by name. While no current systems make use of this feature, some user interface management systems allow the user to build their own menus or change the wording of existing menus. These features, however, are generally not for the novice user and require considerable knowledge of the system.
A more practical approach would be to start with an initial set of names for menu alternatives and let the users rate the suitability, clarity, and meaningfulness of the names and then enter suggested names or changes in wording. Thus, the users would have an of editorial role in producing the menu system. Ratings can be used to evaluate a number of aspects of menu frames as well as the traversal of those frames. Listed below are four different types of ratings that can be used in a menu-by-menu evaluation. Each type of rating is illustrated in Figure 12.8.
Ratings of Individual Terms. Given a particular menu, users can be asked to rate the meaningfulness, explicitness, and familiarity of parts of the menu. For example, they could be asked to rate the meaningfulness of the choice: "Select the type of registration:" and their familiarity with the items: "passive, "passive-fixed", "dynamic." The ratings will be a function of both the subject matter knowledge of the user as well as the clarity and specificity of the passages. One would expect large differences between experienced and novice users; however, well-written menus may help to attenuate differences by educating novice users as to the meaning of the alternatives.
Ratings of Prior Probabilities. Given a target function or object to be located in the menu structure, users can be asked, "What is the probability that you will find the target given that you select Alternative i? These ratings assess the subjective probability that a particular path leads to the goal. To the extent that the probability is high on the correct alternative, the menu conveys the proper expectations to the user of where paths lead.
Norman & Chin (1988) used these sorts of ratings in a pilot study to test the comparability of different menus used in their experiment on the effect of menu structure. Subjects were shown a target item and the first frame in the menu tree. They rated the probability that each alternative would lead to the target with the restriction that the probabilities sum to one. The subject was informed of the correct choice, moved to the next menu along the path, and asked to rate the probabilities for alternatives at the next level. This continued until the target was one of the menu items. These data helped to diagnose poorly worded menu frames and particularly hard to find targets.
Ratings of Screen Layout . Users can be asked to rate the way in which menus are displayed on the screen. These ratings should include (a) how well organized the items are, (b) how meaningful and useful the organization is to the user, (c) how easy it is to locate desired items on the screen, and (d) how confusing or cluttered the screen appears. Screen layout is highly subjective issue and should follow the principles of artistic design as well as. Additional ratings might include artistic aspects such as (a) balance, (b)
Ratings of the Screen-to-Screen Transitions. The way in which a system moves from screen to screen can create either an impression of discontinuity or of graceful progress. Discontinuity can occur when transitions are abrupt either visually or in terms of context. Some screen transitions seem to inch along by conveying too small a sense of change. Such an impression can frustrate the user. Other transitions may seem to move to a new galaxy in that they move too far with no sense of context or continuity. Users can rate screen-to-screen in terms of (a) step size, (b) sense of progress, (c) smoothness, and (d) maintenance of a sense of context.
To rate all of the above aspects of all screens on even a small system might be excessive. Fortunately, most real world systems use only a limited number of screen layouts and types of transitions. Meaningfulness of terms and probability ratings, however, may pose a problem if the menu includes a large number of items and is hierarchical. One possibility would be to rate only a sampling of the total number. Alternatively, users could be given the capability of annotating items or features of menus that were particularly problematic. Nevertheless, menu-by-menu ratings should prove extremely useful in evaluating prototypes of menu selection systems and should be a standard part of usability testing.
Prototyping is an essential element in design and evaluation. Prototyping of menu selection systems should allow for quick and easily modifiable mockups. More and more software tools and user interface management systems make it possible to alter the human/computer interface more or less independently from the application program underneath. However, few systems support an experimental workbench for prototype evaluation by generating tasks and monitoring user performance. MSPS, however, is one system that does and has been successfully used in a number of studies.
Prototyping must be supported by user evaluation. While user satisfaction has been acknowledged as important, empirically tested instruments to assess user evaluation have been lacking. The QUIS was developed and tested over a number of studies to fill that need. The QUIS provides both ratings of overall satisfaction and ratings of specific system attributes that help to diagnose the strengths and weaknesses of the system. Other scales have been developed to assess factors more directly related to menu selection. These reveal that the most important factor of design from the user's standpoint is clarity of the menu items. Finally, menu systems should be subjected to menu-by-menu evaluations by users. Embedded ratings scales provide a tool for user feedback.
Prototyping and evaluation is essential in the design of menu selection. To many, the design of a menu selection system seems to be a trivial process of merely specifying the items and writing menu frames. Prototyping and user evaluation may seem superfluous. On the contrary, menu design is neither trivial or obvious. Designers can only make informed guesses. The initial design must be prototyped and iterated several times in response to user evaluation.
[Homepage][Previous Chapter]