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.8 Iterate


The testing with users will always show some problems with the design. That's the purpose of testing: not to prove the interface, but to improve it. The designer needs to look at the test results, balance the costs of correction against the severity of each problem, then revise the interface and test it again. Severe problems may even require a re-examination of the tasks and users.


One thing to keep in mind during each iteration is that the features of an interface don't stand alone. Revising a menu to resolve a problem that occurs with one task may create problems with other tasks. Some of these interactions may be caught by reanalyzing the design without users, using techniques like the cognitive walkthrough. Others may not show up without user testing.


When should the iterations stop? If you've defined specific usability objectives (see hypertopic on Managing the Design Process), then iteration should be stopped when they are met. Otherwise, this will often be a management decision that balances the costs and benefits of further improvement against the need to get the product to market or, in in-house projects, into use.




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