TL;DR
Hosts had no reliable way to know what guests actually pay on each channel or what they truly earn per booking. Rates were the single largest driver of support contacts and a meaningful churn driver — with price mapping mismatches as the top theme. Rates 3.0 rebuilt the pricing experience around one principle we learned from research: hosts don’t need more features — they need to trust the system.
🖼️ Image coming soon — the Rates 3.0 experience with per-channel price visibility.
Context & role
Part of Lodgify’s “Get Fully Booked” initiative (rates and connectivity domain), V1 → V2. Initiative designer, working with a PM, the engineering team and their EM.
The problem
“I’m an Independent Host trying to know what guests are paying and what I actually earn from each booking. But checking how my prices show up across channels is time-consuming and my rates setup is opaque — which makes me feel unconfident, worried about losing money, and wasting time I could spend hosting.”
Five interconnected pain clusters: pricing uncertainty (no guest-facing preview), configuration complexity (fear of breaking settings), overwhelming information architecture (many pricing strategies not even supported by the channels), sync verification burden (each OTA with its own terminology and logic), and redundant fee/tax/promotion configuration scattered across the product.
The jobs to be done: set my prices with confidence (see what guests see and what I earn) · adjust rates quickly without fear · trust that changes sync correctly everywhere.
🖼️ Image coming soon — the UX audit board mapping every friction point.
Process
Prototype-first validation. An interactive prototype tested across two rounds of user interviews, with feedback feeding directly into iterations. The core design objects: a “what guest pays” and “what host earns” breakdown, and a per-channel view of how prices actually land on each OTA.
The research insight that set the direction: hosts consistently described Airbnb as easy and structured, and Booking as a headache. So we took Airbnb as the usability benchmark — simplicity and clarity guide the design, not the most complex channel’s logic.
The trust decision. Where a channel didn’t support a pricing feature, we chose not to hack around it. Show it as unsupported, explain why, let the host decide. Short-term it looks like a worse feature list; long-term it’s the only way the host trusts the number on the screen.
🖼️ Image coming soon — the “what guest pays / what host earns” breakdown. 🖼️ Image coming soon — how the prototype evolved between interview rounds one and two.
Solution
A new rates management experience: per-channel price visibility (what syncs, what doesn’t, and why), guest-pays/host-earns breakdowns, and safer editing flows. Delivered in phases — V1 beta, V1 GA, then V2 — followed by a structured post-release program: cross-channel end-to-end testing and user research driving the iteration backlog on measured friction, not assumptions.
🖼️ Image coming soon — the “supported vs unsupported per channel” state: the trust story in one screen.
Learnings
- Trust beats feature parity. If a channel doesn’t support something, don’t hack the system to fake it — be clear and transparent about what syncs and what doesn’t. Hosts forgive a missing feature; they don’t forgive a wrong price.
- Every channel has its own API — and its own opinion. Nothing works exactly the same across OTAs. The design job isn’t fighting each API’s quirks; it’s absorbing that chaos into the most unified experience possible, so the user never has to think about it.