Superhero Hotel Booking

The problem

Superhero Hotel sells a fixed 28-day stay to startup founders visiting San Francisco's Frontier Tower. The founder's brief named four problems. Pick a start date near the edge of the calendar and your checkout month never rendered, so guests committed to a stay whose end they had never seen. The picker itself was a free date-range control strapped onto a fixed-length product. He wanted the flow to propose optimal start dates instead of accepting arbitrary ones. And arbitrary dates were expensive in a way nobody was tracking.

Walking both live flows on video, my audit across the 4-Week Stay and the nightly widget turned up more than the brief named. The ones it didn't name were about trust: the flow showed “Only 2 rooms left” counters that were random numbers, capped at 3 by design, and payment was full and non-refundable, disclosed late. A conversation with the front desk added two more that no screen could show. My read: founders were at least as likely to abandon at trust as at calendar mechanics.

My role

Sole designer, end to end: the research, both flows, the founder feedback and review sessions, an interview with front-desk operations, and the handoff to backend engineering. Every design decision and every QA catch was mine, including the pricing inconsistency below, the step-overload call, and the copy that had to be rewritten. Claude helped synthesize the competitor research. I verified everything I delivered by breaking the flows in the browser at five viewports and tabbing through every step.

Two working weeks from brief to handoff, June 26 to July 10, 2026.

Discovery

Start from the live flow, not the brief

Instead of designing against the founder's four problems, I started from evidence: I walked the live flow on video and mobile screenshots, read the git history, and probed the production APIs read-only. Of everything that surfaced, the most interesting finding looked like a bug and wasn't. The scarcity counter was fabricated deliberately: the founder's own commit capped it at a random 1 to 3 because raw inventory (“36 rooms left”) weakened the signal. That finding set the shape of the whole project: the business goals were real, the mechanisms were the problem. It also gave me the question I carried into every other source: where else is the interface promising something nobody behind it can back?

Who's booking

One primary user, defined in the PRD (product requirements doc) and held to: the founder relocating to Frontier Tower for a working stint. They think in months and rough windows, not check-in/check-out dates, so “which month” comes before “which dates.” They're committing thousands sight-unseen, which is why non-refundable prepay next to fake scarcity reads as risk, not urgency. And their flexibility on start dates was an assumption I flagged for validation rather than a fact, so exact-date entry stayed first-class instead of being designed away. The tourist on a short, specific-date stay was explicitly deprioritized to the nightly track.

What the front desk knew

The audit showed me what the interface said. It couldn't tell me whether the hotel could keep its word, and the person who knows that is the one behind the counter. So I sat with Liz at the front desk for an open-ended conversation (we spoke in Taglish). Rather than limit it to the problems the brief already named, I asked how bookings actually work on the hotel's side and where the guest-facing flow might part ways with operations. Two findings directly shaped the redesign.

Occupancy is governed by hotel policy, not OTA conventions. On direct bookings a one-bed room takes one founder, or two guests if they're partners; the Double's two beds take two guests at most. Relationship only matters when two people share a bed. The OTAs (online travel agencies) sell the same rooms at two per single and four per double. The direct flows now enforce her two-guests-per-room cap, not the OTA's, and it drives the room step's capacity math (below). The partner rule is guidance in the copy rather than a hard block, with the formal rule left to the terms and check-in. My first draft of the guest copy framed the second guest around “partners and married couples.” I rewrote it for the customer the hotel actually serves, founders, around the beds instead of the relationship: “Bringing your partner? You'll share the Suite's king bed. Traveling with a co-founder or friend? The Double has two separate beds.”

No room is held while a bank transfer settles. I'd found it in the live Stripe states, and Liz confirmed there's no hold procedure at the desk, so any “we're holding your dates” promise would have been false. That turned a copy problem into a product decision (below): I took it to the founder, and he switched bank transfer off. “We should just deactivate it.” The occupancy policy wasn't visible from any screen, and the hold gap only became certain once the desk confirmed it; both became constraints the redesigned flows had to respect.

What the research showed

Liz told me what the hotel could promise. The research had to answer the question the fake counter left open: if not fabricated scarcity, what can the founder's urgency stand on? Two research waves ran before any pricing UI got designed: published UX and pricing evidence first, then a competitor teardown with review mining. The findings converged. The providers and pricing practices I reviewed pointed toward transparent price differences and genuine savings, not fabricated inventory counters. Blueground's pricing presentation gave a reference for framing price differences as savings rather than penalties. And the reviews I analyzed surfaced recurring concerns around cancellations, refunds, and unexpected fees, which I recorded as competitive trust considerations, not as validated problems among Superhero Hotel's own guests.

When gap pricing came up, I pushed for rigor over instinct: research other providers first. The revenue-management tools (PriceLabs, Beyond, Wheelhouse, OwnerRez) treat orphan gaps with discounts of 20 to 35% and prevent them with stay restrictions; none of them surcharges the booking that creates the gap.

The same research named the endgame pattern (price-per-date calendars, the Google Flights model) as the next iteration once live pricing flows, and fed the backend brief: score both edges of the 28-day block, the arrival gap and the trailing fragment.

I also studied Airbnb's flexible-dates system from recordings: the continuous-scroll calendar that solves our hidden-checkout bug, all-in pricing, and a “free cancellation” selling point this non-refundable product can't match, a competitive gap worth knowing rather than hiding. A read-only scrape of the live nightly rates across six rooms and six stay lengths surfaced a price inversion (6 nights cheaper than 5 in total) that went straight to the founder.

Synthesis

Different problems, one design challenge

The findings came from different sources and had different causes: a calendar defect, a deliberate business decision, a pricing inconsistency, an operational limit. What connected them was the challenge they added up to: help guests make informed booking decisions without the interface misrepresenting the hotel's inventory, pricing, or operations.

I translated these findings into three principles, and every decision below answers to at least one:

• Keep the goal, challenge the mechanism. Urgency, inventory use, and full prepayment were real business needs. The design question was how to pursue them without misleading scarcity or late disclosure.
• Show the whole commitment before the commit. The dates, the all-in price, and the cancellation terms are on screen before the Pay button, never after it.
• Promise only what the system and the operation can support. Room capacity, availability, and payment states reflect the hotel's actual rules and technical capabilities.

The 4-Week Stay

Urgency without lying

The proposed replacement makes urgency a property of the offer instead of a counter: the flow presents a handful of real, gap-free “best windows” each month at the lowest price, and windows that strand empty nights cost visibly more, with the reason written next to the price (“Starts 4 nights later than the best window, so it's priced a little higher”). Scarcity became “the good windows are genuinely few,” which has the advantage of being true.

The founder had originally asked for a penalty framing: prices increase as you drift from optimal. Competitor research supported flipping it. Blueground frames the same economics as “save money by booking a move-in closer to an apartment's availability date,” pricing the operator's need as the guest's discount so both sides win the same transaction. I presented that flip as his call to make, with the evidence, rather than just shipping my preference. It became the model he approved:

To be precise about status: the experience is designed, built in the interface, and approved. The algorithm that scores windows against live inventory is the backend piece still pending, so the window prices in these screens show the interaction, not production pricing.

The audit's other trust finding closed in the same spirit. Full prepay at booking stayed, that was the founder's deliberate call, but its terms stopped arriving late: both flows now put his exact cancellation policy in its own inset before the Pay button, so the non-refundable commitment is read before the commit, not discovered at it.

Guide only where the constraint is real

Curated windows make sense in busy months. But in a wide-open month, “3 best windows” is fake curation: every start date is equally optimal. The founder spotted it in review and sketched the answer: when everything is open, just show the calendar.

My first build gave open months their own embedded calendar. Then I asked the question that killed it: with an exact-date calendar one tab away, isn't this redundant? It was. The delivered version makes wide-open month chips navigational: tap “October · Wide open” and you land on the one calendar, scrolled to October, with a banner explaining that every start date gets the best price. One calendar in the whole flow. Which months flip between curated and open is specified as a per-month backend decision, so the interface is built to adapt as occupancy grows without a redesign.

That one calendar is also where the brief's first problem dies. It scrolls continuously (the Airbnb pattern from the research) instead of paging two fixed months, the full 28 days shade across month boundaries, and check-in and checkout stay pinned in the summary below it. Nobody commits to an end date they have never seen.

The date decides the price, never the tab

Testing my own flow, I picked July 9 in the flexible tab: $1,900, best price. Then I picked the same July 9 on the exact-date tab: $1,980, standard rate. Same stay, two prices, depending on which button you had clicked. Nobody had specified this case, and it would have shipped.

The fix became a rule with a name: the date decides the price, never the tab. In the interface, an exact-date pick that matches an optimal window now shows that window's price; a suboptimal pick shows its uplift and offers a one-tap “Best-price start” upgrade. The rule then outgrew the frontend: it went into the backend handoff as a contract requirement that every number a guest sees, taxes included, comes from the pricing API.

The Day-by-Day

Two flows that behave like twins

The hotel's nightly track (1 to 27 nights) ran through an embedded third-party widget: prices shown before taxes, duplicated guest forms, and dead-ends on sold-out dates. I brought it in-house as the 4-week flow's sibling: same steps, same validation behavior, so a guest who learns one flow has learned both.

The parity ran both directions. When I judged the 28-day flow's first step overwhelming (dates, guests, and rooms stacked on one screen), the fix came from the nightly flow's structure: room selection became its own step. When the nightly flow got press-to-validate (an always-enabled button that marks every missing field and focuses the first one), the 28-day flow got it the same day. I had originally deferred inline validation to keep the prototype moving; an audit I ran against the flow ten days later named that deferral its weakest point, and I reversed it the same day.

The widget's failure points, handled

The old widget's dead-ends became moments the new flow designs for:

• Sold out is caught at selection, not after you've committed to a room. A “We're full for these dates” card offers two one-tap alternative windows of the same length, with WhatsApp and email as the human fallback.
• 28 nights or more steps aside. The nightly path hides and a routing card hands you to the 4-Week Stay flow, carrying the check-in date you already picked.
• All six room categories render as full cards, price-sorted, and the cheapest room that fits your party wears a Recommended badge. Groups get per-category room steppers with a live capacity tally (“2 rooms · sleeps 4 · Room for 4 of 7 guests”), and Continue stays gated until everyone fits. The capacity per room is the house policy from the front desk, not the OTA's.
• Two-tier pricing became an honest hint. I scraped the live rates across six rooms and six stay lengths to model the real tier break, then wrote it next to short stays: “Stays of 6 nights or more get a lower nightly rate.”
• A declined card is a designed state. A destructive banner, the form preserved, a retry that works, tested against Stripe's decline test card.

Explored and killed

Built, then killed by taste

• An Airbnb-style two-mode picker with ±3 days flexibility chips. Built, then cut: the flexibility math complicated the packing model for marginal benefit. The simpler month-first flow survived contact with the founder twice.
• Collapsible room rows. I proposed showing only the recommended room expanded. It passed every automated test, and I still killed it after seeing it: burying rooms behind a tap made the page tidier at the cost of trust. All six rooms render as full cards.

The invisible work

None of this shows up in a screenshot. It shows up when you tab through the flow, refresh mid-booking, or book from the wrong timezone. It is most of what separates a prototype from something you would trust with a card.

Where it stands

Both flows were delivered as pull requests and in review at handoff, with the pricing algorithm assigned to backend engineering against my spec. What stands behind them:

• The founder reviewed the flow in two live sessions and approved it in the second (“That looks all good”); both of his change requests from the first (current-month availability, windows visible on load) were built the same day.
• I briefed backend engineering against my handoff spec, and the pricing algorithm was assigned to be built against the contract it defines; that build is on hold pending a roadmap decision, so there are no live results yet.
• The cancellation policy is in the founder's own wording, kept at his request. My part was where it sits and when the guest reads it, not what it says.

• Research along the way surfaced three live production bugs (the hidden-checkout calendar, a schema.org price rendering “$undefined/night” to Google, and a rate-tier inversion where 6 nights cost less than 5), all documented for the team.