Resy Celebrations

I was planning my own birthday dinner in New York and somehow ended up doing venue scouting on foot. That's when I knew something was broken.

We started with a survey to figure out who we were designing for. Students dropped out of our target group fast. Most don't use Resy because the app requires a credit card on file, and the budget for a sit-down dinner for 15 just isn't there. That pointed us toward working professionals in NYC, ages 24-35.

From there we ran two rounds of interviews: consumers first, then restaurant managers. The consumer side confirmed what I already knew. Everyone had tried Resy for a large group at some point. None of them had actually booked through it. They'd all ended up calling, emailing, or just picking whatever restaurant responded first.

The restaurant interviews were the ones that changed how we saw the problem. We talked to four Brooklyn restaurants: Nuaa Table, Wayward Fare, Convivium Osteria, and La Rina. Every single manager said the same thing: Resy works fine for regular tables, but for groups of 8 or more, it can't collect what they actually need. Event type. Space preference. Menu selection. Minimum spend. None of it is in the standard flow. So guests email, find out the policies, and most of them disappear. One manager put it plainly: “If guests saw pricing and policies before emailing us, that would filter out groups who aren't serious.”

We almost didn't interview restaurant managers. Our professor pushed us to go beyond the user side and actually talk to the people running these places.

That's when the problem got more interesting.

The managers weren't refusing large bookings. They were doing work that Resy had no infrastructure for. Event type, seating preferences, dietary needs, minimum spend: none of it fits a standard reservation flow. So they took it to email because that was the only place that conversation could happen.

The back-and-forth email wasn't the problem alone. Resy just didn't have a way for restaurants and users to communicate the specifics at all. Once we understood that, we knew the solution had to work for both sides, not just the user.

Resy Celebrations is a dedicated tab inside the existing Resy app for groups of 8 or more. Not a filter, not a workaround. A separate mode that signals to both the user and the restaurant that this is a different kind of booking.

A user opening Celebrations first tells the app what they're looking for: event type, party size, date, rough budget, vibe. That input filters the restaurant results before they even appear, so everything shown is already a realistic option.

From there, browsing happens through swipe cards. Each card has the minimum spend, capacity, layout previews, and a Celebrations badge if the restaurant has opted in and shared their policies upfront. No hidden costs discovered 3 emails later.

When a user finds a place they want, they send a structured in-app request instead of an email. Party size, event type, dietary needs, budget range, timing. The restaurant receives this through a manager dashboard and can respond, counter-propose, or decline without leaving the platform. The user sees the status update in real time through a progress tracker.

Once confirmed, the booking becomes a shared space. The host sends an RSVP link to the group through the app. Guests confirm attendance and split any upfront deposit in-app. The restaurant sees the headcount update automatically if anything changes before the cutoff window.

The project delivered end-to-end research: consumer and restaurant manager interviews, an online survey, affinity mapping, personas, user journey mapping, and a lo-fi prototype covering the full booking flow for both sides.

The feedback from our professor and class was largely positive. Two things stood out. First, the solution didn't go far enough in showing how Resy Celebrations protects restaurants from no-shows and last-minute cancellations. We understood the restaurant side through research but didn't fully translate that into the design. Second, the swipe mechanic got some valid pushback. A few reviewers felt it worked better as a discovery tool than a primary interaction pattern, which is a fair read.

Our professor also noted we had one persona too many, with two of them overlapping more than they needed to.

I'd have tried to speak to someone at Resy. We understood the problem from both the user and restaurant side, but we never pressure-tested whether the solution was actually viable for Resy as a business. Why does this gap exist on their end? Is it a technical constraint, a strategic choice, a resource problem? That conversation would have made the solution a lot sharper.