Book hotels faster

 

Story

Suraj is a marketing manager in a private bank. There is a long weekend coming along and he wants to visit Goa with his wife. He uses Cleartrip to book flights and hotels for the places he travels to. After he finalised the travel dates for his trip, he searched for the right hotel and booked a hotel in under 30 seconds. 

How did we make the booking experience so fast?
 

 

Intro

Cleartrip is a travel product focusing on giving millions of users a simple travel and local experience. The mission: Make travel Simple. The products ranging from Flights, Hotels, to Hyperlocal Activities, Food experiences, Local Events and more!

Who I worked with?

I worked closely with Jaydeep, Product Designer, Suman, The Product Manager, Sunit & Kedar, The Design Managers and kickass iOS and Android Engineers at Cleartrip. It's a project that wouldn't be possible without the contribution from various designers at Cleartrip.

Platfroms launched

Android.
iOS.

How Long did it take?

The project was on and off, but roughly took us to 2 months of design to get the first version. Further we iterated to include more components like coupons, gifst cards and new payment systems

 
 

Problem

As a casual traveller, I want to book my hotel fast before the rooms get booked, so I can carry on with my other plannings related to travel

Exploration and Ideation

Unlike other problems, this was not the one that came from business or product requirement, but rather a problem statement we, the design team defined while we were trying to optimise our product journey

When I was working on the Material redesign for Cleartrip Android app, I had to revisit all the flows that are existing and try to understand the rationals behind some of the biggest designs that directly impact our transaction and user journey. During this review, I noticed that a journey for hotel booking was unexpectedly wrong and the transitions made it feel super long. (Unlike iOS, Android as a platform had a long over-due for page transitions and only Android 5 brought it natively)

When I tried to book a hotel in the app, I went through 4 screens (with loaders) to arrive at the final payment page to book. 

The inconsistency affected even our data when we realised there are different sets of drop off rates and not easy for us to directly compare

The inconsistency affected even our data when we realised there are different sets of drop off rates and not easy for us to directly compare

I was curious about this legacy design that existed for Android and I tried to look into the data to find out that there are a considerable amount of drop-offs compared to iOS. I wanted to create an experience in the Android app that makes the book flow faster, maybe even faster than the iOS book flow, and make it efficient and simple. This way I wanted to experiment if it would affect the conversion

What's behind the legacy?

Before I went to explore solutions, I wanted to understand the technical background about the current solution. The server calls were structured in a way that the first step, you get the room picker results, where the user selects the room and based on that we create an itinerary with price, tax information. Once the user confirms that and goes to the next step, we open the traveller details and ask the user to fill in information. Once the user clicks continue, we again request another Server call with the traveller information and fetch the payment details that are appropriate for that booking. This structure created few progress bars and delayed certain pages in this flow. So the actual process looked longer and slower than iOS flow 

Design solution

I wanted to step from this current architecture for Android and come up with a solution that would be an ideal good experience for the user. 

Sometimes going away from all the constraints help us to arrive at what we are truly solving for the user. 

What if after the user picks the room → The user sees itinerary → Add traveller information → Pick the payment details and book. 

This is not a new solution, and we were sorta doing already for pay at hotel bookings (for certain hotels) & Signed-In users. I tried to question why we need to separate the flow, while we can arrive at similar solution for the main book flow experience

I cooked up a prototype and showed to my design manager and other designers. The team did raise some concerns and critiqued my solution, but saw the huge potential with the approach I took. This helped me to focus and iterate on the Prototype

Once we had a considerably reliable flow with most cases considered, we pitched it to product and executives and we felt this is something that we can build fast and run it on AB and validate it! 

ideation sketch

Itinerary, Contact details and Payment - 3 simple steps to book

Details

We wanted to reiterate on what users are booking and we wanted a persistent bar that comes at each level when they scroll down in the book flow. This way we can point out the validation and other errors, faster when the users are scrolling down, so they don't have to jump from the context at the final step to fix those errors. 

So we made a design where Itinerary, Contact details, Deals, Payment Type slide in when users scroll down in the book flow, giving the contextual information as they progress. 

 
Banner Components
Itinerary and fare breakup at the top fold

Itinerary and fare breakup at the top fold

 

Payment

While working on the vertical book flow, we also had to revisit some of our primary payment flows and wanted to provide a way for a new payment method: Partial Payment. Partial payment is a solution that addresses the sub-problem of how users find full payment overwhelming & high commitment, especially when the trip is very far away. We wanted to provide a way for users to switch between different payments and also Cleartrip Wallet (Our payment wallet where we store refunds and deal cash back)

While Pay Now and Pay Partial required card details to go to the next step for booking,  Pay@hotel was simpler and it required an SMS OTP(One-Time-Password) to confirm the booking. The approch I took simplified it further and showcased the design thats consistent across differnet tabs

 
Partial Payment Flow
Full Payment flow
Pay at Hotel Flow
 

Challenges

The technical challenges ranged from the backend - how can we process multiple calls together to for all the users, to frontend issues like animation, timing and transitions. The challenge also came with the contextual banners that appear while scrolling and how it can scale different screens. Fragmentation is huge in Android and these problems let me learn and adapt my solutions faster. 

Since the new book flow was about to be validated through AB, we had to come up for the legacy substitute design taking the users to all four steps. That means two sets of new feature design when the test was running. and we need to ship faster. 

Validation & what steps we took next

We validated the design through the test and we rolled out for all our hotel users.  This design later impacted iOS too and we went from 3 step process to single scroll book flow just like Android. We also tried to create the similar book flow in Flights to see how can we save some more time for users and it lead to a separate book flow project. The single page book flow later arrived in our Local products, helping us to create book flows for scheduling Events, Food and Activites 

How could we’ve done better?

This project was done in 2015-16 and if I can go back and work, I would probably focus on User research to understand the user’s actual pain point and arrive at the problem statement then I would have optimised the solution. 

Further, we relied on validation with data and not the users. Would have been wonderful if I could have validated this with few users who belong to our booking segment. 


Next up

Case studies from my work and fun projects

WorkSuganthCleartrip, HomePage