Process · Foundation
Four experiments that set the way.
Before designing a customisation flow, I needed to establish whether users would engage with preferences at all inside the room selection context.
Rather than building a full solution immediately, I structured a sequence of experiments that progressively increased intervention complexity — each one informing the next.
The initial card design made no mention of the possibility of customising the bed type, a key gap in communicating available options to the user.
The smallest testable hypothesis: not whether users would customise, but whether they noticed that options existed. I surfaced bed type options as static information on the room card — no selection mechanic. This isolated the impact of awareness alone.
Design challenge: bed configurations varied significantly. Presenting all options in a single line became unreadable for edge cases. I proposed displaying each option on its own line to preserve clarity across all configurations.
Building on positive awareness signals, I brought preference selection directly into the room card. Focus: bed type — the most requested room-level preference, already an established pattern on Desktop. This tested whether users would engage when given immediate, inline control.
+4,282 bookings with bed preference
A key team discussion: what should the default selection be? I decided to make "No preference" the explicit default. Auto-selecting a bed type for every eligible room would have generated unintentional requests at scale, driving up partner workload and pushing down reply rates — directly undermining the review score improvement the feature was designed to produce.
Trade-off: lower apparent engagement to protect partner experience
As the room card began carrying more interactive elements, I restructured its IA: Static information (details, conditions, pricing) moved to the top. Interactive elements (preference selection, number of rooms, room CTA) moved to the bottom. Clear separation between reading and deciding.
+47 bookings · Structural foundation established
The limits of the Room Card
Even two preferences would significantly increase card height, hurting scannability and comparison. Past A/B tests confirmed this — small height increases consistently hurt conversion — so this direction was discarded early.
Base room card
Adding two preferences easily doubled the room card height.
Dropdown helped to keep the height short but required multiple taps to select options.
Chip-based multi-select at the bottom of the card.
Decision
Back to basics.
Both containers had been built to hold multiple preferences, future-proofed for a roadmap that wasn't arriving on schedule. The structural complexity was creating friction for what was, at that moment, a single-choice task.
I took the single-screen structure of Variant 2 and replaced the complex input components with radio buttons — the simplest possible interaction for selecting one option. No dropdown overhead. No container designed for a future that wasn't here yet.
+5% preference-matched bookingsThis iteration went full-on.
The question shifted from what to how.
With the single-screen customiser proven commercially, the question shifted to flow structure. I evaluated alternatives and narrowed to three, before pushing back on the PM's plan to improve single-screen first — optimising a foundation we already knew would be replaced gave no useful signal.
Show every available customisation option on a single screen
Discarded · Customisation flow complexitySequential screens per customisation, inspired by e-commerce product detail patterns. Ruled out: the room detail page was already dense.
Discarded · Room page complexityEach customisation in its own dedicated screen, inspired by airline booking flows. Tested in its raw state to get a clean read on whether the structural approach itself was valid — not an optimised version of a design we'd replace.
Full-on · Validated the multi-step customisation hypothesis