Making room bookings for day-trips ultra fast ⚡
An attempt to increase conversions for Day Use room bookings on Agoda
Introduction
Only 2 weeks into 2023 and I’ve been on my toes with two 48-hr design projects. (Shoutout to the UX Mastery community and our mentor Anudeep for the amazing momentum!)
In this 2-day project, I built a faster checkout experience for daytime travelers. I built the feature in an attempt to impact conversions for a niche booking option called Day Use offered by Agoda (a travel and hotel booking platform).
This article has 2 parts. You can navigate the sections here —
01. The design
Context
Understanding the problem
Solution
02. The process
Setting a direction for my project
Research: Current experience and competitor analysis
Understanding constraints
Ideation & solution
Testing my design
+ Changes made after usability testing
Future scope
01. The Design
🛈 Context
About the project
Teams in the UXM Community participated in a 48-hour challenge to build various features for travel booking apps. My team explored new feature designs for Agoda and I chose to build a faster checkout feature for it.
My objective was to simplify and speed up the booking process for travelers to increase the conversion rates on Agoda.
🤔 Understanding the problem
How do we hotel bookings fast and easy for travelers on short day trips?
For the faster checkout feature, I considered the use case of travelers on quick daytime trips (traveling for work, quick visits to friends and family, or travling for emergencies).
Agoda offers short-duration daytime room bookings — called Day Use — that where hotels offer bookings from 2–10 hours at more economical prices.
I felt that the user base of Day Use — travelers on day trips — would spend comparatively lesser time exploring hotel details than travelers on vacation trips. So users of Day Use may benefit from an quicker way to book rooms, after scanning through basic room information and amenities. A shorter funnel could also increase conversion rates for Agoda.
So I chose to design the Quick Book feature with a focus on Day Use bookings, rather than building it across all hotel bookings.
💡 Solution
Quick Book — a feature to help you book rooms ultra fast
Quick Book allows customers to complete their booking in 2 steps, while selecting their booking options quickly and reviewing relevant details.
The feature uses the curation of relevant information and pre-selection of options to speed up the room booking flow.
I designed the Quick Book flow to bypass multiple screens and long scroll time. See the comparison of the 2 flows below —
I planned a few important details and functions that the user should be able to perform using the Quick Book flow —
- Viewing relevant information about the hotel and the room
- Changing the room type and number of rooms they want to book
- Selecting a booking package and time slot for their stay
The Quick Book flow starts on the search results page —
1 — Customers enter their destination, the date of booking and room requirements
2 — The Quick Book option is directly available on the hotel cards in the search results page.
Users can use Quick Book for faster room booking, or tap the hotel card to see full details (entering the normal booking flow)
Tapping the Quick Book button leads users to an overlay —
1 — The overlay has a pre-selected room
Users have the option to change rooms
2 — A price package is pre-selected with a carousel of other available deals
The deals cards show information that can help users make a decision without having to explore extensively
3 — Users can choose from the available check-in times in the carousel
4 — The check-in and check-out times are auto-calculated based on what the user selects and what duration of stay that the hotel provides
5 — Users have the flexibility to change the number of rooms
Tapping Book Now leads users to a final review and payments page —
1 — The room customizations are put into a collapsible section to reduce scroll time for the user, and lead them quickly to booking completion.
The review page allows users to review all the booking details like the hotel name, room type, duration and time, number of rooms. Pre-filled contact details reduces the number of tasks that the user needs to perform here. (these are existing features that I retained as such, since they work well)
Check out the prototype of Quick Book here:
02. The Process
🧭 Setting a direction for my project
A little AI helped me quickly set the direction for how I would approach teh faster bookings feature. I used (the now very famous) chatGPT to generate a brief for faster checkout, to consider possible business metrics that I can target, how I might help users with this feature, and the possible constraints. I found some information relevant and refined whatever needed more clarity.
Based on the brief I generated, I refined and made note of some important points to give me a direction for this project:
Feature name: Faster Checkout
Core idea of the feature:
- Designed to streamline and speed up the booking process on the Agoda platform.
- Can include features that reduce the tasks and time spent by the users (such as pre-populating form fields, storing payment and contact information, and allowing users to quickly review and confirm their bookings)
How we might help users & the business:
- Reduce the risk of users abandoning their bookings due to a lengthy or complicated checkout process.
- Increase customer satisfaction and conversion rates for Agoda.
📝 Research: Current experience and competitor analysis
The first step in creating the concept for Quick Book was a background study on how the Day Use feature works in Agoda, and what similar features other travel booking platforms are implementing.
Day Use is a room booking feature that Agoda offers to travelers who need a place to stay during short day-time trips. Agoda seems to be treating Day Use as a separate vertical, with a separate search tab and search listings page. Users can enter their destination location, the date for which they need a room, and the number of people who will be staying. Search listings show the hotels that have Day Use rooms available and upto how many hours of stay are available (this representation turned out to be misleading and has the potential to lead to drop offs. Read more about it here).
Currently the booking process on Agoda takes users through 4 pages
- Search listings
- Hotel page
- Room selection + deals selection + time selection
- Payment details
Next I looked through competitor products to see if and how they were implementing faster checkout. I found that GoIbibo does this for a similar short-duration booking option called Hourly Stays.
GoIbibo gives users a way to select their duration and check in time directly from the hotel cards in the search listings page. The app also prefills customer details on the final review page before payment, and so reduces the number of tasks being performed by users.
✋ Understanding constraints
I noticed that hotels on GoIbibo offer multiple options for the duration of stay (3,6, & 8 hours based on availability of time slots). On the other hand hotels on Agoda seemed to offer a fixed number of hours for any given hotel; it also seemed like there was no option to change the check-in time for some hotels.
This was confusing since Agoda markets flexible bookings on Day Use, anywhere from 4–12 hours. So I wanted to understand deeper about why Agoda chose not to offer multiple durations of stay on their hotels.
I tried to approach Agoda’s customer service (without success, since I did not have an active booking) and search internet resources for how Day Use bookings work. But when this did not give me clarity I decided to look through the app once more to identify patterns.
After exploring how time slots are offered on different hotels from different location I found that
- hotels decide at what time they will open day bookings and what time they will close.
- hotels also decide the number of hours their rooms can be booked for (this is currently a fixed number of hours for each hotel, say 5 hours or 9 hours)
Considering these constraints, the existing architecture of the interface was misleading since it indicated that users had the freedom to select any check-in and checkout time and adjust their duration of stay (when the option is not currently available).
I realised I could not directly take inspiration from competitor products and offer flexible timings for booking rooms under Day Use. I decided to work with the constraints Agoda’s Day Use and build the Quick Book feature such that it communicates what users can do in a much better way.
🚧 Wireframing & building the UI
I made a few assumptions about the target customers that helped guide my design decisions
- In Day Use, customers can only book rooms for daytime hours (ranging anywhere around 7 AM — 8 PM depending on the hotel). So I assumed that Agoda’s target user base for this would be business travelers, people visiting for emergencies, or people visiting a new location for short day trips.
- I assumed that people on a day trip may not need to explore the features of the hotel and room extensively, unlike someone who is booking rooms for a holiday.
I also assumed that detailed hotel and room information may not be necessary for frequent travelers who may already be familiar with certain hotels that they regularly book with. - Day Use customers are more likely to look for a few basic details about the location of the hotel from the airport and what useful amenities are available in the room.
Based on these assumptions I decided to give users a way to book rooms directly from the search listings page by adding a Quick Book button to the hotel card that would open an overlay displaying the relevant booking options and brief information to customers.
The Quick Book button gives customers the option to bypass the hotel details and room details pages to book faster (users can still go to these pages if they want by tapping on the hotel card).
On the search results cards, I retained the information about the distance from the airport, ratings, and available promotional offers. I also retained the price and copy indicating the duration of stay (e.g “upto 5 hours”). Although I wanted to make the messaging around durations clearer, I decided to test the current messaging with real users first.
I decided to reduce the number of tasks the users would have to perform by pre-filling certain choices and by allowing them to make the necessary selections in one step within the same overlay.
1 — The Quick Book overlay opens once customers tap the button on the search results page.
2 — Users can see the pre-selected room and change it if needed. The deals section shows the available price packages for the room with information about what is included in the deal.
3 — Users can choose a check-in time from the list of available timings. This removes the misunderstanding (in the original app interface) that users can increase or decrease the duration they want to book.
4 — Tapping Book Now would lead users to the payment details review page.
I built components for my design by taking cues from the layout, text, and colours used on Agoda’s mobile app.
🧪Testing my design
To get unbiased insights about the usability of my design, I tested it with a random sample of users who had volunteered for testing from the UXM community.
Since I had limited time, instead of creating a fully functional prototype, I chose to do the testing questionnaire style for each screen. I used a series of open-ended tasks and questions to know what my users understood from the design, how they would perform various tasks, and what gaps still remained.
Here are the key insights I got from usability testing:
What got validated:
- The concept of Quick Book was validated when users understood and predicted correctly what the Quick Book button would do
- Users understood the actions that could be performed in the overlay (changing their room, selecting a price package and check-in time), and could predict what would happen when they tapped Book Now
What needed to be improved:
- Users misunderstood the copy “Upto 3 hours” to mean that they had the flexibility to book for say 1 or 2 hours.
- Users wanted a way to see room reviews and did not realise they could tap the room rating score to do the same.
- They wanted a way to see more pictures of the selected room.
- They were not sure which deal was selected — they needed a better signifier than the highlight box around the deal.
- They did not have clarity on why there were only a few time options provided for check-in.
Changes made after usability testing —
- Edited the copy on the Quick Book overlay to make it understandable and to better indicate the actions that can be performed
E.g - “Very good” to “See reviews”
Also adjusted the layout and colours of the overlay to improve the hierarchy of information and reduce distractions. - Added a checkbox to indicate which deal has been selected.
- Universally changed the messaging surrounding the duration of stay from “Upto X hours” to “X hours of stay”
- Modified the selected state of the check-in time options, since the previous design made the selected state too similar to a tapable primary CTA
- Added an auto-calculated check-in and check-out time (+ date) for the user to quickly understand and review this information.
- Added the flexibility to view further room details and edit the number of rooms before booking.
See a description of the final solution — jump back to the top
Future scope
This design is my attempt at creating a minimum viable product with the functionalities required to start implementing faster bookings in Agoda. If I had more time here’s what I would explore:
- How to help users find the right hotel faster by indicating the earliest available check-in time for a hotel directly on search listings (instead of having the user see it in overlay in the next step)
- What other amenities this target customer base looks at while booking rooms and how I might indicate these to help customers make more informed decisions
- How social proof and reinforcements can be brought in to nudge customers towards booking
Given how short the flow of this feature is, it would be a lot of fun exploring effective ways to implement these.
