Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | ProcessUsers&Tasks |Design | Inspections | User-testing | Tools | Documentation |

1.1 Figure Out Who's Going to Use the System to Do What
1.2 Choose Representative Tasks for Task-Centered Design
1.3 Plagiarize
1.4 Rough Out the Design
1.5 Think About It
1.6 Create a Mock-Up or Prototype
1.7 Test the Design With Users
1.8 Iterate
1.9 Build the Design
1.10 Track the Design
1.11 Change the Design


1.11 Change the Design


In today's computer market there are few if any software products that can maintain their sales without regular upgrades. No matter how well the product is initially designed to fit its task and users, it will probably be inadequate in a few years. Tasks and users both change. Work patterns change because of the product itself, as well as because of other new hardware and software products. Users gain new skills and new expectations. Designers need to stay abreast of these changes, not only by watching the workplace in which their products are installed, but also by watching for developments in other parts of society, such as other work situations, homes, and the entertainment industry. The next revision of the design should be a response not only to problems but also to opportunities.

HyperTopic: Managing the Design Process

Task-Oriented vs. Waterfall Design

The traditional "waterfall" model of software design starts with a requirements analysis step that is performed by systems analysts who are usually not the interface designers. These requirements are transformed into system specifications, and eventually the hardware, underlying software, and user interface are designed to meet those specifications.


The waterfall model has proven to be a poor approach to software that has an important user interface component. As this chapter describes, the successful interface designer needs a deep understanding of the user's task and how the task fits into the rest of the user's work. That understanding can't be derived from a set of abstract specifications. Further, our experience has shown that several design iterations are essential in producing an effective interface. The traditional waterfall model simply doesn't allow those iterations.


The Design Team


Because the task-centered design methodology spreads the activities of interface design throughout the software design and life cycle, the interface can't be produced or analyzed at one point by a group of interface specialists. The job of building a good interface has to be taken on by the team that designs the product as a whole.


The design team needs to be composed of persons with a variety of skills who share several common characteristics. They need to care about users, they need to have experience with both bad and good interfaces, and they need to be committed to and optimistic about creating an effective system. The team should include representatives from the entire range of interface-related areas: programmers, technical writers, training package developers, and marketing specialists. The team might include a user-interface analyst, but that's not essential. A shared commitment to interface quality, along with appropriate opportunities to interact with real users, will produce high quality interfaces for all but the most complex or critical interfaces.


Responsibility


Responsibility for the entire interface effort should be centralized. In particular, the designers who create the software shouldn't sign off on their product and hand it off to an entirely separate group that creates the manuals, who then hand off to another group that handles training. All of these activities need to be coordinated, and the only way to achieve that is through central management.


Usability Objectives


Serious corporate management efforts may require you to produce specific numbers that quantify usability. Usability objectives are target values for things such as speed to perform representative tasks and number of errors allowable. These can be used to motivate designers and support resource allocation decisions. The target values can be selected to beat the competition or to meet the functional needs of well- defined tasks.


(For more information on management, see Appendix M.)

Copyright © 1993,1994 Lewis & Rieman
Contents | Foreword | ProcessUsers&Tasks |Design | Inspections | User-testing | Tools | Documentation |