Hotel Details Page

The Hotel Details Page sat between filtering and payment. Customers arrived with a hotel in mind, but still had to resolve the doubts that determine whether they book: is the room right for this party, can I trust the reviews, what is included, and will the facilities match what I expect?

The page was overwhelmingly mobile, spanning the native app and web experiences. That made comparison and evidence harder: customers could hold only a small amount of information in view at one time, while the page still needed to support a high-consideration decision.

Families made the problem especially visible. They needed to validate room configuration, occupancy, bed setup, board basis and usable facilities before booking. A page organised for browsing left too much of that validation to guesswork.

This was a cross-functional rebuild. Product led delivery, Engineering built across app and web, Content Design owned voice and labels, Legal reviewed claims about first-party review data, and Research supported the test programme. I owned the page strategy and information architecture, the review and badge-system direction, the experimentation and usability programme, and the decision to ship proprietary reviews early as a quick win.

Customers were hunting for proof before booking, and the page was sending them elsewhere to find it. loveholidays already held reviews from customers who had booked and travelled, but that evidence was not visible enough at the point where customers were deciding whether to trust a hotel.

Room selection had the same problem. Customers were often choosing between names before they could compare the evidence that mattered: photography, facilities, occupancy, bed setup and the differences between available room types. Choosing a room was a guess dressed up as a choice.

Facilities created a second form of risk. A facility could be seasonal, chargeable, limited, on request or temporarily unavailable. Showing a facility without its conditions was not enough. It could create a promise the product could not reliably keep.

The underlying issue was information architecture. The page contained useful information, but it was organised for browsing rather than deciding.

I treated the Hotel Details Page as a decision-support system rather than a catalogue. The page needed to answer the questions that create hesitation before booking, then expose deeper evidence for customers who wanted to validate the decision.

Verified reviews as proof

The reviews experience placed loveholidays’ own verified customer reviews alongside TripAdvisor rather than replacing an established third-party trust anchor. The two sources did different jobs: TripAdvisor provided breadth and independence, while the first-party source carried evidence from customers who had booked and travelled with loveholidays.

Rooms as comparison

The rooms redesign gave each room type its own photography, facilities, occupancy information and basic configuration. The comparison pattern kept the deciding facts visible so customers could compare rooms without holding several options in memory while scrolling.

Expectation management

Room, board and facility information was treated as conditional data rather than a simple list. Seasonal availability, charges, limitations, on-request conditions and missing supplier data needed explicit states, caveats and fallback behaviour.

Real data before code

I filled the Figma components with real hotel and review data before implementation. Long hotel names, missing photography, sparse facilities and awkward scores exposed problems while they were still design problems. That led to conservative fallbacks, suppressed empty states and a priority order based on occupancy, bed setup, imagery and facilities.

The larger redesign would take more than a quarter. Waiting for a single reveal would have left the page unchanged while also concentrating data, content, tracking and delivery risk in one release. I chose independently testable blocks instead. The trade-off was repeated test overhead and less visual unity at the beginning, but each change could be measured, learned from and rolled back without losing the others.

Replacing TripAdvisor with our own reviews would have been tempting, but it would also have removed a trust source customers already understood. Keeping both sources created an additional content and maintenance responsibility, but gave the page a stronger proposition: independent proof alongside verified proof from customers who had booked and travelled with loveholidays.

Reviews were the highest-confidence, lowest-dependency quick win, so they shipped first. Rooms followed after the data-quality work needed to make comparison trustworthy. The sequence reflected evidence and implementation readiness rather than a preference for one component over another.

Every block needed to be independently testable. That made behaviour change more attributable and allowed one module to roll back without taking the rest of the programme with it. The cost was more experiments to run and monitor, accepted deliberately in exchange for better evidence.

The verified-review experience launched as part of the Hotel Details Page programme and was supported by live experimentation. The rebuilt page delivered a directional 2%+ booking-conversion uplift on the measured page, and engagement with loveholidays’ own reviews increased.

The review proposition also supported loveholidays’ public launch as the first UK online travel agent with its own integrated customer reviews, combining verified customer feedback with existing star ratings and TripAdvisor reviews.

• Booking conversion: directional internal measurement, covered by NDA.
• Own-review engagement: increased, with the exact percentage not published.
• Public product milestone: first UK OTA with its own integrated customer reviews.

The broader page architecture remained a modular programme rather than a single completed redesign. Reviews and rooms were the shipped or live-tested blocks, while the wider system continued to be refined through evidence and measurement.

The most effective change was not a visual improvement. It was taking evidence loveholidays already had and putting it where the customer’s doubt occurred.

I would consolidate the badge and trust-signal system earlier. I treated variation as visual polish for too long, when it was really a system and measurement problem. Too many variants made experiments slower and made results harder to interpret.

The broader lesson is that a component is not finished when its tidy-state layout works. It is finished when it has survived real data, missing data, awkward content, uncertain conditions and the expectations it creates for the customer.

Before implementation, I populated the Figma components with real hotel and review data rather than placeholders. Long hotel names, missing room photography, sparse facilities, awkward scores and uneven review categories exposed problems while they were still cheap to fix.

The exercise changed the design in three ways:

• Review components needed explicit source labels and content rules.
• Room comparisons needed sparse states, conservative fallbacks and a clear priority order.
• The page system needed rules for degrading, simplifying or hiding modules when the underlying data was not strong enough.

A component that only works with tidy data is not finished.

The page was designed for customers making a high-consideration decision on a small screen. Comparison kept the deciding facts visible: occupancy, bed setup, imagery, facilities and price.

I worked with Content Design to replace internal vocabulary with customer language, shorten reporting labels, and make scores legible without requiring customers to interpret a separate key. Source labels made it clear whose evidence a customer was reading.

Accessibility here was not only a contrast or component concern. It was also about reducing ambiguity, making conditions visible and ensuring that customers could understand the decision without relying on memory or hidden context.

Measurement was defined before build. The goal was not simply to make the page feel clearer, but to establish whether each module helped customers move toward a confident booking decision.

Reviews shipped as the first quick win and were evaluated through live experimentation. The rooms work followed as a separate module, allowing the team to learn from room-specific data quality and comparison behaviour without bundling it into the review release.

Testing modules rather than releases made behaviour change more attributable and allowed one block to roll back without taking the rest of the programme with it.

Room comparison exposed the importance of data resilience. Missing images, thin facilities data and equal weighting across attributes made some comparisons misleading or noisy. The response was to define sparse states, suppress empty cards, use conservative fallbacks, and prioritise occupancy, bed setup and imagery.

This case study describes design direction, experimentation and product outcomes while protecting commercially confidential information.

The reported 2%+ booking-conversion uplift is an internal, directional measurement and is not presented as an independently audited commercial result. The exact own-review engagement uplift is not published.

The claim that loveholidays became the first UK online travel agent with its own integrated customer reviews is presented as a public product milestone. Internal identifiers, system names and colleague names are excluded. Contributions are attributed by role where appropriate.