Revised Design

From the testing of our paper prototype, we learned that the design need to accommodate other means of payments. We decided to leave aside the McCard function from our first-iterative prototype, but still want to consider it for future designs for the following reasons:

• No participants in our testing saved their favorite orders in their McCards. Therefore, it is possible that the McCard function will actually have little use. However, we should also consider that the concept is rather new to the users, who might already be inclined to reject what they have not been used to. The acceptance of the concept can involve many different factors. For example, the European countries seem readier to accept the smart-card technology than the US.
• Some participants said that they do not want to have another card to buy food at McDonalds. However, our further research (http://pc.idg.net/english/crd_cards_32893.html) shows that McDonald's is already implementing the system in Germany. In fact, they have been used in Europe by several merchants, not just McDonald's. The system that lets users get a new card and add its value is separate from the smart-card readers. The current system does not yet allow electronic ordering. One benefit of smart cards is that they do not require merchants to communicate with banks to authorize purchases. Regarding our system, smart-cards, therefore, simply represent another type of payment. What will affect our design, however, is the possibility of saving personalized information (favorite orders) on smart cards (McCards). We might have to revisit this issue in the future.

We then start to focus more on minimizing the required steps needed to perform a quick order (i.e. simply ordering a Big Mac), since the subjects who tested for the quick purchase scenarios complained that there were too many unnecessary steps.

Our design currently allows three types of payment: credit card, ATM card, and cash instead of using only McCards. We no longer use tabs to categorize menu items because by doing so forces the number of categories into a small number. That resulted in two levels of hierarchy. One consist of tabs labeled MyFavorites, Extra Value Meals, New Tastes / Mini Meal Deals, Happy Meals, and Others. The other is a drop down list box of sandwiches, salads, desserts, and beverages, in the Others page. (screenshot) In the revised design, we instead divide the screen into two columns. The first, which is narrower, has a list of all categories. The second wider column displays the items that belong to the category picked by the user. This design has all categories in one level (screenshot).

However, this change is in expense of having the tray visible at all time (screenshot). With a new design, we cannot fit all elements in one screen. Therefore, we decided to convert the tray concept into a new screen that serves a similar function by summarizing the current items in the order (screenshot). Users can view their order by clicking the View Order / Check Out button and go back to order more or check out by choosing their payment options. This screen also shows three buttons of payment choices: credit card, ATM card, and cash. Tapping each option will direct the users to a screen that serves the corresponding type of payment.

As a result of another important feedback on the toys, we add a 'Preview Toys' feature under the 'Happy Meal' category (screenshot). Clicking this label will show pictures of toys. We also made some minor rearrangements by associating the 'sauce' option to each food item (only ketchup for this prototype, screenshot). We also allow users to choose their language right on the start page without an extra click (screenshot). Note that 'Start[Spanish]' means the word 'Start' written in Spanish and the same applies to Chinese.