First, we needed to determine which aspects of the new voice-recognition interface for drive-throughs were the most important and crucial for its usability. These components should be components of the interface, not the actual system. Therefore, "toy" prototypes which have very little or no real functionality can be quite useful.
3.1.1 Interface Layout and Appearance
One important aspect of any interface that will be used by a large user
population, especially if most of the users are novices or occasional users,
is the appearance and layout of the interface. It is important to test the
use of screen space, color, text, video, and other visual aspects
that are obvious to any user who walks up to the system for the first time.
This component of the interface is crucial because the presentation of information in an interface can be as important as the information itself. A system may work perfectly and provide all necessary information to the user, but if the user has trouble finding that information on the display, or if the user's attention is drawn away from the desired information by another part of the display, the interface has not been designed well.
In particular, we must be careful with our use of color and multimedia. These things are generally desirable, but too much of a good thing can be harmful to the ease-of-use of the interface.
In order to test this aspect of the system, we used sketches as a static prototype. Because the sketches have no actual functionality, they isolate the component of appearance and layout. They are hand-drawn, so they do not distract the tester with fancy, computer-produced pictures, buttons, etc. We believe that these drawings, while inexpensive to produce in terms of time and resources, can go a long way in measuring the effectiveness and usability of the visual interface.
3.1.2 Ordering Tasks and Feedback
One of the most desirable aspects of the
voice-recognition interface we designed is that the ordering task
is not dissimilar from the way it is done in the current interface.
People verbalize their order, which is quite natural for most users. Granted,
they may not be able to use quite as large a range of vocabulary in the
new system, but we claim that would not significantly decrease the usability
of the interface for most occasional users. To test this, we need to
have some way to measure the number of errors users would make in such
a system, and what they would actually say.
Another extremely important design feature of our system is the amount of feedback given to the user. In the current interface, there is little or no feedback, and when it is given, it is inconsistent from user to user. We have attempted to include a great deal of immediate and consistent feedback in our design.
Both of these components are tested in our second prototype. This is a "Wizard of Oz" prototype built on top of the Macintosh HyperCard development application. To simulate the actual workings of the system, a potential user sits in front of the monitor, which shows a menu and another window with instructions, feedback on orders, etc. When the user begins to use the interface (by speaking), the feedback and responses are controlled by someone else using command key combinations on the keyboard.
In this way, we hope to record several important measurements, such as:
3.1.3 Cancellation Tasks and Ending an Order
Another crucial component of our interface is the ability on the user's
part to easily cancel or change the order. This is, in effect, error-handling
in our system. We want to make it painless for the user to recover from
a mistake, and we want them to be free to change their minds at any time in
the ordering process. Cancellation, then, is a very important task for our
interface to handle cleanly.
Finally, we need some way to test our interface at the conclusion of a customer interaction. There must be a clear and simple way for the user to end the session and move on to payment and picking up their food. It would be tragic if our interface worked perfectly all the way to this point, and then the user could not figure out how to quit.
To test these final two components, we developed a third prototype, which we are calling a "textual storyboard". Unlike a traditional storyboard, with images and links between them, our prototype uses textual descriptions of what the user sees and hears, and then asks them to give a response. This is quite straightforward to implement in hypertext form using Mosaic.
We will focus and direct the scenarios in this prototype to test the two aspects of the interface described above, cancellation and termination, so that the tester is forced to try to use those parts of the interface. In this way, we can test how well the instructions for those tasks are presented, and how natural or intuitive the actions are.
Of course, the last two prototypes could be exchanged in function. We could have tested cancellation and termination using the HyperCard approach, and ordering and feedback using the textual storyboard. Both techniques allow for interactivity on the part of the user. We chose the mapping described above, though, to reflect the importance of system aspects as we perceived them. Since the ordering task seems to be most central to the operation of the interface, we felt that it should be tested using a prototype that delivers a great deal of fidelity. The Wizard of Oz prototype is more realistic than either of the other two, because responses are given in real time, the actual display is in front of the user, and there are relatively few constraints on what the user may do. Thus, we chose to test ordering with HyperCard, and cancellation with the storyboard technique.