Previous Table of Contents Next


Compared to detailed object representations, the information presented on the screens and its organization was far more crucial to learning and efficient use; users formed a (mental) model of the system based on the screen titles, layout, and content of fields and widgets. Furthermore, users commented that the graphics for such objects occupied precious screen space that could be better used for displaying important information. An efficient and effective organization of and access to user tasks is critical, i.e., the effort expended is focused on efficient task organization, and within a task, on efficient object organization. Essentially, this is an issue of navigation and screen organization, which depends to some degree on the technologies and tools employed.

It is also helpful to identify where and how the metaphor will be used, irrespective of how it is represented on the screen (by words or pictures). For example, a metaphor may work well for novice users but may be perceived as superfluous by experienced users. A metaphor may be used explicitly in documentation and training material and implicitly on the screen itself. The presentation of the metaphor may also influence users. For example, for one application, the initial cartoon-style presentation of a metaphor suggested that this was not a “serious” application. When the presentation style was changed to elegant drawings, users found it acceptable and helpful.

For a metaphor to be successful, it must be consistent with existing metaphors used in the workplace (see Section 3.3), it should be sustainable throughout the user interface, it should be able to accommodate exception and error conditions, and it should be extendible as new tasks are learned or created (these are the criteria for evaluating metaphors during the design sessions described above). It is essential to understand the user’s initial (mental) model of the current application (see Section 3.3) and then build on that understanding with the appropriate metaphor. If the functionality of the application is “new” (i.e., unfamiliar to the users) it is helpful to understand the analogies or models users employ to make sense of the “new” functionality. This happens in legacy system redesign when new functionality is introduced (as an extension) that users have not encountered before or where new functionality is provided to support or enforce the new way of doing business. Design of a metaphor is particularly challenging when the malfunctions analysis of the COTS software revealed critical or serious malfunctions in the COTS system model.

For example, the XYZ Finance & Insurance Company introduced functionality to explain and illustrate its financial and insurance instruments to the customer. The current user’s model (discovered in the malfunction analysis) consisted of the application form metaphor for collecting and analysing customer data and the contract metaphor for the sales documentation. Users deemed the metaphor of a slide show appropriate for the explanations and illustrations. These could be customized with individual customer data, consistent with the concept of customizing slides, and they could be printed for the customer to keep.

The choice of appropriate metaphors for an application is the most challenging and most far-reaching user interface design decision on any project. It is also the most enjoyable part of any project. The author’s experience has been that metaphors are best generated by a joint working group of user interface designers, users, and business and systems analysts. Brainstorming techniques, the usability engineering tool kit (see Section 2.3), the design room (see Section 2.4), and copious amounts of chocolate, cookies and coffee, and/or pizza and beer are helpful. There is no well-defined process for generating metaphors. It is best to start with the metaphor of the current application or the COTS software (see Sections 3.3 and 3.4) and to examine carefully how well it fits with the new task definitions (see Section 4.1).

An iterative design approach with user testing is essential to the design of the metaphor to ensure that the final metaphor matches the user’s model. If users form a model different from that conveyed through the metaphor, then they will very likely not be able to use the functionality as intended.

The metaphor is documented as part of the User Interface Architecture (see Section 5) and posted in the usability engineering room. In fire prevention assignments, sufficient resources should be allocated to this project task. In firefighting assignments where time is of the essence, it is best to rely on the results of the malfunction analysis and adopt a metaphor based on the user’s model of the current application rather than spending time exploring other metaphors.


Previous Table of Contents Next