Yelp Reservations
Party Cards, v3
Timeline
~2 months
Main Squad
Me (Lead PD)
Aditi (PM)
Huafei (iOS Eng)
Supporting Squad
Amy (PD)
Brian (Director of Product)
There's way more to Yelp than just restaurant reviews
Yelp has more products than just the consumer-facing mobile and web apps you may be familiar with. They have several other products, including a few products for restaurants like front-of-house software that helps restaurants manage diner flow. This product was called Yelp Reservations when I worked on it, but today it's called Yelp Guest Manager.
Back in 2017, Yelp acquired a startup called NoWait, a startup focused on restaurant waitlist management. Their product was very similar to Yelp Reservations, but almost entirely built around the busy restaurant use-case. Almost as soon as the acquisition went through, our team went to work to merge NoWait into Yelp Reservations.
Even a small component can represent something as important as you and your family
One of the many things our team needed to update was the party card component, which represents a party (a group of diners) in our most-used view on iPad. This component didn't support some of the new functionality we were inheriting from NoWait.
By updating this component, we would support our customers' hosts and hostesses and improve our competitive advantage with new waitlist features.
Obsess over inputs
Our account management team had been collecting feedback over a couple years, including feedback mentioning the data users would like to see in this component. The PM and I consolidated that feedback, the data the component currently supported, and the new data required for the waitlist use-case. Using Optimal Workshop, we then asked several of our existing customers and a few of our account managers with previous front-of-house experience to rate what data they considered to be "Must Have", "Nice to Have", and "Not Necessary" in the party card component. This would help inform our hierarchy.
The feedback from customers indicated there were additional opportunities for improvement as well:
How might we make status updates faster?
How might we show that new data hasn't synced with other devices?
How might we show the first to arrive among two parties who have the same reservation time?
Designing for power users
While waiting for results to come back from the Optimal Workshop research, I admittedly jumped the gun a bit to play what I call Wireframe Design Tetris™️.
A few promising solutions actually arose from this, specifically for the additional opportunities that didn't require insight on hierarchy. Once we had the results back from our research, I was able to stop playing Tetris and make data-informed decisions. After an iteration or two, and with feedback from Amy and the greater Yelp design team, this was the result:
(x2) 2m
Timoyee Tonobai..
--
2
306
Party
Size
Party
Name
Comms
Attributes
Time-related
Table #
In order to evaluate whether or not this new design was effective, we ran usability tests with 2 different hosts at 3 different restaurants. I made sure to test each use-case and edge-case in the prototype as well. On the left, we have the list of parties, which is what participants saw. The right is a key of what each icon means if you're curious (participants were not provided this until afterward).
Over 12 million people were packed into this small component
Across the board, each participant was able to tell us the most important aspects of what was happening in this prototype, but did need clarification around what some of the icons meant. Since our users quickly become power users, we were comfortable shipping these updates even though it would take time to fully learn.
A core principle for this product was to present information, not be prescriptive. We could have chosen to show what we believe is the most critical data about a party at a given time, and hide the rest behind a tap into its details. Instead, we managed to display a lot of data in a small component by being thoughtful about whitespace, type contrast, hierarchy, color, and iconography. Simplicity, or taking the burden from the user, is not always the best choice.
When I originally wrote this case study back in 2019, about a year after these updates had shipped, over 12 million diners had been seated. Since then, like any competitive digital product, this component has likely undergone many more improvements.