New Restaurant System
The automation process is centered around the use of QR-codes and multiple screen devices.
Product Description
Based on team discussion and initial rapid user survey, we figure out that getting the server’s attention and waiting are two parts that frustrated diners most. The new restaurant system we designed will optimize the existing one by doing the following:
-
Introducing QR-Code allows diners to use their personal mobile devices to order, add food, and pay the check anytime they want. The system reduces diners’ waiting time and makes the ordering process more flexible for diners.
-
For restaurants, we introduced multiple devices for different roles, including server, chef, and busser, to help them communicate. The kitchen screen will make the order status more visible for the chef. It will also benefit servers to deliver food on time and minimize the errors, such as providing the wrong orders. Wearable devices, such as vibrating wristbands, can let servers check the delivery status timely. Bussers will get immediate updates on which table is required to clean immediately.
Displaying available tables, indoor navigation, immediate feedback system to kitchen, and online ordering and payment, are features included in our new restaurant system.
User Diagram 01 - Diners
We analyzed diners’ dining experience from entering restaurants to ordering food and paying bills. It is similar to what we discovered earlier by group discussion and rapid user survey. We marked diners’ waiting behavior in grey and asking for service in the red. It is quite obvious that the total time of diners waiting for asking services occupied a large part during the whole dining process. So in the later section, you’ll see how our solution fixes this problem for diners.
User Diagram 02 - Restaurant
The diagram of restaurants is much more complex than diners. Depending on the type of restaurant, there may be more roles that we did not account for in our diagram. However, we included the most common roles that are involved in the process, such as hosts, servers, chef, and bussers. The hardest part of the process is communication. Updating information timely to a certain role, such as the chef tells the server that the order is ready, and the server gives feedback to the chef and POS machine the food is delivered. Those back and forth communication are important to diners’ dining experience and decide how long they need to wait. We think that the existing system does not solve the issue very well yet.
Storyboard - Our Solution
Feedback to Storyboard
Here are some comments and feedback we collected from outlier:
-
When the cook receives the order→ Generally there is more than one cook, so instead of having the cook receive the order on his or her phone, I think we should have one large screen. That way the design is more transparent, and many people (including servers potentially) can see the orders come in. Having one (or more) large screen/monitor will be better from a hygiene perspective too, because the cooks won’t have to handle their phones.
-
Sending out the food → I think there should still be a printed aspect like in traditional restaurants. This works as a double check--making sure the food matches the order. Because servers are not taking the orders, they don’t know what people are ordering, and in turn, won’t know if the order matches the food coming out. Maybe when the order is ready, the chef can hit “complete” on the system and it will automatically print the order. The chef can then put the printed order next to the food going out.
-
Bussers → In this current scheme, the only job bussers would have would be to clear tables. Because of this, I’m not sure how necessary a wearable may be-- it may be adding complexity to something that rather than building off of the the standard solution (knowing when to buss a table based on seeing a dirty table). I’m having a hard time explaining this, so it might be better to talk about on our meeting.
The function of this prototype is to allow customers to get their own table on their own time without relying on a hostess. This is done by inputting the amount of people in their party on the home screen. The maximum number of people goes up to 8, which is the max number of chairs at a table, so diners have the ability to get a table and seat themselves. However, if there are more and the “+” button is pressed, then someone working at the restaurant will help accommodate the extra people.
1-1 Home Page
When the user presses next, the app will calculate the optimum table for that party - a map of the exact layout of the dining room will populate, highlighting the table that the party will go to. Users have the ability to go back to the home screen if they see they entered the wrong party number or if they change their mind. They will then press the confirm button on this screen, taking them to the confirmation screen. This page will list the party amount and table number, and instructions on how to get to the table.
1-2 Table Availability
We decided that having a light above each table would create the sufficient ability for diners to find their table easily, as well as showcase the status of that table (i.e. occupied, vacant, needs bussing, etc.). Once the user presses confirm, the table that they will occupy and the corresponding table number will slowly blink to further let them know which table is theirs. A sensor in the light will be able to know when the party arrives, stop blinking, and turn to red.
1-3 Confirmation
Wireframe 01 - Diner Experience
This prototype is for a user interface on mobile devices such as mobiles and tablets at the very front of the restaurant, similar to a self-serving hostess stand. Diners would have the ability to come to the establishment, walk up to the tablet stand or using their own mobile scanning the QR code, and have an available table picked for them. They would then be able to walk to their designated table. The function of this prototype is to allow customers to get their own table on their own time without relying on a hostess.
Path 1 - When there are tables available
We also created screens for a different path - if the dining room is full. A screen will populate telling the diner how long the wait time is. They would be able to confirm yes, they want to wait for a table, or press the no button to cancel that table order and go back to the home screen. If yes is pressed, the next screen will then ask them to enter their phone number so they can be reached when their table is ready. They can confirm their party number, the cell phone number, and press confirm. Then a pop-up will tell the user they are in the system and they can then wait for a text. When OK is hit, the home page will populate and the next diner can begin the process.
Path 2 - When the dining room is full
2-1 Input number of people
2-2 Inform waiting time
2-3 Asking inputing phone number
2-4 Confim phone number
2-5 Feedback
We also designed a mobile version, which has a few extra features including view menu, finish and pay, and make a reservation. To automate the experience, we would set up QR codes at the table which connects them to the restaurant’s website, allowing diner’s to access the menu from their phone as well as pay. This app will allow them to have all functions in one place, including get a table at the establishment just like at the iPad station, or make a reservation.
Mobile Version
Wireframe 02 - Kitchen System & Table Status
1. Kitchen Display System
The Kitchen Display System (KDS) displays order tickets on a touch screen as they are sent from diners.
1. Chefs can mark when they have finished preparing a specific order by tapping the hollow circle next to the meal, which marks it green.
1-1 Mark specific order as complete
2. If the chef has a question or needs clarification, he may touch the server’s name on the order ticket which automatically alerts the server on her wearable. When a chef completes an entire order and is ready to send out the food, he can swipe the ticket which automatically prints the ticket and alerts the respective server on her wearable. If the chef needs to review a previously closed ticket, he can press the recall button.
1-2 Swipe up to complete the entire order and print the ticket
3. The KDS system is designed to mirror the paper ticket system formerly used in kitchens. It employs a more skeuomorphic design to suggest verisimilitude which helps distinguish tickets (especially when a ticket extends to the next line). It facilitates communication between cooks by showing when both individual orders and entire ticket orders are completed.
1-3 All tickets shift in response to the completed ticket
2. Table Display System
The Table Display System (TDS) shows the status of the tables in the restaurant.
1. The TDS system is color coded, with the colors corresponding to whether a table is open, in use and waiting, ready to serve, eating, in need of bussing, or in need of a server.
2-1 View all tables
2. The tables display the time since the party was seated, and servers can review each tables’ order tickets by touching the tables. The TDS is integrated with the KDS, POS and wearables so that the tables will change according to the triggers sent by the accompanying systems or devices.
2-2 Click a specific table
3. The TDS functions as a view of the floor from the kitchen. It provides feedback so that kitchen staff (and others) can understand what is happening on the floor and how tables are being turned. Rather than decentralizing the information and having all restaurant staff responsible for their own devices, the TDS consolidates all information into one accessible and transparent interface. This allows servers and bussers to collaborate and work more efficiently because they are aware of the status of everyone’s tables, not just their own. In other words, the TDS allows servers to translate knowledge “in the head” to knowledge “in the world” while still affording workers the flexibility for extemporaneous help or adjustments.
2-3 View table ticket
Rapid User Survey
We asked some key questions about how chef and server communicate when the food is ready. This helped me design the Kitchen Display System and Table Display System.
Q1. What do you do when you are waiting for the food? How do you know when it is ready? Did you need to individually fire orders at the right time, or does the POS timed already?
-
User 1: Depends on the pos! And you kinda gotta go check yourself if you want it a certain way. Yeah it can be pretty awk and depends on what we say to the kitchen.
-
User 2: I’ve had two different experiences. Seafood restaurant on Martha’s Vineyard had an expo and he timed everything and everyone in the kitchen communicated very well to each other. Harvey’s went through so many phases but you can designate the courses and the kitchen spaces it out. Sometimes with an expo and sometimes on their own and it all varied on success. When you modify there’s only a certain amount of characters. Usually 8 you can type. So sometimes many lines of notes. So if it’s complicated I go back and be like “this is what I meant”.
Q2. And how do you know when your order is ready?
-
User 2: We had food runners or if it was a weekday then I’d just looked in the window and see. Back in the day we had pagers.
Q3. did the food runners just hang out back there?
-
User 2: Yup.
Reflection
In order to design a system that automates the restaurant process, we first had to investigate how restaurants function and the roles of their employees. To do so, we spoke with several servers and drew from personal experience to create a user flow that outlined the ordering process and the various stages of interaction. One of the most significant insights we gained was the importance of communication in a restaurant. In restaurants, there needs to be constant communication to successfully complete orders and address unforeseen problems. This is especially important due to a restaurant’s fluid nature, where things are prone to change depending on demand, availability, staffing, and other factors.
While communication takes place across all levels in the restaurant, there is the unique challenge of communicating between the kitchen and the floor. Servers function as an intermediary between those two spaces and they are required to communicate not just the orders, but also any minutiae that may accompany an order. Servers also function as a second set of eyes to confirm that the orders they placed were prepared correctly by the kitchen.
We decided to approach the problem of restaurant automation with these issues of communication in mind. Since so much of restaurant communication is informal and extemporaneous, we realized that it would be better to design a system that could (if needed) accompany such communication rather than try and eliminate the verbal communication completely.
Our design builds off of the current kitchen-floor binary and works to make all information centralized and visible, starting with the ordering process. Diners place their orders which are automatically sent back to the kitchen and displayed on the Kitchen Display System (KDS). Cooks can view the order information, and servers can view the status of their tables on the color-coded Table Display System (TDS). If servers wish to view an order, they can click on the table and view the table ticket. When an order is completed, the cook will swipe the ticket on the KDS which will automatically print the ticket and change the table status on the monitor, as well as alert the server on his or her wearable. The server can receive the order and check that it is correct either with the physical ticket, or through the TDS. The server can then deliver the order and tap their RFID enabled wearable to show that the order has been delivered, which changes the table status on the KDS. This process is repeated with bussers, who also have a RFID enabled wearable that will change the table status on the TDS.
By having a KDS and TDS integrated with a point of sales system, we aimed to make all operations transparent and accessible to all restaurant workers. Even though the kitchen is the central hub of information, the RFID wearables allow workers to “see around corners” without decentralizing the information. This is important for providing feedback from the floor while still preserving the different responsibilities of different workers. Furthermore, our design never places too much importance on one person or one interaction. This was an intentional effort to make our design resilient and error-expectant rather than error-proof. Instead of having one system or technology responsible for all interactions, we employed a several-step process with built in checks and feedback to ensure that any errors would be visible and easy to work around.
From a dining standpoint, we decided to build off of an already popularized framework of QR codes and iPad touch screens. Due to the pandemic, some diners will already be familiar with scanning QR codes to access menus and order forms, so our seating and ordering process will not be entirely novel to them. In order to accommodate all diners, however, we have also included an iPad touch screen in case someone would prefer that modality.
We made a few revisions to the dining process based on feedback we had received. Initially we let diners choose their own seats from an interactive seating chart that displayed wait times. Although this afforded diners more choice, it also introduced more ambiguity and increased the chances of error and dissatisfaction. We revised the design to include a seating algorithm that chooses a table based on the number of people in a diner’s party. This streamlines the process and makes the experience more accessible. The diner only needs to look for the corresponding green light to find his or her table.