Party Cells v3

This UI component is the bread and butter of the Yelp Reservations app – they represent our restaurant's guests. Those guests could have food allergies, they could be on their dessert course, they could have asked to add a few more people to their party, so on so forth to the tune of a seemingly endless number of possible combinations. Much of this information needs to be available at a glance.

So when the product team decided we would be adding more robust waitlist functionality to the reservations application, we knew we had to update this component to accommodate. Our design was not only confusing for the waitlist use case, but it simply didn't support some of the new functionality.

There were other opportunities worth tackling during the redesign as well:

• How might we make status updates faster?
• How might we improve the hierarchy of the information?
• How might we make the component scalable for more information in the future?
• How might we show that new information in a cell hasn't synced with other devices?
• How might we show who arrived first among two parties who arrived within a few minutes of each other and have the same reservation time?
• And how might we make all of this information legible without being an eyesore or cause cognitive overload?

Over the years, we'd collected some feedback regarding what information users would like to see in these cells. We consolidated that feedback, the  information the cell currently supported, and what was required for the waitlist use-case into a list. We then asked several of our existing customers (who are busy enough to go on waits) and a few of our account managers to rate what they considered to be "Must Have", "Nice to Have", and "Not Necessary". This would help inform our hierarchy and what could be progressively disclosed.

Our hierarchy was already good, but it was fragile when trying to add additional information. I explored several different options. Admittedly, I got overly attached to a few. Changing anything in a product that receives high engagement is always challenging, but when the vast majority of your users are power users, it can be pretty scary.

Initially, I had trouble juggling all of these things and aligning stakeholders on each item I was attempting to solve. By considering the cell's taxonomy and its natural groupings, the proposed solutions became much more clear.

In order to push this component to its limit, I created an example scenario that could happen in a restaurant that goes on a wait (one in a million chance). I made sure the scenario accounted for all the things I was solving for and all of the edge cases I could think of. This led to mockups with an actual story behind it.

One of the most sacred design principles on the reservations team is to offer the information, not be prescriptive. Hosts have a stressful job and need a tool to help them, not tell them how to do their job. We managed to cram a lot of information into a tiny area by being thoughtful about whitespace, type contrast, hierarchy, color, and iconography. Hosts were able to tell us exactly what was going on when viewing this example (and were quick to point out it would probably never happen).

I believe these changes solve for each issue well, all things considered. Over 4 million diners via Yelp have been seated since these changes went into effect. Another 8 million+ were seated who didn't make their reservation on Yelp. So let's agree that eleventy billion people left a restaurant probably full and probably happy thanks to a tiny bit of help from yours truly.

Other Projects