Agoda's YCS Mobile Bookings feature
Crafting the mobile experience on Agoda's partner extranet tool
Role
Product Designer - Enterprise
Role
Product Designer - Enterprise
Role
Product Designer - Enterprise
Industry
B2B - Travel and Tourism
Industry
B2B - Travel and Tourism
Industry
B2B - Travel and Tourism
Tag
design-system
Tag
design-system
Tag
design-system
Stage 1. Problem statement and opportunities
Project Overview
YCS is Agoda’s extranet portal for hotel partners. It enables them to manage bookings and allotments, receive payments, and gain insights into their property's performance compared to competitors. In February 2024, I redesigned the bookings page for mobile users.
Your Role
As a product designer, I defined the scope of deliverables, ideated and designed for mobile users, and regularly collaborated with the product owner and engineers to ensure alignment. I also leveraged Agoda’s existing design system to expedite production.
Challenges
The biggest challenge was adapting pages or features for mobile use without introducing new design approaches, such as with the price breakdown subpage.
Stage 1. Problem statement and opportunities
Project Overview
YCS is Agoda’s extranet portal for hotel partners. It enables them to manage bookings and allotments, receive payments, and gain insights into their property's performance compared to competitors. In February 2024, I redesigned the bookings page for mobile users.
Your Role
As a product designer, I defined the scope of deliverables, ideated and designed for mobile users, and regularly collaborated with the product owner and engineers to ensure alignment. I also leveraged Agoda’s existing design system to expedite production.
Challenges
The biggest challenge was adapting pages or features for mobile use without introducing new design approaches, such as with the price breakdown subpage.
Stage 2. Scoping
From the start of this project, I worked with the product manager to define deliverables, splitting the project into three phases. Phase 1 focused on recreating all static pages for mobile, and Phase 2 included features like verifying credit card information.
Although I didn't work on Phase 3, it involved introducing features and subpages supported by other teams for the mobile experience.
In the following study, I focus on Phase 1 and Phase 2.
Stage 3. Static pages (Phase 1)
3.1 Search page
3.1.1 Search bar
The first task I tackled when designing the static pages was the search bar. User research on the desktop version showed that most hotels:
Primarily searched by dates
Preferred to find bookings within the week
Based on this, we emphasized dates in our search bar design.
We also made sure hotels could filter their searches by guest name and booking ID.
Lastly, we added filters for room type, rate plan type, channel type, and payment method.
When filters are applied for a specific room type, rate plan type, and/or payment method, we show the applied selection as a dismissible chip under the search bar. By default, we apply a "select all" approach to filters.
Stage 3. Static pages (Phase 1)
3.1 Search page
3.1.1 Search bar
The first task I tackled when designing the static pages was the search bar. User research on the desktop version showed that most hotels:
Primarily searched by dates
Preferred to find bookings within the week
Based on this, we emphasized dates in our search bar design.
We also made sure hotels could filter their searches by guest name and booking ID.
Lastly, we added filters for room type, rate plan type, channel type, and payment method.
When filters are applied for a specific room type, rate plan type, and/or payment method, we show the applied selection as a dismissible chip under the search bar. By default, we apply a "select all" approach to filters.
However, during my sync with the product manager, there was feedback that this simplified search bar might reduce feature discoverability and make the search functionality less usable. A Senior Product Designer suggested that we make each search category a distinct row like this:
While I understood the feedback, I was concerned that having distinct rows for each search category would take up too much space on mobile screens. Instead, I proposed placing the filters beside the search button.
Edge cases
For edge cases, I identified four types of errors:
When the selected dates are more than 366 days in the past or future.
When special characters are entered in the booking ID/name search field.
When the search yields no results.
When there is a system error
Edge cases
For edge cases, I identified four types of errors:
When the selected dates are more than 366 days in the past or future.
When special characters are entered in the booking ID/name search field.
When the search yields no results.
When there is a system error
3.1.2 Booking cards
Next, I focused on how to display booking information. On the desktop view, we used a table to list bookings by status (Confirmed, Amended, Cancelled).
Space was limited for the mobile view, so we decided to use card components for a more digestible layout. I designed four options, and we chose option 1 because its clearly labeled action buttons provided better user affordance. Although Option 1's use of iconography was appealing, the lack of icons in Option 3 helped avoid distractions. We also placed stay duration information next to the stay dates.
3.1.2 Booking cards
Next, I focused on how to display booking information. On the desktop view, we used a table to list bookings by status (Confirmed, Amended, Cancelled).
Space was limited for the mobile view, so we decided to use card components for a more digestible layout. I designed four options, and we chose option 1 because its clearly labeled action buttons provided better user affordance. Although Option 1's use of iconography was appealing, the lack of icons in Option 3 helped avoid distractions. We also placed stay duration information next to the stay dates.
3.2 Booking details page
The booking details page was part of Phase 1. It was simple enough that I only needed to change the information layout from horizontal to vertical.
The more complex task was adapting the price breakdown sub-page for mobile. I tackled this by using a card design, grouping all price-related information in a single card for each stay date. These cards were then placed on a scrollable bottom sheet.
3.2 Booking details page
The booking details page was part of Phase 1. It was simple enough that I only needed to change the information layout from horizontal to vertical.
The more complex task was adapting the price breakdown sub-page for mobile. I tackled this by using a card design, grouping all price-related information in a single card for each stay date. These cards were then placed on a scrollable bottom sheet.
Stage 4. Property collect features (Phase 2)
In the second phase, we had to design four features for bookings where the property collects payment from hotel guests:
Search Page's action menu
Mark as no-show
Verify credit card
Request a new credit card
Cancel booking when a credit card is not provided
View payment card details. We decided, however, to make this feature only available on the desktop view.
4.1. Search Page's action menu
From the search page, hotels can trigger a menu of actions they can take on bookings (Mark as a no-show, Verify credit card, Request a new credit card) while browsing through cards.
I proposed three design options for this action menu:
Option #1: A bottom sheet with actions and some information, forming call-to-action buttons.
Option #2: A bottom sheet with actions as call-to-action buttons, each with attached information.
Option #3: A bottom sheet with simple call-to-action buttons and tooltips that display more information in a modal.
Option #3, though it added an extra step, offered clear call-to-action buttons and detailed information about each action.
4.2. Mark as a no-show (Feature)
Within 72 hours of the check-in date, hotels can mark a guest as a no-show and cancel the booking. Before that, the "mark as no-show" button is disabled.
Once enabled, if the hotel chooses to go ahead and mark the guest as a no-show, it follows the following flow:
4.3. Verify credit card (Feature)
Another feature I had to account for was verifying credit cards. Since the flow already existed on the desktop, recreating it on mobile was straightforward.
In the simplest scenario, upon clicking the "Verify now" button, the hotel receives confirmation that the card is valid and successfully verified that day.
When the card is invalid for any reason, we can request the hotel guest to provide new card details. Note that the following flow is also triggered when the hotel clicks on the "request a new card" button to ask for a new card from the guest.
If the hotel guest provides new card information, we inform the hotel:
If the hotel guest doesn't provide any information within 72 hours of the check-in date, the hotel can cancel the booking.
4.4. Request new credit card (Feature)
This feature follows the same flow used in the card verification process for requesting a new valid card.
4.5. Cancel booking (No CC)
If a credit card is not provided by hotel guests, the booking can be canceled in certain cases:
The hotel can cancel the booking if the guest has not confirmed their stay 14 hours before check-in.
However, if the guest confirms their stay 14 hours before check-in, the hotel cannot cancel the booking.In other cases, a machine-learning algorithm handles cancellations by determining if a guest is a high-risk no-show.
If a guest is likely to check in, as determined by the machine-learning algorithm, we do not allow hotels to cancel.
Stage 5. Chat feature
On the booking details page, users can always access a "chat" button that opens a chat window with the guest:
At the top of the page
At the bottom of the page
From the search page of bookings:
Next steps and acknowledgments
In Phase 3, we planned to introduce features and subpages built and supported by other teams as part of the mobile experience. Unfortunately, I didn't get to work on Phase 3 because I decided to transition out of Agoda. I credit much of my success on this project to my extensive collaboration with Brady Liu (Senior Designer - Enterprise), Lei Lei Wu (Product Owner), and the team of over 20 engineers who supported this product feature launch.
Stage 4. Property collect features (Phase 2)
In the second phase, we had to design four features for bookings where the property collects payment from hotel guests:
Search Page's action menu
Mark as no-show
Verify credit card
Request a new credit card
Cancel booking when a credit card is not provided
View payment card details. We decided, however, to make this feature only available on the desktop view.
4.1. Search Page's action menu
From the search page, hotels can trigger a menu of actions they can take on bookings (Mark as a no-show, Verify credit card, Request a new credit card) while browsing through cards.
I proposed three design options for this action menu:
Option #1: A bottom sheet with actions and some information, forming call-to-action buttons.
Option #2: A bottom sheet with actions as call-to-action buttons, each with attached information.
Option #3: A bottom sheet with simple call-to-action buttons and tooltips that display more information in a modal.
Option #3, though it added an extra step, offered clear call-to-action buttons and detailed information about each action.
4.2. Mark as a no-show (Feature)
Within 72 hours of the check-in date, hotels can mark a guest as a no-show and cancel the booking. Before that, the "mark as no-show" button is disabled.
Once enabled, if the hotel chooses to go ahead and mark the guest as a no-show, it follows the following flow:
4.3. Verify credit card (Feature)
Another feature I had to account for was verifying credit cards. Since the flow already existed on the desktop, recreating it on mobile was straightforward.
In the simplest scenario, upon clicking the "Verify now" button, the hotel receives confirmation that the card is valid and successfully verified that day.
When the card is invalid for any reason, we can request the hotel guest to provide new card details. Note that the following flow is also triggered when the hotel clicks on the "request a new card" button to ask for a new card from the guest.
If the hotel guest provides new card information, we inform the hotel:
If the hotel guest doesn't provide any information within 72 hours of the check-in date, the hotel can cancel the booking.
4.4. Request new credit card (Feature)
This feature follows the same flow used in the card verification process for requesting a new valid card.
4.5. Cancel booking (No CC)
If a credit card is not provided by hotel guests, the booking can be canceled in certain cases:
The hotel can cancel the booking if the guest has not confirmed their stay 14 hours before check-in.
However, if the guest confirms their stay 14 hours before check-in, the hotel cannot cancel the booking.In other cases, a machine-learning algorithm handles cancellations by determining if a guest is a high-risk no-show.
If a guest is likely to check in, as determined by the machine-learning algorithm, we do not allow hotels to cancel.
Stage 5. Chat feature
On the booking details page, users can always access a "chat" button that opens a chat window with the guest:
At the top of the page
At the bottom of the page
From the search page of bookings:
Next steps and acknowledgments
In Phase 3, we planned to introduce features and subpages built and supported by other teams as part of the mobile experience. Unfortunately, I didn't get to work on Phase 3 because I decided to transition out of Agoda. I credit much of my success on this project to my extensive collaboration with Brady Liu (Senior Designer - Enterprise), Lei Lei Wu (Product Owner), and the team of over 20 engineers who supported this product feature launch.
Other projects
NerdWallet's design system revamp
Consolidating NerdWallet's Design System Libraries in Figma
Dell's Data visualization library
Designing data visualization color palettes for Dell's design system
Agoda PBS Config: Price shopping and comparison
Introducing an approval flow for price shopping and comparison at Agoda