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.2 Choose Representative Tasks for Task-Centered Design


After establishing a good understanding of the users and their tasks, a more traditional design process might abstract away from these facts and produce a general specification of the system and its user interface. The task-centered design process takes a more concrete approach. The designer should identify several representative tasks that the system will be used to accomplish. These should be tasks that users have actually described to the designers. The tasks can initially be referenced in a few words, but because they are real tasks, they can later be expanded to any level of detail needed to answer design questions or analyze a proposed interface. Here are a few examples:


    * for a word processor: "transcribe a memo and send it to a mailing list"
    * for a spreadsheet: "produce a salary budget for next year"
    * for a communications program: "login to the office via modem"
    * for an industrial control system: "hand over control to next shift" 

Again, these should be real tasks that users have faced, and the design team should collect the materials needed to do them: a copy of the tape on which the memo is dictated, a list of salaries for the current year and factors to be considered in their revision, etc.


The tasks selected should provide reasonably complete coverage of the functionality of the system, and the designer may want to make a checklist of functions and compare those to the tasks to ensure that coverage has been achieved. There should also be a mixture of simple and more complex tasks. Simple tasks, such as "check the spelling of 'ocassional'," will be useful for early design considerations, but many interface problems will only be revealed through complex tasks that represent extended real- world interactions. Producing an effective set of tasks will be a real test of the designer's understanding of the users and their work.




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