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.9 Build the Design


The key guideline in building the interface is to build it for change. If you've been using a UIMS for prototyping, then you're already close to a finished product. If you've been using some other prototyping system, now is the time to switch to a UIMS or, perhaps, to an object-oriented programming environment. Try to anticipate minor changes with easily changed variables. For example, if you have to write your own display routine for a specialized menu, don't hardcode parameters such as size, color, or number of items. And try to anticipate major changes with code that is cleanly modular. If a later revision of the design requires that your specialized menu be replaced by some more generic function, the code changes should be trivial. These sound like ordinary guidelines for good programming, and indeed they are. But they are especially important for the user interface, which often represents more than half the code of a commercial product.




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