Restaurant Point-of-Sale Interfaces: Comparisons in Menu Organization and User Efficiency
This project was partial fulfillment towards a Masters of Science degree in Applied Psychology at Arizona State University.
Problem:
• Need generalized, usability guidelines for restaurant interfaces.
• Interfaces are designed with a focus on functionality over user experience, often disorganized.
• New servers learning to use this program may make mistakes, resulting in customer dissatisfaction, user frustration, and loss of profits.
• Interfaces are designed with a focus on functionality over user experience, often disorganized.
• New servers learning to use this program may make mistakes, resulting in customer dissatisfaction, user frustration, and loss of profits.
Persona:
A persona was developed to answer "why" this problem was important. This was created in Microsoft Powerpoint.
Hypothesis:
Implementing left side emphasis and categorical design in restaurant point-of-sale interfaces can positively impact selection accuracy, selection time, and total time spent on the related type of tasks for new users.
User Flow:
User flow was the premise for the design. Categories and items were laid out accordingly by proximity. I wanted to place related items together that would lead the user to the next logical step. The menu also modeled the way a typical dinner service was scripted.
For example, a server approaches your table and takes drink orders, then leaves to retrieve the drinks, and returns for your appetizer or entree orders.
That means the script between you and your server has a specific order: Drinks > Appetizers > Entrees > Desserts
The treatment followed this order.
It also categorized by subcategory to help teach novice servers how to take orders efficiently, because experienced servers took their orders this way.
Flow Examples:
Drink Selection:
Drinks > Soda > Sprite > Diet Coke > Cold Drinks > Lemonade
One Customer Order:
Drinks > Cold Drinks > Water > Appetizers > Salad > Caesar Salad > Entrees > Spaghetti & Meatball
Then by proximity, modifications took place next to the working total.
Select Coke > Less > Ice
Study:
2x2 repeated measures with partial counterbalancing.
Conditions:
• List Type (categorized/restaurant scripted)
• Interface Type (treatment/control)
Dependent measures: Selection time, total time, errors, and number of selections.
28 participants: m=21, f=7, age=21.18
Design:
Based on background literature, categorical organization and F-shape were incorporated into the design as main usability factors. In theory, categorical organization would encourage new servers to take customer orders more efficiently.
Two interface prototypes were created in Axure RP 7.0:
- The control interface followed NCR's default Aloha Table Service program.
- The treatment interface was designed with usability.
Results:
Data were coded from screen recordings and ran in SPSS.
Significant differences were found for selection time, total time, and number of selections.
Errors, selection amounts, and selection time were used to calculate efficiency, which was also significant.
No significant difference in number of errors.
Discussion/Implications
1. Implementing usability into restaurant interfaces help new servers be more efficient, make faster and fewer selections, and spend less time entering table orders.
2. Teaching servers to organize items by category result in fewer selections because it helps them plan inputs ahead of time.
3. The amount of errors made when entering orders is not related to the way an interface is organized.
Interface Screenshots:
Treatment interface
Control Interface
Presentations
I presented this project at ASU's Innovation Showcase in the Fall 2015 and Spring 2016.
The Spring poster can be found here: Link
The research paper is currently pending for submission in ASU's digital repository.
Video Demo
Miscellaneous
Experimental set up
Early Wireframe Iterations:
First sketch. Tabs were favored in the beginning, but that idea was eventually tossed.
First prototype iteration for the sketch in Axure. The tabs were functional at this point. The buttons were too small and there were many issues with this design.
Second prototype iteration. After removing the tabs and restricting some of the point-of-sale operations for test purposes (i.e., removed manager functions), the modify window was moved closer to the working total and the "send" and "cancel" buttons were adjusted.
