Users selecting a room option faced two distinct problems:

The findability problem: Properties offered too many room-rate combinations, each presented as a separate vertical card. With some properties offering over 16 options, most users never explored beyond the first few.

The comparability problem: Many rooms shared the same amenities and size, giving users no reliable way to understand what differentiated one rate from another. When users could not find meaningful differences between the cheapest option and higher-value rooms, they settled for the first one they saw. The property shown below, for example, offers the same Family Room 8 different times, with minimal differences between options. Roughly 65% of users defaulted to booking the cheapest option. In post-checkout research, around 30% of users said they believed they had booked a free cancellation rate when they had not.

Choice overload in Room Selection had been a known problem for years, with multiple attempts to address it that never proved successful.

During H1, Room Selection designers were asked to come up with alternative designs: Filters Android, Filters iOS, Rate Selection, Horizontal Comparison and Multiple Choice.

I worked on both Filters concepts and continued into Two-Step Selection. Two other designers worked on the remaining concepts. Horizontal Comparison, tested in Mobile Web, emerged as the most promising approach.

During H2 I was asked to make a plan to implement the chosen solution in both Android and iOS.

iOS required four iterations before fullon. Family traffic was identified as a risk early. During the component audit and prework phase, I drafted multiple ways we could incorporate Families content into the new Room details IA.

I presented the alternatives to Families and Policies teams, but couldn't reach alignment. I had proposed consolidating all rate details into the Booking Conditions screen, which Families team supported. Policies pushed back. They owned the screen, had run their own experiments optimizing it, and adding family content risked competing for attention with theirs. Without agreement, we excluded family traffic from the first iteration, our MVP, to avoid delaying the core hypothesis test.

In parallel, I worked on two fronts: a short-term solution to unblock iteration 2, and ongoing discussions to align on a longer-term IA vision. The short-term solution, a one-line summary with an info icon, landed for iteration 2. The longer-term vision had gained support from Policies, Families, and Web by the time I left. Subsequent iterations refined tap targets, thumbnail size, and performance before meeting fullon criteria on iteration 4.

Android

The Android experiment reached full traffic after 9 days. The primary metric, booked non-cheapest rate, increased by +4.54% (V1) and +4.82% (V2), representing +3,118±120 additional bookings per day. PNC, our property-net-conversion guardrail, was non-inferior.

Over 86% of Android users scrolled horizontally, validating the core discoverability hypothesis that had been flagged as a risk in research. Traffic to the room details screen increased by over 20%, suggesting users were exploring more before booking rather than defaulting to the first option they saw.

One known trade-off: multi-room bookings with different rates were deprioritised, and that use case dropped 8.29% — acknowledged and flagged as a future iteration.

iOS

The iOS experiment ran for five weeks plus a two-week measurement period before reaching full traffic. The primary metric, booked non-cheapest rate, increased by +2.91%±0.22%, representing +5,614 additional bookings per day. PNC was non-inferior, with a small overrun on the accepted cost threshold that leadership reviewed and approved given the opportunity cost of further delay.

Over 80% of iOS users scrolled horizontally, consistent with Android and confirming the discoverability behaviour held across platforms.

iOS initially shipped with multi-room support. The copywriter and I flagged that the interaction was error-prone and made the case to remove it; the PM agreed and we dropped it in a later iteration.

Consolidate rate details into a single screen

Travelers shouldn't have to bounce between views to piece together what a rate actually includes. A short-term version shipped during fullon, but that was a patch, the lasting fix was to bring everything that defines a rate into one structured place.

Extract common rate information to make rates comparable

When the same core facts sit in the same spot on every rate, comparison becomes a quick scan instead of a hunt, travelers weigh one rate against another without re-reading each from scratch.

Let travelers read the rate card without friction

Several teams had each built their own icon-and-text pattern, and grouped together those differences pulled the eye away from the content. One consistent pattern lets travelers take in a rate's details in a single smooth pass.

This project was the most complex stakeholder environment I'd worked in at Booking.com: six teams, two platforms, ~100 components, and a hypothesis that had already struggled to ship elsewhere.

The decision to audit and de-risk before experimenting came from recognizing that a failed experiment on a cluttered baseline would tell us almost nothing. The sequencing mattered as much as the design.

If I were doing it again, I'd push earlier for a clearer answer on the Families use case. Excluding traffic solves a short-term problem but creates a gap that compounds over iterations.

Finally, it's easy to underestimate Foundational work. IA experiments were initially seen as design debt cleanup, and the Apps adaptation was regularly referred to in meetings as a port. I was asked more than once whether I was simply copying the Web design as closely as possible. Both initiatives ended up producing the most concrete results. This project reinforced my belief that foundational decisions, even unglamorous ones, are often where the real impact lives.