Dennis Wixon

User performance with command, menu, and iconic interfaces

Performance and subjective reactions of 76 users of varying levels of computer experience were measured with 7 different interfaces representing command, menu, and iconic interface styles. The results suggest three general conclusions:there are large usability differences between contemporary systems, there is no necessary tradeoff between ease of use and ease of learning, interface style is not related to performance or preference (but careful design is). Difficulties involving system feedback, input forms, help systems, and navigation aids occurred in all styles of interface: command, menu, and iconic. New interface technology did not solve old human factors problems.

Contextual design: an emergent view of system design

We offer an introduction to contextual design as an emergent method for building effective systems. Contextual design addresses a number of the inadequacies in previous methods by emphasizing: interview methods conducted in the context of the users work, codesigning with the user, building an understanding of work in context, and summarizing conclusions through out the research. We contrast this design method to usability engineering and artifact examination.

The Usability Engineering Framework for Product Design and Evaluation

Publisher Summary This chapter begins with the description of the usability engineering and then describes its origins. The chapter then structures a discussion around each of the steps involved in doing usability engineering. Usability engineering is a process for defining, measuring, and thereby improving the usability of products. Usability engineering evolved because of a need to move usability from the realm of personal opinion to an attribute that is quantifiable like other engineering attributes. Practitioners can use the definitions and examples as a basis for their work. The chapter discusses the issues and pitfalls that provide background for establishing, marketing, and refining a usability engineering process in a development organization. Notes for the theorist on the conceptual underpinnings of usability engineering and the interrelationships among usability engineering and other methods like contextual inquiry, inspections, and scenarios are provided throughout the chapter. Finally, the chapter lists the ways in which other design models and methods complement the usability engineering framework.

Making a difference—the impact of inspections

In this methodology paper we define a metric we call impact ratio. We use this ratio to measure the effectiveness of inspections and other evaluative techniques in getting usability improvements into products. We inspected ten commercial software products and achieved an average impact ratio of 78%. We discuss factors affecting this ratio and its value in helping us to appraise usability engineerings impact on products.

How do people really use text editors

Keystroke statistics were collected on editing systems while people performed their normal work. Knowledge workers used an experimental editor, and secretaries used a word processor. Results show a consistent picture of free use patterns in both settings. Of the total number of keystrokes, text entry accounted for approximately 1/2, cursor movement for about 1/4, deletion for about 1/8, and all other functions for the remaining 1/8. Analysis of keystroke transitions and editing states is also presented. Implications for past research, editor design, keyboard layout, and benchmark tests are discussed.

Contextualism as a world view for the reformation of meetings

The foundations for research and action in the area of group work are examined. Four alternative “world views” are presented. One of these, contextualism, is discussed in depth. Its methodological consequences for research and implications for reform of group meetings are explored.

The Dialectic of Usability Engineering

Publisher Summary This chapter reviews a major theoretical issue underlying usability engineering that emerges when usability is defined in terms of user experience. Usability engineering is emerging as an identifiable design philosophy and approach to the building of usable software systems. Usability, ultimately, lives in user experience. Therefore, usability engineering must be grounded in experience. Engineering is commitment to action in the world. It is building artifacts economically according to specification and infinite time. Engineering always operates against a background of scarce resources, such as talent, materials, time; and money. Usability Engineering provides a collection of powerful tools to support this part of the process. Engineering involves building things. Almost hidden by the transparency of this truism is that engineering involves a commitment to action in the world. A commitment is a pledge to cause to happen, by a specified time, an event with shared, agreed upon conditions of satisfaction. Engineering, and more generally commitment, depends on interpretation against a shared background of meaning, in other words, against agreed upon goals and conditions of satisfaction.

Contextual inquiry: grounding your design in user's work

One of the oldest and widely accepted principles in the design of computer-based tools for users is the principle “know the user.” This principle begs the question “What is the framework for knowing? Any approach to designing products for people contains implicit assumptions regarding what a designer needs to know, how that knowledge is obtained, how it is organized, and how it impacts the design of a product [2].

User centered design: quality or quackery?

Clearly User-Centered Design (UCD) is an activity that has entered the collective CHI-consciousness to an extent that should make us confident that usable systems are just around the corner. Of 18 large software producing entities surveyed over the summer of 1995, all reported either to have at least one documented UCD process in use or under development, or not to need one because UCD activities were well understood by the people responsible for carrying them out. However, scratching the surface of this utopian state reveals that the revolution is far from complete. We do not have a clear consensus about the boundaries of UCD (what constitutes a UCD method and what does not). We are not in agreement about how central users should be in the development of usable systems (If users design, what use are designers?). We have not had enough experience with our processes, to tell that they really lead to development of usable systems. This panel explores what we don’t yet know, and how we can try to know it.

Engineering for usability (panel session): lessons from the user derived interface

The focus here is on the lessons learned from the UDI project for building usability into the software development process. In the UDI project we attempted to engineer a usable system. That process involved:<list><item>defining an appropriate metric for measuring usability, </item><item>setting explicit levels of usability to be achieved </item><item>determining an appropriate methodology for building usability into the system, </item><item>delivering a seemingly functional system with an easily changed interface very early in the development cycle, and </item><item>recognizing the tentative nature of the initial design. </item></list> Using the UDI project as an example, each of the above principles will be discussed in detail.