Use case 01

Rebuilding a new-generation booking engine

A product redesign focused on continuity, trust, and clearer comparison inside a legacy white-label booking stack.

Scope

Year-long product design initiative

Context

White-label hotel booking platform

Outcome

Abandonment from ~60% to ~25%

Illustration of booking friction and trust problems in an online booking flow — The core problem was not aesthetic polish. It was trust failure at the exact point users were most likely to drop.

Context

I led product design on a year-long initiative to rethink a large-scale hotel booking engine used across a wide range of properties. Many users dropped as soon as the booking flow opened in a separate window. That handoff broke continuity at the most sensitive point in the journey and created an immediate trust problem.

The experience also depended on legacy PHP services, some dating back to 2006. That constrained performance, security, and interaction design, so product decisions had to hold up within real technical limits.

Our clients ranged from boutique villas and alpine chalets to budget hostels across Europe. The engine needed to flex across very different inventory models and brand expectations without turning into a one-off build for each property.

What was broken

The previous flow felt dated, narrow on desktop, and hard to parse at decision points. Key booking details were difficult to compare, and concepts such as guest count versus bed type were easy to misread.

The result was slower decisions and weaker confidence. The flow made users work too hard to understand meaningful differences, precisely where trust and speed should have been strongest.

Legacy booking engine example for Monte Cristo — Legacy room selection screen with weak comparison and dense hierarchy.

Redesigned booking engine concept — Legacy room selection screen with weak comparison and dense hierarchy.

Research

We mapped 15 booking journeys across hotel types and reviewed 10 competitor tools to understand both expected patterns and avoidable weaknesses. Interviews with 12 guests and 8 hoteliers helped separate surface complaints from the underlying trust, clarity, and comparison problems driving abandonment.

We synthesized the patterns through affinity mapping and used two cross-functional workshops to turn them into product priorities. The goal was to align around what needed to change in the product, not only what looked dated in the interface.

Research synthesis board showing grouped highlights by theme — Research synthesis turned scattered complaints into clearer product themes around trust, comparison, and clarity.

Design process

Our first direction explored a modular system. Hotels could show rooms only, rates only, a combined view, or a hybrid. Testing across 15 properties made the tradeoff clear: configurability increased internal optionality, but it also introduced too much cognitive overhead for guests.

The second iteration narrowed the system around clarity and trust. We simplified the decision path, strengthened hierarchy, and used imagery and typography more deliberately so each property could retain character without compromising speed or comprehension.

Version one modular booking engine exploration — Early exploration: high flexibility for hotels, but too much decision overhead for guests.

Outcome

The new engine is live on more than 150 hotel sites. Keeping guests inside a clearer, more consistent flow reduced abandonment and made the booking experience feel more trustworthy from search to checkout.

The most important outcome was not only a cleaner interface. It was a stronger product surface that felt credible enough to support conversion across a very mixed client portfolio.

“It looks like a real product.” and “I felt bad about our guests seeing the other booking engine.” were the most telling reactions after rollout.