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 | |
2.1 Getting in Touch With Users
So here's what to do. The first step is to find some real people who would be potential users of what you are going to build. If you can't find any you need to worry a lot. If you can't find them now, where will they come from when it's time to buy? When you have found some, get them to spend some time with you discussing what they do and how your system might fit in. Are they too busy to do this? Then they'll probably be too busy to care about your system after it exists. Do you think the idea is a real winner, and they will care if you explain it to them? Then buy their time in some way. Find people in your target group who are technology nuts and who'll talk with you because you can show them technology. Or go to a professional meeting and offer a unique T-shirt to people who'll talk with you (yes, there are people whose time is too expensive for you to buy for money who will work with you for a shirt or a coffee mug).
"I don't have to bother about this stuff. My system will be a tool for any UNIX user, no matter what they are working on. There's no special user population I'm trying to support."
Unfortunately experience shows that many ideas that are supposed to be good for everybody aren't good for anybody. Why not check by finding somebody and making sure it's good at least for them?
"Well, I'm somebody and my tool is good for me."
Two points here. First, is it REALLY good for you? Do you actually USE it? Never work on something if you ought to be a user for it but you aren't. It's amazing how often this principle is violated. Second, there are lots of reasons why things often seem more useful to their designers than they do to other people. A big one is that the designer builds up his or her understanding of the thing over a long time and with a lot of thought. Usually the user wants to understand it right away, and often can't (Bruce Tognazzini makes this point very well in "Tog on Interface" Reading, MA: Addison Wesley, 1992, p. 8).
Copyright © 1993,1994 Lewis & Rieman |
Contents | | Foreword | | ProcessUsers&Tasks | | Design | | Inspections | | User-testing | | Tools | | Documentation | |