User Interface Design and Ergonomics - National Open University of ...

would do to accomplish a task you have assigned. They describe their action, and you
make the next screen appear, either by rummaging around in a pile of pictures on paper
and holding up the right one, or by getting the computer to show the appropriate next
screen.
This crude procedure can get you a lot of useful feedback from users. Can they
understand what's on the screens, or are they baffled? Is the sequence of screens wellsuited
to the task, as you thought it would be when you did your cognitive walkthrough,
or did you miss something?
To make a simple mockup like this you have to decide what screens you are going to
provide. Start by drawing the screens users would see if they did everything the best way.
Then decide whether you also want to "support" some alternative paths, and how much
you want to investigate error paths. Usually it won't be practical for you to provide a
screen for every possible user action, right or wrong, but you will have reasonable
coverage of the main lines you expect users to follow.
During testing, if users stay on the lines you expected, you just show them the screens
they would see. What if they deviate, and make a move that leads to a screen you don't
have? First, you record what they wanted to do: that is valuable data about a discrepancy
between what you expected and what they want to do, which is why you are doing the
test. Then you can tell them what they would see, and let them try to continue, or you can
tell them to make another choice. You won't see as much as you would if you had the
complete system for them to work with, but you will see whether the main lines of your
design are sound.
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' screen. This idea can be adapted to many situations in which the system you
are testing needs to respond to unpredictable user input, though not to interactions as
dynamic as drawing.
179