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


We don't mean plagiarize in the legal sense, of course. But you should find existing interfaces that work for users and then build ideas from those interfaces into your systems as much as practically and legally possible. This kind of copying can be effective both for high-level interaction paradigms and for low-level control/display decisions.


At the higher levels, think about representative tasks and the users who are doing them. What programs are those users, or people in similar situations, using now? If they're using a spreadsheet, then maybe your design should look like a spreadsheet. If they're using an object-oriented graphics package, maybe your application should look like that. You might be able to create a novel interaction paradigm that's better suited to your application, but the risk of failure is high. An existing paradigm will be quicker and easier to implement because many of the design decisions (i.e., how cut and paste will work) have already been made. More important, it will be easy and comfortable for users to learn and use because they will already know how much of the interface operates.


Copying existing paradigms is also effective for the low- level details of an interface, such as button placement or menu names. Here's an example. You're writing a special- purpose forms management package and the specifications call for a spelling checker. You should look at the controls for spelling checkers in the word processing packages used by people who will use your system. That's almost certainly how the controls for your spelling checker interface should work as well.


This is an area where it's really common for designers to make the wrong decision because they don't look far enough beyond the requirements of their own system. Let's dig a little further into the example of a spelling checker for the forms package. Maybe your analysis has shown that the spelling checker will most often pick up misspelled names, and you can automatically correct those names using a customer database. So you decide the most efficient interaction would be to display the corrected name and let the user accept the correction by pressing the Return key. But the word processor your users use most frequently has a different convention: pressing Return retains the "wrong" spelling of a word. Do you follow the lead of the existing system ("plagiarize"), or do you create your own, more efficient convention? To an extent the answer depends on how often users will be running your system compared to how often they will be running systems they already know. But more often than not, the best answer is to stick with what the users know, even if it does require an extra keystroke or two.




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