PRINCIPAL DESIGNER
2023
WEB & iOS
Problem
Restaurants seat hundreds of guests per night. When reservations come in, OpenTable automatically places them on appropriate tables. Over the course of the shift the system may move reservations around if a better option opens up, especially if that move ensures another diner can be seated. This is colloquially called “tetris-ing.” Restaurants need tools that allow them to leverage OpenTable’s processing power while providing human insight to optimize their seating capacity for their needs.
Solution
No matter how optimized the system is, humans are at the heart of hospitality. They are going to know if a table is about to get up or if a guest asked to swap tables. Smart Assign gets these humans involved by enabling them to lock certain reservations in place or suggest table placements—all while the system continues to look for optimizations to seat more guests.
Role
I led design for Web and iOS throughout this project. I also led three rounds of research with restaurants. I delivered in depth guides, prototypes, and nine video walkthroughs that documented every permutation of the smart assign work to ensure our engineering partners had clarity while building. The project launched in September 2023.
Insight
We collaborated with a Restaurant Group (a collection of restaurants under one company) that operate with a large amount of reservations. We met once a month to review process and get feedback. This was a successful partnership. We learned about detailed use cases and even leveraged their language to name the actions. We learned:
Design
Result
Learning
One wrong tap
Assigning a reservation happens millions of times a day for tens of thousands of restaurants on the OpenTable platform. Any update to this area of the app is under immense scrutiny—even still things slip through. During beta, we inadvertently introduced an extra tap in the assigning workflow. While it may not seem like much, that extra tap added valuable seconds that our hosts and General managers did not have to spare. We got an immediate reaction. With a small group of engineers we reworked the designs and workflows and shipped an update during the next sprint.
Too focused
Our beta was very focused on the types of restaurants that we interviewed with, when we launched to a larger segment we discovered a majority restaurants were using the actions in unexpected ways which guided us to changing the order of some of the actions to appeal to the majority of users.
Locked up
I was surprised by the high adoption of the lock feature. Restaurants could achieve a similar result by assigning a reservation. I believe the visualization of a lock helped provide crystal clear communication to their teams. And that communication when working in a fast-paced environment means they can spend less time behind a screen and more time in front of their guests.
As a team we felt this was an important initiative. We built our case around why we should make this investment and why we should make it now. We used the product as our customers do and presented clips of our interviews in the next planning meeting. Seeing the frustrated looks as our customers used the existing product and the hopefulness of their voice as they used our proposed vision was enough to convince that stakeholder that this was worth building.