Hotel of Tomorrow
Redesigning the way waitstaff communicate with the back of house in hotel restaurants
Role & Duration
Product Designer
Human-robot Interaction, Product Design, Rapid Prototyping, Fusion 360, Hospitality Automation
Team:
1 Information Science Major (me!)
1 Mechanical Engineering Major
1 Electrical and Computer Engineering Major
Duration:
Oct 2021 – Dec 2021
Scenario #1: If the server is needed by the chef, Buzz's head will pop up and its foot will kick to alert the server. After a quick pat to signal they've received the call and are on the way, the head retracts back into the server pocket.
Overview
The Gettys Group Companies is a collective of hospitality industry professionals. As a part of their global design competition, HOT Ed™ Challenge, my team and I worked to identify opportunities for redesign within Cornell University's Statler Hotel.
We saw a major interaction issue in restaurant kitchens and as a result our work focused on communication systems, such as order ticketing and server paging.
Preliminary Ideation
After we conducted background and field research at various eateries on campus, there were a few questions we wanted to explore.
- How can different parts of a restaurant better communicate with each other?
- How can we change the dining experience for patrons + the work experience of staff to be more enjoyable, efficient, or easy?
Feedback, Round 1
Our professor and TAs critiqued:
- Early prototyping is meant to explore and ideate in the problem space, not to look for solutions. The aim of this stage is to have initial ideas to jump off of.
- The level of detail in prototypes should fit what is necessary to explore/learning process. Thus, early drafts shouldn't be as refined.
- We reflected as a team and agreed we were overeager in trying to solve potential problem spaces.
Going forward, we knew to adjust our design approach and view prototyping as a means of exploration.
Critical Function/Experience Prototype
Feedback, Round 2
While brainstorming questions that we could only answer through prototyping, we felt unsure whether we were designing for a contrived issue or even a "reasonable" problem space. What if no one really needs what we design?
We were advised to establish expertise on what problems can be made better:
- Identify what exactly is the issue, how it occurred, how often, and whether the system is currently satisfactory for users.
- Often existing systems just need a simple change to address the problem. (Ex: different colors for identical dishes on a ticket)
- Doesn't have to solve all kitchen problems.
- Doesn't need to be an entirely new/separate machine.
- Avoid overcomplicating the solution.
So, we scheduled a sit-down interview with the chefs and chose a day to observe the restaurant in action during dinner service.
CFP Overview
Critical Question: How can it be made easier to track the progression of an order?
Why? Restaurants need to prepare and serve food at peak freshness, which is only possible if orders are effectively / efficiently kept track of.
Pivoting Directions
Until this point we had explored design possibilities of the order ticketing system, but as a team we felt uninspired and constrained in this design space. Using interview insights from the chefs, we began ideating around the waitstaff's buzzer system.
Despite this change in direction we continued to focus on communication between parties of a restaurant.
Feedback, Round 3
Upon review, our TAs advised us to design in a way that enables 2-way interactions. So we not only want the robot to affect the server, but also for the server to affect the robot. What kinds of stimuli will result in user and/or robot reactions?
They stressed to remember storytelling holds precedence over practicality. There are justifications for speculativeness. There is significant value in exploring the complexities of human-robot interaction, while future work can focus on ergonomics.
Prototype Iteration
Many objects need a basic level of upkeep to keep using it—charging your phone overnight, taking your car in for an oil change, etc. Since the buzzer is also one of these objects, why not reimagine it to be a living being? This was a way to cultivate interactions between server and buzzer.
Feedback, Round 4
We had a chance to consult executives of The Gettys Group regarding the effects of device haptics and whether there's a way to alert users without disruption.
Rather than worrying about the intrusiveness of the buzzer companion, they suggested to find opportunities for visibility. They mentioned a likeness to the Pixar film Ratatouille and whether idle interactions could add another level of complexity.
Adding Visibility
If we utilize the shirt pocket vs. pants/apron pocket, we could employ visibility more effectively.
Design Evaluation Criteria
We conducted an internal evaluation of our design as it evolved and developed. Our evaluation criteria was based on prototype requirements + stakeholder needs, ranked on a scale of 1-5 (5 being the best).
- How well does it address issues of communication between FOH, BOH, and customers?
- How well does it address issues of charging/docking?
- How visible is it?
- How portable is it?
- How easy is it to learn/use?
- How likely would restaurants adopt the system?
- How practical is it?
- How interactive is it with customers?
Construction
Featured modules:
- photoresistor -> to simulate the buzzer being inside a pocket or taken out
- touch sensor -> to 'soothe': stop the poking/kicking and lower the head back out of view
- RF transceiver modules -> wirelessly control the buzzer's actions from Wizard of Oz interface.
- 2 potentiometers, one for the poking/kicking motion and the other moving the head.
Demo Videos
Scenario #1 (close-up): In addition to the head popping up in notice of a chef's call, Buzz's foot will kick as a tactile alert. This side view, water bottle representing the server, shows the movement of the foot against the server. A few pats soothes the buzzer and ceases its movement.
Scenario #2: When the server takes Buzz out from their pocket, its "foot" kicks to signal if it is taken out of the pocket it should be placed back in the charging dock. Otherwise, Buzz should be kept inside the server's pocket during a shift.
Wrapping Up
The key features of our concept establish companionability where typically not found and allow for new interactions with the technology that surrounds us. It reshapes how servers “care” for their buzzers, a reminder of its function as a conduit for vital communication during shifts.
Future Work
Adjust form factor. Utilize space more efficiently.
Conduct field studies. Observational trends will further develop interactions between user and robot.
Experiment with material selection. Consider different use cases and adjust factors accordingly.
Reflection
Although our team did not win the design challenge, it was a valuable experience. We learned to develop ideas through various prototyping techniques, resolve issues as a team, and collaborate with industry professionals.
Who are we designing for? In the beginning especially we were at a loss for what direction to go in. But keeping this consideration at the forefront ensured the design targeted real user needs, in addition to guiding us during the bumbling early stages.
Simultaneously, we want to focus on reimagining interactions between the user and robot, and vice versa, rather than the sole purpose of practicality and functionality. Design is supposed to explore and innovate, not simply solve.