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