Resy Celebrations: Making in‑app large party reservations simpler
- Role
- UX Researcher • Product Designer • Prototyping
- Platform
- Mobile feature, inside the existing Resy app
- Timeline
- Semester 3 course project | Team of 4, I led direction and owned research
What is Resy Celebrations?
My Role
This is an independent concept. It was made for a university UX course and is not affiliated with, commissioned by, or endorsed by Resy. Nothing here shipped. The Resy name is used only to describe the product the concept was designed against.
Context
Booking a table for 2 on Resy takes seconds. Booking for 15 sends you to your email.
“There's no infrastructure inside Resy for the one kind of booking that needs it most.”
For groups of 8 or more, most restaurants can't confirm through the app. Resy caps the party size and tells you to email the restaurant directly. So the thing Resy is good at, fast and clear booking, quietly stops right at the point where a group dinner gets hard to coordinate.
The problem found me before the project did. My birthday was coming up and I was trying to book a group dinner in New York. Once I set the party size past 6 on Resy and OpenTable, both apps told me to email the restaurant. So I did. Most took 2-3 days to reply, some never did, and a lot of them didn't list a phone number at all. When they did write back, it was usually a hefty per-person quote I had no way to see coming. My partner and I gave up and went to the Lower East Side and East Village in person, walking into bars to ask about minimum spends and availability. We got more in an afternoon on foot than in a week of emails.
The fastest way to see the gap is to lay the two sides next to each other. Both are trying to reach the same outcome. Neither has anywhere to do it.
Booking a large party today
Guest
- 01Sets party size past 6Resy hands off to email
- 02Emails several restaurantsOften with no phone number listed
- 03Waits 2-3 days for a replySome never respond
- 04Finds out the minimum spendThree emails deep, if at all
- 05Books whoever answered firstOr gives up
Restaurant
- 01Receives an unstructured emailNo event type, no headcount
- 02Asks follow-up questionsMenu, space, dietary needs, timing
- 03Quotes the minimum spendMost guests disappear here
- 04Holds the space on trustNo commitment from the guest
- 05Tracks it all in an inboxNowhere else for it to live
Email isn't just one slow step here. Almost everything that matters to either side happens there, outside the product.
Research
I ran a survey to define who this was for, then two rounds of interviews: 15 users first, then 6 restaurant managers across Brooklyn and Manhattan.
From the survey
The thing that would decide whether a place was even an option, the minimum spend and the policy, was the one thing you couldn't see until you'd already spent the effort to ask.
The survey also decided the target. Students dropped out fast. Most don't use Resy because it wants a card on file, and a sit-down dinner for 15 isn't in the budget. That left working professionals, roughly 29-33. The user interviews confirmed the pattern: everyone had tried Resy for a big group at some point, almost nobody had booked through it. The words that kept coming up were “waiting,” “hidden costs,” and “I didn't even know if it was confirmed.”
“If guests saw sample menus, pricing, and policies before emailing us, that would filter out groups who aren't serious.”
Manager, Convivium Osteria
The Insight
We almost didn't interview restaurant managers. My professor pushed us past the user side to talk to the people running these rooms. That's where the problem got more interesting.
The managers were open to large bookings, but they were doing a lot of work Resy had no infrastructure for. Event type, seating, dietary needs, minimum spend, prix fixe. None of it fits a standard reservation. So they took the conversation to email, because email was the only place it could happen.
The back-and-forth email wasn't really the problem. Resy just didn't have anywhere for restaurants and guests to exchange the specifics at all. Once I saw that, I understood I couldn't fix the user's side by speeding up email. The fix had to give both sides a place to have the conversation Resy had been pushing off the platform.
How might we
Help users book and manage a large-party reservation inside Resy, instead of routing them back to email?
Design Decisions
Every decision below answers the same thing. Underneath the logistics, this is a trust problem, and it isn't symmetrical. Both sides are being asked to commit before the other one has.
The trust gap
The guest risks
Committing a group of 12 to a place they can't picture, at a price they can't see, through a channel that gives them no confirmation. The frustration that came up most was less about cost and more about not knowing whether anything was actually booked.
The restaurant risks
Holding a room, staffing it, and prepping a set menu for a party that may not arrive. The managers described this directly: minimum spends, kitchen strain, staffing, no-show risk. Keeping bookings of 8+ on email is one of the few ways they have to screen them.
The restaurant side turned out to be enormous, an operational problem in its own right. Solving all of it was never the scope of a research course project. What the manager research did was let me design a grounded, hypothetical experience for their side, built on what they actually told us, without pretending I'd solved restaurant operations. The user was the problem I was solving. The managers were the context that made the user's side designable.
Deposits and the card hold
A restaurant will accept a large party when the party has committed to something. That is the entire reason the 8+ gate exists. Everything upstream in this design (the preference-first flow, the structured request, the manager dashboard) only earns a “yes” if there's something at the end of it that makes the booking real for the restaurant, not just for the guest.
What the design does carry: once a booking is confirmed, it becomes a shared space. The host sends an RSVP link through the app, guests confirm and split any deposit in-app, and the restaurant's headcount updates automatically before the cutoff. That solves the guest-side half. Nobody is chasing 12 people on Venmo, and the restaurant gets a live headcount instead of a number from three weeks ago.
Who has committed what, stage by stage
Request sent
Guest
Preferences and a headcount
Restaurant
Nothing yet. The request is just sitting there
Restaurant accepts
Guest
Still nothing at stake
Restaurant
A room, a date, and a set menu held open
The mechanism
Card held, not charged
Guest
A card on file against the minimum spend
Restaurant
Staffing and prep committed against a real booking
Night of
Guest
Deposit split across the group, settled on arrival
Restaurant
A live headcount instead of a three-week-old number
The prototype now has the hold. Once the restaurant says yes, the guest holds a card against the minimum. Nothing is charged, and it's only taken if the group cancels late or doesn't show. That's the moment the booking becomes real for the restaurant, and their dashboard marks it guaranteed instead of just accepted. Until the guest holds a card, the tracker stops one step short of confirmed. That was the sharpest note this project got, and it's a fair one, so it was the first thing I built after the course.
The four decisions this made possible
01
Celebrations as its own mode, not a filter
Not a party-size filter bolted onto the existing reservation flow
A large-group booking isn't a bigger version of a table for two. It carries different information, a longer timeline, and higher stakes on both sides. A dedicated tab says that upfront, to guests and restaurants both.
Research6 manager interviews. Every one described 8+ as a different job, not a bigger one
02
Ask what you're planning before showing a single restaurant
Not results first, filters after, the way most discovery flows work
People were reaching out to places that could never have held them, and only finding out three emails deep. Collecting event type, size, date, budget and vibe first means every result on screen is already a real option, with minimum spend and capacity on the card.
Research67% didn't learn the minimum spend or policy until after they'd already reached out
03
A structured request, and a dashboard for the restaurant to answer it
Not speeding up the email thread, or auto-confirming large parties
The email was never the point. There was just nowhere else for that conversation to live. The guest sends event type, headcount, dietary needs and timing as fields, and the restaurant accepts, counters, or declines without touching their inbox. Input stays light while you're inquiring and only steps up once the restaurant says yes.
ResearchAll 6 managers described the same inbox workaround, independently
04
The confirmed booking becomes a shared space, not a receipt
Not one host on the hook for the deposit, chasing twelve people on Venmo
The host sends an RSVP link through the app, guests confirm and split the deposit in-app, and the restaurant's headcount updates automatically before the cutoff. The restaurant stops planning against a number that's three weeks old.
ResearchManagers named no-shows and stale headcounts as the two costs of saying yes
The Product
Resy Celebrations is a dedicated tab inside Resy for groups of 8 or more. It's its own mode, so both the guest and the restaurant know this is a different kind of booking. Here's the same workflow again, from both sides.
Booking a large party through Celebrations
Guest
- 01Says what they're planningEvent type, size, date, budget, vibe
- 02Browses only real optionsMinimum spend and capacity on every card
- 03Sends one structured requestNot an email into the void
- 04Watches the status moveA tracker, not a refreshed inbox
- 05Shares an RSVP linkGuests confirm and split the deposit in-app
Restaurant
- 01Receives a pre-filled requestEvery field they'd have had to ask for
- 02Accepts, counters, or declinesWithout touching their inbox
- 03Publishes policies upfrontFilters out groups who aren't serious
- 04Sees a live headcountUpdated automatically before the cutoff
- 05Works from a dashboardSomewhere for the conversation to live
“The whole feature does one thing the old flow couldn't: it keeps the guest and the restaurant in the same place long enough to actually agree on a plan.”
Give it a try
This is the working hi-fi prototype, so you can actually use it. Set your preferences, browse the matches that fit your party, and send a request. Then open the restaurant's dashboard, accept or counter your own inquiry, and watch your tracker move. Both sides read the same data.
A concept prototype. It is not connected to Resy, and no real reservation is made.
Where it landed
The scope of this project was needfinding and proposing a solution, so that's what the course asked for and what we delivered: research across 15 users and 6 managers, a survey, synthesis, personas, current and future journey maps, and a lo-fi prototype covering the full flow on both sides. The hi-fi prototype in this case study I built after the course, on my own, to take the proposed solution from a flow into something you can actually move through.
What didn't work
The course version didn't go far enough on protecting restaurants from no-shows and last-minute cancellations. I understood that risk from the manager research but didn't design for it until the hi-fi prototype, which added the card hold.
The original swipe-to-browse mechanic got fair pushback for working better as discovery than as a primary way to choose a high-stakes booking, which is why the current version uses Resy's list and map instead.
We carried one persona too many, with two that overlapped.
What I'd do next
Put it in front of people. Everything in this prototype is built on interviews, but nobody has used it yet. I'd run short sessions with 3-5 people who've organized a group dinner recently, give them a real occasion to plan, and watch where they stop. The hold is the part I'm least sure of.
Talk to someone at Resy. We understood the problem cold from the guest and restaurant sides and never pressure-tested whether it was viable for Resy as a business. Is the 8+ gap a technical limit, a strategic choice, or a resource call? I don't know, and not knowing is the biggest hole in the argument.
Defend the scope out loud. We debated sit-down dinners versus standing events early on and chose 8-15 sit-down. I still think that was right, but the case study currently assumes it rather than making the case.
What I took away
“You can't design one side of a transaction well without understanding what the other side actually needs.”
This was my first two-sided problem, and I didn't really understand what that meant until I was inside it. The moment the restaurant side came in, almost every decision I'd made for the user had to be reconsidered.