Previous Table of Contents Next


Whatever the data defining the represented world, or the derived mediating abstractions, the representing world will have its own constraints. In Figure 3.1 the lower middle box shows these constraints as the grammar of the representing world. While the designer can expand the realm of possible components from which they choose, even these new components typically fall within some general paradigm, such as defined in the visual graphical user interface. Expanding the possible grammars of user interaction (e.g., looking beyond direct manipulation or adding gesture to the repertoire of means of manipulation) is an important topic in human computer interaction design, since any chosen paradigm has its own particular affordances with regard to the aspects of the represented world that can be included or the facility of the end user to access those aspects.

3. REPRESENTATIONS IN DESIGN: DECISIONS AND TRANSFORMATION

The rationale for user-centered design is that research shows continuous and iterative inclusion of end user information is the best way to create useful and usable products (Landauer, 1995). The previous section argued that user-centered design requires mediating information be generated and applied in the creation of the representing world within the representational system. The purpose of this section is to outline one process for realizing a concrete design and show how facilitating the systematic transformation among the different representations is the raison d’être for useful process steps.

The discussion that follows covers design work for a system management application for monitoring hardware and software processing resources typically functioning as servers within a corporate computing environment. The application was distributed and could be used to monitor resources in a single site, worldwide or in between. It also was intended to support proactive and reactive automation of operations. The time scope of the work was about 1 year, although the majority of the user interface design covered about 3 months (post contextual inquiries). The development team consisted of about 15 software engineers, supported by a usability engineer working about half time on this project.

The next section describes the overall process. The example pertains to one aspect of the product and was one of numerous design problems.

3.1. PROCESS OVERVIE

This project used an iterative design process through which alternative user interface designs and system behaviors were tested and refined in the course of product development. This means that the “gap” was not bridged once, but rather was bridged incrementally as the design was refined. User-centered analysis was the starting point for design, but feedback from users on that analysis, on intermediate approximations of the concrete design rendered as storyboards, prototypes, and ultimately on the product itself informed the final concrete design. Thus, repeated interactions with end users shaped decisions about both the form of the representing world and the correspondences between it and the represented world. Figure 3.2 shows the steps of iterative process used for testing approximations of the concrete design.


Figure 3.2  Iterative design — spanning the gap in increments.

At the center of the figure is the end user. At the top of the figure the square-labeled scenarios and use cases represent the initial user data. The scenario information also described the work environment, education, and experience of end users and their existing tools. The other three squares are types of artifacts used to capture the concrete design at different stages in its evolution. User feedback was gathered on storyboards (sequences of paper screen designs arranged as flows, serving as a paper prototype), software prototypes, and the actual product.

The methods used to gather user feedback changed as the rendering of the design changed, but they consistently linked to the originating scenario and use-case data. Figure 3.3 shows for this project where the scenarios provided content and structure for other steps in the interface design and testing process.


Figure 3.3  Use cases and scenarios provide data for many design steps.

The use cases had corresponding usability goals, usually defined in measurable terms such as time to complete an operation or number of errors. The use cases also provided a high level definition of the important system interactions, especially since user-case structure defined related operations. Finally, the use cases were executed as test tasks, using storyboards, a prototype, and in testing field test versions of the product.

Thus, by combining an iterative design approach with the appropriate description of the represented world, it is possible to shape the design and the design process with end user information. The concrete design is derived from content of the analysis and modified in accord with ongoing feedback. The process (e.g., setting usability goals and test tasks and then testing via the storyboard walkthroughs and prototype testing) is linked to the same analysis. The user-centered analysis can be augmented as well during the design cycle (e.g., new use cases may emerge as users note how their work is being changed by the application itself).

3.2. VIEWING THE MANAGED RESOURCES: THE OPERATOR’S WINDOW ONTO THE WORLD

In design a good deal of the work is detailed examination of the results of user-centered analysis, extraction of key information, and laborious development of correspondences between the data and the elements of the representing world. The ability to recognize recurrent patterns in end user data and to manipulate the possibilities of the representing world (e.g., knowing the grammar and style or idioms) is developed with practice. The following subsections use the definition of the main application window as a case study to elaborate on the process overview provided above. Figure 3.4 gives an overview of this case study within the diagram for a representational system. The four squares show the elements of the system described earlier, but now labeled with the instances of information from this case study. Each element is explained below.


Figure 3.4  Example case study elements in a representational system.


Previous Table of Contents Next