Order Tracker for Restaurants
Class —> HCI 440: Introduction to User-Centered Design
Role and Responsibilities —> User Research, Ideation, Prototyping, and User Evaluation
Duration —> January 2025 - March 2025
Background
HCI 440 at DePaul provides students with a broad overview of the steps involved in the user-centered design process. For our quarter-long group project, we were tasked with identifying an issue within the service industry to address that would allow us to learn the main steps of the design process outlined by Stanford's d.school framework: empathize, define, ideate, prototype, and test.
Problem
Miscommunication between the kitchen and servers leads to workflow breakdowns
In the hustle and bustle of a busy restaurant, back and forth conversations about orders can be a source of disruption and frustration. However, there must be a way for servers and chefs to stay on the same page about order details, order status, and wait times for guests -- otherwise, delays and incorrect orders arise.
User Research
Insights from interviews
As a team, we interviewed 10 individuals who work in the restaurant industry. Among the participants were chefs, servers, and restaurant owners. From the experiences shared with us, we uncovered the following pain points in their work flow:
Communication between servers and the kitchen is difficult to maintain
Chefs feel "nagged" when servers check in on orders, and servers feel left in the dark when trying to keep customers informed.
Incorrect orders and delays can be detrimental to workflows
An incorrect dish sets off a chain reaction of delayed orders, placing extra strain on the kitchen. This can lead to breakdowns in communication.
Special requests, modifications, and allergies complicate the execution of orders
Modified items and accommodations for customers with allergies requires additional time from the kitchen, while servers must make the kitchen aware of these details.
User Personas
In order to represent the intended users in our design process, we developed two main personas who reflect the motivations and frustrations uncovered in our interviews:
Conceptual Design
After consolidating our interview findings and crafting personas, we explored requirements for our solution that would address the frustrations and goals of our participants. We then created design scenarios for the personas, imagining how our future design would fit into their workflows and facilitate communication.
Requirements
Based on our research, personas, and scenarios, we developed the following requirements. We determined our solution should:
build off of the functionality of current restaurant POS systems to minimize disruption in adopting our design.
allow for kitchen teams to update the timing and status of an order.
track and display orders in real time, enabling servers to monitor their orders.
provide notifications for delayed or changed orders to keep servers informed and manage customer expectations effectively.
allow servers to include special requests, modifications, and allergy information for orders.
allow servers to update or change orders after they have been sent in to the kitchen.
prompt kitchen staff to confirm allergy and modification information.
User Flows
To assist the process of creating preliminary wireframes, I developed task analysis flow diagrams that show how our proposed solution could be used by servers and chefs.
Kitchen Flow
Server Flow
Protoyping
Wireframes
To start floating ideas for the layout of our system, we began sketching wireframes individually before moving forward to digital prototypes. The following sketches I completed were used as the framework for the future prototypes, and were created with the flows from the diagrams above in mind.
Kitchen Flow
Server Flow
Digital Wireframes
Once we shared our ideas and sketches with each other, we decided to move forward with my concept. I began creating more fleshed out and refined wireframes in Figma, so that we could present a functional prototype for user evaluation. We also conducted a cognitive walkthrough of our main flows to ensure our design allowed users to complete their goals with the features provided.
Server Flow
Kitchen Flow
User Testing
Formative Evaluation: Incorporating User Feedback
We presented users with a functional prototype on Figma, and asked them to complete three main tasks:
Server
Take an order, adding modification and allergen details.
Submit an order, then edit it from the orders menu to include another modification.
Kitchen
Start an order, confirm order details, and update the prep-time to the pre-determined amount.
Acknowledge change made to order, and check which order was affected.
After conducting user testing with the tasks described above, we incorporated feedback from chefs and servers to improve our design. We gained further insights into what would and wouldn't work in a fast paced restaurant setting, and received recommendations to make the design more impactful for the users.
Insights & Redesigns
One of our participants with server experience explained that it is important to know the status of the kitchen before sending in an order so they can manage customer expectations accordingly. If they take several tables' orders without knowing the kitchen is backed up it can lead to further pileup on the chefs, unexpected wait times for customers, and misdirected frustration at the servers.
Redesign: We included a general estimated wait time display in the top banner based on the amount of orders the kitchen is currently working on.
When a server is editing an order, they were previously unable to add new items directly from the pop-up window. Instead, they had to go submit a new order, which is inefficient for the server. One of our users mentioned it would save time to be able to add an item to an existing open tab from this window.
Redesign: Following this feedback, I decided to alter the layout and structure of the order detail menu. The server now has the ability to cancel, edit, and add items in one place.
We were informed by a chef and restaurant owner in our user group informed us that restaurants cannot always accommodate allergy restrictions or special requests. The restaurant may not be able to fulfill these requests for a variety of reasons. Removing an ingredient could make the dish impossible to make (ex: you can't make an omelette without eggs), and some kitchen crews cannot spare the time or effectively meet a customer's allergy restrictions due to cross contamination.
Redesign: Based on this knowledge, I included an additional option to deny a request if the kitchen cannot accommodate it. Ideally, the server would not be able to add modifications or requests that are not possible, which could be determined by the kitchen when setting up the system. However, with the current state of the design, this was the most direct solution for the moment.
Future Directions and Limitations
Because this class was aimed at giving a broad overview of the user-centered design process, we only completed one iteration of research, prototyping, and testing. Further work should include further user testing with prototypes of increasing fidelity, and more iterations of the user-centered design life cycle.
Additionally, it would be beneficial to conduct more qualitative user research to better understand how these work flows are executed. Our interviews were the extent of the user research methods within the confines of this project, so it would be useful to develop a more comprehensive understanding of how the introduction of a new technology would impact the work environment.
Site by Jack Thomson made with Framer