(by SIMians Course Comment Forum Group)

Overview

This page presents the results of heuristic evaluation of the McInterface system (first interactive prototype). Individual heuristic evaluations were performed by four evaluators, using Neilsen's standard usability heuristic list. The individual findings were then discussed and compared as a group. A summary table was compiled which includes all identified violations and severity ratings from the individual heuristic evaluations. Major findings and recommendations appear below.

Summary statistics

Total violations found (after eliminating overlaps): 54

Violations by severity:

Severity	Number of violations identified
4	2
3	13
2	19
1	8
0	12

Violations by heuristic:

Heuristic number and brief description	Number of violations identified
1 Visibility of system status	7
2 Match between system and real world	27
3 User control and freedom	3
4 Consistency and standards	11
5 Error prevention	6
6 Recognition rather than recall	5
7 Flexibility and efficiency of use	4
8 Aesthetic and minimalist design	2
9 Help users recover from errors	0
10 Help and documentation	2

Note that some violations were assigned multiple heuristics; thus the total number shown in the violations by heuristic table is greater than 54.

Major Findings and Recommendations

The following list represents the most critical findings and our overall recommendations for improving the McInterface:

1. The “Order Summary” page does not include important information about the order details, such as special requests and sizes. The scenario/persona information makes it clear that this information is critical to the users. We recommend that the Order Summary page be modified to show details about each item ordered. (Violation #21, Severity 4)

2. The “Order Summary” page can only show up to six items ordered. It should be able to show a much larger number of items ordered. Although this may be a limitation of the prototype, the design documentation did not specify this as a limitation. (Violation #48, Severity 4)

3. The use of the left-hand toolbar to display different parts of the restaurant menu was not obvious. Although it is probably better not to display the entire menu at once, this may surprise new users since it is different from the current restaurant menu. As a suggestion, the page should contain brief instructions such as "Click below to view different parts of the menu". (Violation #2, Severity 3)

4. The interface should display a list of what the user has ordered and the total amount the user owes while the user peruses the menus. Although we understand that the design team removed the "tray" feature due to space limitations, this information is very important to the user during the ordering process. The need to repeatedly switch from the menu pages to the "Order Summary" is time-consuming and increases the user's memory load. We suggest that perhaps an abbreviated order summary could fit on the screen, with the full details reserved for the separate "Order Summary" page. (Violation #10, Severity 3)

5. Since all users must select a size (for drinks, etc.) but only some must make special requests, there should be a “one-click” shortcut to order a drink/fries of a specific size. (Violation #52, Severity 3)

6. The "Eat in / To go" radio buttons on the "Order Summary" reset when the user returns to the ordering pages. This is likely to cause errors. (Violation #50, Severity 3)

7. The “Quit” option on the “Special Requests” dialog boxes should have a confirmation. Otherwise, it is too easy for the user to select this by accident, and have to start over. (Violation #30, Severity 3)

8. The user should not be able to enter a cash amount that is too small to handle the purchase. Although this may be a limitation of the prototype, it is not described in the design documentation. (Violation #57, Severity 3)

9. The “Thank you” page should display on the screen for longer than it currently does. The current delay (about 5 seconds) may not be sufficient for the user to read the instructions. (Violation #38, Severity 3)

10. The labeling of the “Cancel” button on the payment pages is unclear and should be changed. It can be interpreted to mean "Quit the system" rather than "Return to Order Summary". (Violation #36, Severity 3)

11. There are several violations related to the mechanism for selecting and displaying special requests. The use of a text box to display (but not to enter) special requests is confusing (Violation #40, Severity 3). Also, use of the radio button labeled "Regular" to remove a special request is confusing (Violation #31, Severity 2). The “Special Requests” dialog boxes for the different items should include all options that are appropriate to that item, and if possible these options should be previewed on the ordering page (Violation # 29, Severity 2). Overall, the Special Requests function should be redesigned to be clearer and to match users' expectations.

12. The “Start” page should contain some information regarding what the system does. (Violation #1, Severity 3)

13. The “Order Summary” page organization could be improved. The payment types should probably be included on a separate page. The “EatIn/To Go” options should either be highlighted on this page or moved to a separate page. (Violation #20 and 22, Severity 3)

14. A number of issues were observed related to consistency and clarity in the menus. For instance, the “Beverage” menu page should include pictures of beverages, rather than just text (Violation # 17, Severity 2) and sizes for drinks and fries should be visible on the menu details pages for meals (Violation #61, Severity 3).

In addition to internal consistency issues, it is also important to be consistent with the real-world McDonald's options. For instance, the Extra Value meal “Details” pages should make it clear that the meal includes french fries. Similarly, the condiments that are offered for each item should vary depending upon the item. Although not necessarily severe individually, in combination these violations make the interface less usable.