On a new generation
Booking engine
Context
I was the principal product designer on a year long initiative to improve a massive booking engine.
High user churn
Many users dropped out as soon as the booking engine opened. The jump to a new window broke context and trust, which led to a sharp spike in abandonment.
Aging tech stack
Part of the work meant meeting legacy code where it lived. Some PHP backends dated from 2006, which limited performance, security, and flexibility.
Client and user variety
Our clients range from boutique villas and alpine chalets to budget hostels across Europe. The engine had to feel trustworthy, adapt to very different needs, and carry each brand with care.
Existing product
The previous journey looked tired and felt cramped on large screens. Important details were hard to compare and things like guest count and bed type were easy to confuse. The result was slower decisions and less trust.
- Look and usability: dense modules, weak hierarchy, dated visuals.
- Large screens: a narrow column wasted space and the layout did not scale well.
- Ambiguity: guest count vs bed type was unclear and rate details were buried.
- Room comparison: cards did not surface meaningful differences at a glance.
Research
We mapped 15 user journeys across hotel types and evaluated 10 competitor booking tools. Interviews with 12 guests and 8 hoteliers surfaced expectations and frustrations. Patterns were distilled through affinity mapping and prioritised during two cross‑functional workshops.
Design process
Our first iteration was a modular system. Hotels could show rooms only, rates only, a combined view or a hybrid. We tested with 15 properties and found that flexibility was valued but the modularity confused some guests.
For the second iteration we leaned into brand and clarity. We simplified the layout, improved hierarchy and used imagery and typography to give each property more personality while keeping the flow fast and crystal clear.
Delivery
Live examples
The new engine runs on more than 150 hotel sites. Keeping guests inside a clean, consistent flow reduced churn and made booking feel simple and safe.
After the fact
- Churn from ~60% to ~25%
- Time to book down ~50%
- NPS from 4 to 6
- ~150 key accounts live
Positive
- Real impact: churn cut by more than half and faster bookings across the board.
- Better perception: NPS moved from 4 to 6. There is still room to grow, but the change is felt.
- Adoption: about 150 key accounts went live in year one with strong pipeline behind them.
- Healthier stack: critical backend cleaned up and modern bridges added to legacy systems.
“It looks like a real product.”
“I felt bad about our guests seeing the other booking engine.”
Negative
- Slow launch: long time to market caused by stakeholder delays and a rigid, aging codebase.
- Migration friction: some properties still depend on old systems that block an easy switch.
- Scope lesson: a smaller MVP first would have de-risked the work and sped up learning.
Next time: ship lean, validate early, and tackle the hard technical risks up front.