Work Play About Resume
←  All work
04 · Case Study

Airbnb Group Booking

Group trips shouldn’t fall apart before they start. We redesigned how Airbnb handles the hardest part: the money.

RoleProduct Designer
TypeConcept Redesign
Duration4 weeks
ToolsFill in
MethodsSurvey Research, Usability Testing, Hi-Fi Prototyping
DeliverablesSurvey study, group trip hub flows, three splitting models, hi-fi prototype
Problem
Group trips put the entire financial and logistical burden on one person, the one holding the credit card, which makes planning harder for everyone else too.
Insight
82% wanted to split “fairly,” but fair meant different things to different groups. Any single split model would alienate two-thirds of users, so the real decision was to let each group declare its own definition of fair up front.
Outcome
A group hub with three splitting modes, group sign-off before booking, and in-app messaging, moving power off the cardholder and onto the group. Testing validated the onboarding and flagged a need for clearer privacy affordances.

Airbnb has no real group booking. One person finds the place, one person pays for it, and one person spends the next three weeks chasing everyone else for money. The platform treats a group trip as a single transaction with a single customer, so every part of the coordination that makes a group trip hard happens somewhere else: a text thread, a spreadsheet, a payment app.

That structure doesn’t just inconvenience the organizer. It quietly removes agency from everyone else. If you didn’t book it you can’t see the reservation, can’t weigh in on the choice, and can’t tell whether your share has been counted.

We redesigned the experience from research through high-fidelity prototype, introducing shared planning, flexible cost-splitting and a centralized hub that gives every traveler visibility, not just the person holding the card.

Creating a shared wishlist for a group trip
Assigning beds among group members
Early splitting method selection
Property listing seen from a group member’s view
Early wishlist admin view
Early PayManage screen

We designed and distributed a structured survey to understand how people navigate group bookings now, not just the functional pain points but the social friction underneath them.

82% of respondents wanted to split costs fairly, and that finding killed the obvious solution immediately. Some meant even splits. Others meant proportional by room size or arrival date. A third group meant custom amounts they’d negotiated themselves. Any single split model would have alienated two-thirds of users no matter which one we picked.

63% wanted payment reminders, not because they’re forgetful, but because asking friends for money is uncomfortable. People wanted the platform to handle the follow-up so they didn’t have to.

71% wanted to share the planning workload. The organizer role is exhausting, and respondents wanted tools that distributed it rather than tools that made one person faster at it.

So the real decision wasn’t which split model is correct. It was that the split model is not ours to choose. Each group declares its own definition of fair at the start, and the product commits to it: EvenSplit for friends going halves, FairValue for proportional splits, PayManage for custom amounts.

The same logic drove the second decision. If the core problem is that one person carries the whole trip, then one person also shouldn’t be able to commit the group to it. Requiring group sign-off before booking is deliberate friction: slower to commit, but it moves the power off the cardholder and onto the group. That tradeoff is the argument the whole redesign rests on.

An earlier version of the wishlist admin view Cut
What I tried

Lorem ipsum dolor sit amet, consectetur adipiscing elit. The first version went wide before it went deep, and I built the whole thing out before testing whether the premise held.

Why it lost

Sed do eiusmod tempor incididunt ut labore. It tested as more work than the thing it replaced, which is the one result a redesign cannot survive.

What replaced it

Ut enim ad minim veniam, quis nostrud exercitation. The version I kept held on to the intent and threw out the scaffolding around it.

Group wishlist onboarding
Group approvals before booking
Trip messages overview
Joining a trip and paying a share
Trip details with per-member budget
A trip message thread

Three moves carry the redesign, and each one takes something the organizer was doing alone and hands it to the group.

The group picks its definition of fair before anyone pays. EvenSplit for straight halves, FairValue for proportional splits by room or by nights, PayManage for custom amounts. Choosing the model up front turns the most uncomfortable conversation of the trip into a setup step.

A shared wishlist, voting, and end-to-end visibility, with group sign-off required before anything books. Every member can see the reservation, the budget and where their share stands, which is the part the old flow never gave them.

Group trips normally get planned in a WhatsApp thread while the booking happens somewhere else, so context splits in two. Messaging moved into the trip flow itself, with notifications scoped to the trip, so the conversation and the decision finally sit in the same place.

Seamless group onboarding. Building the group feature into the wishlist flow meant users never had to learn a separate concept. They started group trips without being told how.

Clarity drives confidence. EvenSplit and FairValue were well received for their simplicity. PayManage caused hesitation: users weren’t sure who could see what, which pointed to a need for clearer affordances around privacy and transparency.

Feedback and visibility matter. Users missed the comments section and expected notifications for group actions. When someone joins, approves or pays, the group should know.

The most useful thing this project taught me is that the obvious solution is worth killing early. We went in assuming the job was to build a good cost-splitting feature, and the survey turned that into a much better question: whose definition of fair does the product encode? Once we stopped trying to answer it for people, most of the rest of the design followed.

The part I’d push harder on is the privacy hesitation PayManage surfaced. We identified it and didn’t get to resolve it. If I picked this back up, that’s where I’d start: a group can only share money honestly if everyone knows exactly who can see what.