Download Task-Centered User Interface Design

Task-Centered User Interface Design
81
had the complete system for them to work with, but you will see whether
the main lines of your design are sound.
HyperTopic: Some Details on Mockups
What if a task involves user input that is their free choice, like
a name to use for a file? You can’t anticipate what the users will
type and put it on your mockup screens. But you can let them
make their choice and then say something like, “You called your
file ‘eggplant’; in this mockup we used ‘broccoli’. Let’s pretend
you chose ‘broccoli’ and carry on.”
What if it is a feature of your design that the system should
help the user recover from errors? If you just provide screens for
correct paths you won’t get any data on this. If you can anticipate some common errors, all you have to do is to include the
error recovery paths for these when you make up your screens.
If errors are very diverse and hard to predict you may need to
make up some screens on the fly, during the test, so as to be able
to show test users what they would see. This blends into the
“Wizard of Oz” approach we describe later.
Some systems have to interact too closely with the user to be well approximated by a simple mockup. For example a drawing program has to
respond to lots of little user actions, and while you might get information
from a simple mockup about whether users can figure out some aspects of
the interface, like how to select a drawing tool from a palette of icons, you
won’t be able to test how well drawing itself is going to work. You need to
make more of the system work to test what you want to test.
The thing to do here is to get the drawing functionality up early so
you can do a more realistic test. You would not wait for the system to
be completed, because you want test results early. So you would aim for
a prototype that has the drawing functionality in place but does not have
other aspects of the system finished off.
In some cases you can avoid implementing stuff early by faking the implementation. This is the Wizard of Oz method: you get a person to emulate
unimplemented functions and generate the feedback users should see. John
Gould at IBM did this very effectively to test design alternatives for a speech
transcription system for which the speech recognition component was not
yet ready. He built a prototype system in which test users’ speech was piped
to a fast typist, and the typist’s output was routed back to the test users’
Text available from hURL:ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book/i.