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.4 Rough Out the Design


The rough description of the design should be put on paper, which forces you to think about things. But it shouldn't be programmed into a computer (yet), because the effort of programming, even with the simplest prototyping systems, commits the designer to too many decisions too early in the process.


At this stage, a design team will be having a lot of discussion about what features the system should include and how they should be presented to the user. This discussion should be guided by the task-centered design approach. If someone on the team proposes a new feature, another team member should ask which of the representative tasks it supports. Features that don't support any of the tasks should generally be discarded, or the list of tasks should be modified to include a real task that exercises that feature.


The representative tasks should also be used as a sort of checklist to make sure the system is complete. If you can't work through each task with the current definition of the system, then the definition needs to be improved.




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