FabHotels: Hotel booking for
5 million MAUs.
FabHotels operates a network of 1200+ budget hotels across India, aiming to deliver standardised stays at affordable prices. The goal was to increase conversion by redesigning key flows — from simplifying hotel discovery to improving PDP clarity,
and so on.
Drag the handle to see before vs after
The outcome
34%
Increase in conversions
15%
86%
Increase in performance scores
26%
Faster page load on high latency
The approach
We started by setting up event tracking on Mixpanel to build visibility across different user journeys. With a data-driven approach and competitive benchmarking against leading OTAs, we started tackling one page at a time.
Each release (of usually a single page) was rolled out progressively — starting with 10% of users to establish a performance baseline, then expanding to 20%, and eventually a full rollout once fully stable.
All changes were tested on mobile-web first, allowing us to experiment faster and gather insights before extending them to the apps. Throughout, we closely tracked user behaviour, iterated and re-iterated on the designs.
Defining a clear brand proposition — building trust by highlighting guaranteed amenities upfront
Starting with the Homepage
The previous homepage struggled with clarity and hierarchy. Key user actions like search felt buried. There was no structure and a visual language that brought different elements together.
The redesigned homepage shifted to a search-first experience.
Trust-building elements like offers, benefits, guest reviews were placed post-primary action.
UX copy throughout the page was designed to build trust and communicate FabHotels' value propositions clearly.
Data revealed higher ECR for locality based search, so we introduced nested locality suggestions within the search flow — helping users move faster in their booking journey.
Homepage Screens pt. 1
Homepage Screens pt. 2
SRP: Search Results Page
The following points are linked to a numbered annotation in the image for easy reference.
1. Visibility
Below is an example of our design iterations - highlighting how data shaped our decisions. Initial tests showed a drop in the ECR so we decided to borrow cues from the older design — to improve scan-ability. The hotel name dominated the card even though it’s not the primary decision factor for most users, so we reduced it’s font size and changed the color back to black.
2. Interaction
Key interactions like filters were made more accessible. Moving from a hidden floating button, filters are now a sticky strip with a few exposed options for quicker refinements.
3. Reviews
Reviews have been a constant area of experimentation for us. Inspired by patterns from Booking.com, we tested adding context labels like Excellent or Good.
Since most effort by ops team was put to gather reviews on Google and OTAs, our app had limited review data. To leverage this with a hypothesis of building trust, we integrated Google Reviews directly into our product.
Improvements made to the SRP
PDP: Product Description Page
The following points are linked to a numbered annotation in the image for easy reference.
1. Image gallery
Replaced with a grid preview — offering variety at a glance (building exterior, room, bathroom, etc.). The “+15 photos” CTA encourages exploration but doesn’t distract.
2. Upfront Savings
Displaying the coupon offer upfront gives users the idea of savings early in the decision journey and creating a stronger incentive to proceed with the booking.
4. Menu
Unlike other OTAs, our one-page PDP was tried and tested. Given the standardisation of our offerings, a separate room selection page added unnecessary friction.
We introduced a floating menu to support this one-page design - allowing users to seamlessly jump between different sections of the page.
Hotel PDP
- Data about booking behaviour.
And why is that important?
Let’s have a look.
With the launch of rate plans, the dev team implemented a shopping cart-like logic for room selection due to technical constraints. Rooms could be added or removed freely. Great flexibility, right? Nope!
If a user wanted to change their room, they first had to remove the existing selection then add a new room.
Old flow of room selection
Let's fix this!
A simple breakdown of the data above shows that 97.75% of users book the same room type — either a single room (93%) or two rooms of the same type (4.75%). It was only logical to optimise the experience for this majority.
For these users, changing room types should feel instant — like flipping a toggle.
New room selection flows
A few more product UI shots
FabHotels App UI
