LOOP: AIGA Journal of Interaction Design Education
June 2003 Number 7

Two iterations in two weeks
fter a very brief introduction to process, students were asked to design the interface for a kiosk in a fast food restaurant. I provided a set of data—a menu with prices and special combo orders. They produced a paper pro totype of an interface in one week that supported two user tasks: placing a particular order (which I provided) and changing an order (removing an item or changing quantity).
      The second week of class began with a short presentation on protocol for conducting usability tests. I provided a pre-questionnaire, tasks printed out for the users, a post-questionnaire and so on. Then teams scattered through the school to meet with their test subjects and conducted tests on at least two people.
      We regathered to talk about what worked and what didn’t—what we would change about the design, the test protocol and the construction of the prototypes. Based on these lessons, students were asked to develop a second iteration for the following week.
      The results were interesting. Every team encountered common design challenges that ranged from fitting the whole menu on the screen at once to providing feedback for the order as it progressed. In effect, because many teams created prototypes rapidly, we explored many possible solutions in a very short time. I actually recommend this as a technique for teams in industry: set an aggressive deadline for a complete prototype, turn several two- or three-person teams loose in parallel, run quickie tests and regather to debrief the results. You may be surprised by how much energy you generate, how many issues you explore and how quickly unforeseen solutions start to emerge from the whirl.

      Figure 1 shows one page from each of the prototypes. The specifics of each design are less important than the collection. With inexperienced students working under unreasonable deadlines, we had no expectations for developing a finished solution. But we did ground conversations about interface design in realistic problems. These designs raised issues from the smallest details about choosing appropriate labels to grand questions about balancing between marketing goals and customer goals.
      Students turned in a revised design with a document explaining any changes. Here are a few quotes, along with the issues they made burningly real:

“User fails to follow printed direction reading, ‘Press a price to select an item.’ Instead, user attempts to select item by pressing picture of an item.” [Instructions on interface are evidence of a design flaw: visual qualities that invite pressing or clicking trump conscious processes like “following directions.”]

“User appreciated seeing special offers but was disconcerted that savings didn’t leave screen. User attempts to find button to make savings info go away.” [Mixing promotions with core functionality is difficult; Users expect ads to behave differently. This illustrates how people behave when their expectations prove false.]

“He didn’t know whether the milk shake would be under drinks or dessert.” [Categorizing well-known items can be surprising difficulty. Do you categorize for recognition or recall? Placing items in multiple categories can be valuable.]

“User ordered a la carte then pulled up extra value meal to compare prices.” [People will use a tool in unanticipated ways. Treat this case as a problem to solve or an indication of a need/desire to compare prices.]

“We had hoped to eliminate all of the bugs in our interface with the first revision but discovered some new or previously unnoticed problems in our second user test.” [Heee! Probably best if you never indulge in that hope again: the first designs always suck. Making changes often introduces new problems.]

“The real-time total off to the side gave user the impression that the order was finished and therefore did not need to hit the SEND button (which is something you don’t need to do at a typical food store).” [Previous conversational patterns in the restaurant setting created expectations. Consider how to complete an an open-ended task.]

LOOP June 2003 Number 7