Case study: Getting users to show up at hotels they book
About OYO
OYO is one of the largest hotel chains in the world. They are the largest player in India and Southeast Asia. They also run 4 vacation rental home companies in Europe.
OYO’s consumer platforms get around 1.5 million daily active users.
This redesign was for mobile apps, which bring around 95% of our traffic.
Team and role
I worked as the sole interaction designer on this redesign, in collaboration with multiple product managers and engineers. I was responsible for user research, wireframing, usability testing, high fidelity designs, and prototyping.
The project timeline was 5 months.
Problems
- A lot of users were booking hotels and not checking in
Exactly how many? Due to confidentiality clauses, I cannot share the exact numbers. This chart should paint a picture.
With every booking created in the OYO central database, there are server costs. We send notifications building pre-travel engagement with the customers over multiple channels. A dedicated OYO capatain is assigned to take care of customers’ problems. In a nutshell, OYO burns some money after a booking is created and hopes to redeem it when the customer checks in. So, this problem was burning us a lot of money.
So , what were these users doing?
2. Visual clutter and an outdated information architecture
OYO had expanded into multiple services and product offerings without redesigning the page from scratch. The result was a page where components had been added ad hoc.
Digging deeper into the problems
We did this by analyzing our google analytics data, talking to support executives that handle user queries and user interviews.
We hired an external agency to understand people’s reasons for cancelling on app and not just showing up on property.
Me and a product manager conducted user interviews and studies to understand why so many people cancelled within 10 minutes of booking. We also tried to understand what information a user needs once his/her booking is completed.
- Users cancel booking on app because
We hired an external agency to talk to 2500 OYO customers who had cancelled their hotels. These were the biggest reasons for cancellation.
2. Users cancel within 10 minutes because
Users booked hotels accidentally!! They expected there to be a payment page between the hotel page and booking getting confirmed. This is their mental model formed by interating with other hotel booking apps.
Who were we designing for?
From our user studies and interviews, we mapped the different types of users and their respective needs and pain points from the hotel booking experience.
These are not full-blown user personas, but a small mapping to get the team to empathize with our users.
What did business want to achieve with this redesign?
- Sell more OYO Wizard memberships
OYO Wizard is OYO’s loyalty program that rewards repeat users with discounts. Upon conversations with users, we realised that product education was a blocker for adoption. With the current implementation, users did not understand what it was and hot it could help them.
2. Get more users to upgrade their rooms
An average OYO customer goes for the lower-priced rooms. Letting the users upgrade to a better room would help our profit line.
3. Sell more travel insurance policies
Travel insurance is an a-la-carte item that doesn’t cost the user much increases our profit line because of the scale of operations. It brings a safety-first mindset to the travel plans.
Wireframes
After making quick and dirty sketches on the whiteboard with team, I proceeded to create grayscale wireframes on Figma. These would be used for usability testing.
Learnings from user testing
We tested the concept wireframes with 9 users. We explored conversations around what data points users need to see after they complete a booking and if the options to pay and cancel were discoverable.
1. Users use navigation services like Google maps to reach a place. Hence, writing the entire address of the hotel with pin code was unnecessary. That important real estate could go to another piece of information. The entire address could be revealed when the user clicks on a summarised address.
2. We had gotten relative heirarchies of the modifying booking details, calling the hotel and navigation to the hotel wrong. Users felt that the option to modify wasn’t all that important right after they book because they’ve put conscious effort into deciding their booking details.
3. Users really liked the segregation between bookin-relateed actions and other actions, as compared to the older design. This made information wayfinding easier and gave a feeling of this being a whole separate section.
4. A major concern that users had was the help of assist button. In the hospitality industry, human intervention is the default behaviour. Our redesign had kept it less discoverable to reduce operation costs. Ater these conversations, we decided to keep it upfront and later on build a chatbot that’ll help us reduce operational costs.
5. 6 out of 9 users asked us for a Share booking button. They had planned their travels with someone and wanted them to have access to the booking in case they reach the property first. We decided to make this option more discoverable.
Information architecture
We mapped the user journeys and flows around which we wanted to build our final designs. We made sure to include happy flows and the not-so-happy flows. Looping in developers in the conversation helped us identify edge cases and solve for them.
You can find the complete information architecture and user flow here.
High fidelity designs
How did this redesign solve problems?
- Improved discoverability of the payment CTA
An ideal solution would have been to put payment as a mandatory step. This solution evoked strong reactions from the leadership as it would drastically reduce the number of bookings, which was an important business metric.
2. Made cancellation easier but still made the user not want to cancel
We incentivised the user to stay with an offer. We asked the user to choose a reason. Inside the reasons, there were redirection flows for different use cases. Example — If a user had a problem with the location, we asked them to shift hotels. If their plans had changed, we asked them to modify their booking.
3. Conveyed that hotel is getting booked better with a UI interaction
Our hypothesis was that this would help us reduce accidental bookings. Motion draws the eye and a visual story tells the user about what is happening behind the scenes.
4. Updated the information architecture to reduce visual clutter
This page had two broader sections —
1. Booking information and direct actions
2. Upsell nudges and alternate channels of revenue
We split these 2 by a z-axis for more coherent grouping.
What was the impact of this redesign?
I am not allowed to share the exact numbers because of confidentiality reasons.
- The number of users who paid online for their hotel bookings increased. There was a significant increase in our southeast asia market, especially on Mweb platform.
- The total number of bookings decreased. We attributed this to a decrease in accidental bookings.
- Cancellations withing 10 minutes dropped drastically. We attributed this to the UI interaction making a booking more intentional.
What were my major learnings from working on this?
This project took a long time (>1 year) to be developed by the engineering team. It was split into 5 phases. As a designer, it can get frustrating to wait that long to measure whether your design is successful or unseccessful.
I’ve learnt how to break a large scope into smaller milestones and have design deliverables in tandem with engineering.
In a large organisation such as OYO, different teams are responsible for different parts of the experience. Having an understanding of their priority queues can help you design easier to implement solutions. Example — The team responsible for working on the booking modification piece were really packed. By changing the design a little, we were able to ensure they didn’t have to build a new API.
Thanks for reading :)
Give the article a clap, if you liked it.
