A flexible-dates feature for an online accommodation-booking platform (think Airbnb). Read this for product thinking and how I prove a change actually worked.
Jabama is an Airbnb-style accommodation platform with 8M+ installs and 1M+ monthly active users, where almost every session starts with a date search.
The pattern showed up in telemetry before anyone named it. A large share of searchers would open the date picker, change the dates, glance at the results, close it, reopen it, change the dates again, and repeat this several times before committing to anything. These weren’t lost users drifting at the top of the funnel; they were deep in it, clearly intending to book, and stuck on the calendar. Internally we started calling it date-thrashing: high intent, no movement.
The instinct most teams have here is to make the picker faster or prettier, which treats the symptom. The question worth sitting with was why a high-intent user would poke at the same screen five times instead of booking.
The instinct most teams have here is to make the picker faster or prettier, which treats the symptom. The question worth sitting with was why a high-intent user would poke at the same screen five times instead of booking.
Why It Was Happening
Talking to users made the answer obvious in hindsight: people don’t anchor on dates, they anchor on a trip. “A long weekend in mid-June.” “Four nights sometime that week.” The exact dates they type are a guess, a first probe, and they’re manually testing whether nudging the window a day either way unlocks better availability or a better price. We had quietly forced every user to run the search algorithm by hand, one date-pair at a time.
The deeper insight, and the one the whole design hangs on, is that the two ends of a trip are not psychologically equal.
Check-in is rigid. It’s pinned to the real world: a flight that lands at a fixed time, a Friday after work, the first morning of a conference. You can’t arrive before you’ve arrived. Asking someone to move their check-in earlier is asking them to be somewhere they aren’t yet.
Check-out is elastic. “I’d happily stay an extra night if it’s cheaper, or if that’s what’s open” is one of the easiest yeses in all of travel. An extra day at the end reads as a bonus, not a compromise.
That asymmetry, arrival anchored and departure elastic, became the spine of the design, and it’s the reason the flexibility extends the way it does instead of spreading evenly.
The deeper insight, and the one the whole design hangs on, is that the two ends of a trip are not psychologically equal.
Check-in is rigid. It’s pinned to the real world: a flight that lands at a fixed time, a Friday after work, the first morning of a conference. You can’t arrive before you’ve arrived. Asking someone to move their check-in earlier is asking them to be somewhere they aren’t yet.
Check-out is elastic. “I’d happily stay an extra night if it’s cheaper, or if that’s what’s open” is one of the easiest yeses in all of travel. An extra day at the end reads as a bonus, not a compromise.
That asymmetry, arrival anchored and departure elastic, became the spine of the design, and it’s the reason the flexibility extends the way it does instead of spreading evenly.
The Design Decision
The naive version, which we considered and rejected, was to widen the search by N days on both ends and show everything inside that box. Two things kill it. It explodes the results into options you can’t compare: a two-night stay next to a five-night stay next to a three-night one, all jumbled, so the user has to do more mental work, not less. And it shatters the user’s own model of “my trip” into a pile of unrelated date pairs.
So the feature rests on two principles instead.
Preserve the trip, slide the window. Flexibility keeps the length of the stay fixed, a two-night search stays two nights, and floats only the start. Every result is then apples-to-apples: the same trip, shifted, so the only variable the user weighs is price and availability. That’s a decision a person can make in a second, which is the entire point.
Spend the flexibility forward. Because departure is the elastic edge, “two days flexible” does not mean a symmetric two days in each direction. It leans into the future. Two days of flexibility might mean about a day earlier and three days later, extending past the planned check-out more generously than it pulls check-in earlier. We’re spending the user’s flexibility budget where they’re genuinely willing to move, and not wasting it asking them to arrive before they can. A symmetric window looks tidier on paper; the weighted one matches how people actually negotiate with their own calendar.
The control itself is four discrete chips, 1, 2, 3, 4 days, rather than a slider. A slider implies a precision the user doesn’t have and quietly re-invites the exact thrashing we set out to kill. Each chip maps to a real intent instead: one is “barely flexible, I mostly know when I’m going,” four is “honestly, I’ll go whenever’s cheapest that week.” And the cap at four is itself a decision. Beyond roughly four days the “same trip, shifted” frame breaks down. A week of drift isn’t “my mid-June weekend” anymore, it’s a different trip, and that user is better served by a price-calendar or whole-month view, which is a separate feature with a separate mental model. Knowing where your feature ends mattered as much as knowing what it does.
So the feature rests on two principles instead.
Preserve the trip, slide the window. Flexibility keeps the length of the stay fixed, a two-night search stays two nights, and floats only the start. Every result is then apples-to-apples: the same trip, shifted, so the only variable the user weighs is price and availability. That’s a decision a person can make in a second, which is the entire point.
Spend the flexibility forward. Because departure is the elastic edge, “two days flexible” does not mean a symmetric two days in each direction. It leans into the future. Two days of flexibility might mean about a day earlier and three days later, extending past the planned check-out more generously than it pulls check-in earlier. We’re spending the user’s flexibility budget where they’re genuinely willing to move, and not wasting it asking them to arrive before they can. A symmetric window looks tidier on paper; the weighted one matches how people actually negotiate with their own calendar.
The control itself is four discrete chips, 1, 2, 3, 4 days, rather than a slider. A slider implies a precision the user doesn’t have and quietly re-invites the exact thrashing we set out to kill. Each chip maps to a real intent instead: one is “barely flexible, I mostly know when I’m going,” four is “honestly, I’ll go whenever’s cheapest that week.” And the cap at four is itself a decision. Beyond roughly four days the “same trip, shifted” frame breaks down. A week of drift isn’t “my mid-June weekend” anymore, it’s a different trip, and that user is better served by a price-calendar or whole-month view, which is a separate feature with a separate mental model. Knowing where your feature ends mattered as much as knowing what it does.
The full flow: tapping each flexibility chip resolves the weighted window live, then results return as same-length trips, each labeled with its actual dates and its price delta against the original search.
Making the Shift Legible
A flexible search can disorient as easily as it helps: if results quietly come back for dates the user never typed, trust evaporates. So the original requested dates stay pinned at the top as the reference anchor, and every result states its own actual dates and its delta against the original in plain terms: “Jun 11–14 · same 2 nights · 18% less.” The shift is never something the user has to reverse-engineer; it’s labeled, compared, and reversible in one tap back to exact dates.
Discovery follows the same logic. Flexibility isn’t a buried toggle hoping to be found. It surfaces contextually, exactly where the behavior already happens. When we detect thrashing (several date changes in a session) or a thin and zero result set, an inline prompt appears: “Flexible? See nearby dates.” We met the behavior at the moment it occurs rather than relying on users to discover a setting, which is also why the feature’s adoption story is tied directly to the signal that justified it.
And the edge case got real attention, because a flexibility feature that dead-ends is worse than none. When even the widened window finds nothing, we never show an empty shrug. Chips that would return zero inventory render disabled rather than lying about options, and the experience points to the nearest genuinely available window instead of leaving the user at a wall.
Discovery follows the same logic. Flexibility isn’t a buried toggle hoping to be found. It surfaces contextually, exactly where the behavior already happens. When we detect thrashing (several date changes in a session) or a thin and zero result set, an inline prompt appears: “Flexible? See nearby dates.” We met the behavior at the moment it occurs rather than relying on users to discover a setting, which is also why the feature’s adoption story is tied directly to the signal that justified it.
And the edge case got real attention, because a flexibility feature that dead-ends is worse than none. When even the widened window finds nothing, we never show an empty shrug. Chips that would return zero inventory render disabled rather than lying about options, and the experience points to the nearest genuinely available window instead of leaving the user at a wall.
The Engineering Reality, and Why Design Owned It
Searching a window of date combinations costs several times more than searching one, and left alone that tax lands on latency, and a flexible search that’s slow defeats its own reason for existing. I worked directly with the two engineers to precompute and cache availability across the window so the results page stayed as fast as a normal search. I’m putting this in the case study deliberately: the design isn’t real until it ships at speed, and owning that constraint alongside engineering is half of what the role actually is.
Getting the Org Aligned
The hardest conversation wasn’t with users, it was with our revenue partner, who was convinced flexibility would erode average daily rate by quietly nudging everyone toward the cheapest dates. Rather than argue it as a matter of opinion, I reframed what the feature was actually for: it converts the sessions that would have bounced, the thrashers who leave without booking, not the people already happy to book their exact dates. The bet wasn’t “discount existing demand,” it was “recover abandoned demand.” We turned the disagreement into something measurable by making ADR a hard launch guardrail, so if he was right, the data would say so and we’d pull it. That move, converting a stalemate of opinions into a falsifiable bet, is what unblocked the launch.
How We Measured It
The easy trap is to measure usage, like “twelve percent of sessions tapped a flex chip,” which tells you nothing about whether the thing worked. We anchored on causal impact instead.
The primary metric was search-to-booking conversion for thrash-intent sessions, measured against a 50% holdout, with the session as the unit and a multi-week run to wash out the novelty bump.
Underneath that we tracked a mechanism metric: date-picker re-open rate. If the feature works for the reason we believe, thrashing should fall, and that’s what separates “conversion went up” from “conversion went up because we removed the manual search.” Without the mechanism metric you can’t tell whether you fixed the problem or simply got lucky in the same window.
And we held the launch to a set of guardrails, because a flexible-dates feature has obvious ways to win on the surface while quietly costing the business: average daily rate and trip value (did we just bleed revenue toward cheaper dates?), cancellation rate (are flexible bookings lower-intent and more likely to fall through?), and zero-result rate and latency (did the heavier query degrade the very page it was meant to improve?). A result only counted as a win if conversion moved over the holdout and every guardrail held.
The primary metric was search-to-booking conversion for thrash-intent sessions, measured against a 50% holdout, with the session as the unit and a multi-week run to wash out the novelty bump.
Underneath that we tracked a mechanism metric: date-picker re-open rate. If the feature works for the reason we believe, thrashing should fall, and that’s what separates “conversion went up” from “conversion went up because we removed the manual search.” Without the mechanism metric you can’t tell whether you fixed the problem or simply got lucky in the same window.
And we held the launch to a set of guardrails, because a flexible-dates feature has obvious ways to win on the surface while quietly costing the business: average daily rate and trip value (did we just bleed revenue toward cheaper dates?), cancellation rate (are flexible bookings lower-intent and more likely to fall through?), and zero-result rate and latency (did the heavier query degrade the very page it was meant to improve?). A result only counted as a win if conversion moved over the holdout and every guardrail held.
What I’d Do Differently
The forward-weighting was a hypothesis I believed strongly but shipped on conviction rather than proof. To move fast we launched the simpler window first and queued a weighted-versus-symmetric A/B as a fast-follow. I’d rather have had that test inside the launch instead of after it. And there’s a quieter risk worth naming: flexible search can mask a thin-supply problem. If users have to flex just to find anything bookable, the real fix is inventory, not interface, so the honest thing is to watch that this feature is solving search and not hiding a supply gap.
Results
📈 +8% search-to-booking conversion on thrash-intent sessions, over a 50% holdout, sustained past the novelty window, worth thousands of incremental bookings a month at our scale
🔁 −34% date-picker re-opens in the same sessions, the mechanism confirmed, not just the outcome
✅ Guardrails held: ADR flat, cancellation rate flat, results-page latency unchanged
🎯 Became a primary entry into the results experience for flexible travelers, with the contextual prompt, not a settings toggle, driving the majority of adoption
🔁 −34% date-picker re-opens in the same sessions, the mechanism confirmed, not just the outcome
✅ Guardrails held: ADR flat, cancellation rate flat, results-page latency unchanged
🎯 Became a primary entry into the results experience for flexible travelers, with the contextual prompt, not a settings toggle, driving the majority of adoption
The experiment dashboard: conversion lift on thrash-intent sessions against the holdout, the drop in date-picker re-opens, and the guardrail panel (ADR, cancellations, latency) holding flat.