Agoda PBS Config: Price shopping and comparison
Introducing an approval flow for price shopping and comparison at Agoda
Role
Product Designer
Role
Product Designer
Role
Product Designer
Industry
Enterprise B2B
Industry
Enterprise B2B
Industry
Enterprise B2B
Tag
design-system
Tag
design-system
Tag
design-system
Stage 1. Problem Statement and Opportunities
Project Overview: What is the PBS Config tool? How did it support Agoda's business?
During my time at Agoda, I had the opportunity to support the Agoda PBS Config team. This team owned this incredible tool to compare Agoda's prices to its competitors at scale (with large volumes of price comparison). By automating price comparison at scale, many teams across Agoda leveraged the tool to enhance our pricing strategies.
In the initial MVP delivered by the team, the team had yet to consider implementing a gatekeeping mechanism. As such, they needed help controlling the flow of shop requests from various Agoda teams. I came in and designed an approval flow that admins would control.
Your Role:
As a product designer, my primary role was to develop an approval flow to manage incoming configuration requests effectively. I collaborated closely with the PBS Config team, which included business analysts, data analysts, and developers, to introduce this essential feature. We aimed to ensure that only approved requests were processed, improving the tool's efficiency and reliability.
Challenges:
The biggest challenge in introducing an approval process was determining the most relevant information for the admin team to approve incoming requests. Additionally, the tight timeline posed another significant challenge, as I needed to deliver the design within a sprint and a half.
Stage 1. Problem Statement and Opportunities
Project Overview: What is the PBS Config tool? How did it support Agoda's business?
During my time at Agoda, I had the opportunity to support the Agoda PBS Config team. This team owned this incredible tool to compare Agoda's prices to its competitors at scale (with large volumes of price comparison). By automating price comparison at scale, many teams across Agoda leveraged the tool to enhance our pricing strategies.
In the initial MVP delivered by the team, the team had yet to consider implementing a gatekeeping mechanism. As such, they needed help controlling the flow of shop requests from various Agoda teams. I came in and designed an approval flow that admins would control.
Your Role:
As a product designer, my primary role was to develop an approval flow to manage incoming configuration requests effectively. I collaborated closely with the PBS Config team, which included business analysts, data analysts, and developers, to introduce this essential feature. We aimed to ensure that only approved requests were processed, improving the tool's efficiency and reliability.
Challenges:
The biggest challenge in introducing an approval process was determining the most relevant information for the admin team to approve incoming requests. Additionally, the tight timeline posed another significant challenge, as I needed to deliver the design within a sprint and a half.
Stage 2. Research and Ideation
2.1 Opportunity to Align with a New Design System
Given the limited timeframe for this project, I collaborated closely with the product owner to define the requirements for the new approval flow through regular design syncs. An audit of the existing product revealed that the MVP portal had been built without a designer’s input and relied on Bootstrap for its user interface, resulting in a functional but outdated product.
I proposed leveraging Agoda’s existing design system, the Agoda Design System (ADS), to address this issue. Using ADS would reduce the time to production by utilizing its extensive library of pre-built components. Additionally, the PBS Config team would receive support from the ADS team during the adoption phase. This adoption would streamline the design process and align the product with other Agoda applications, ensuring a cohesive and modern user experience.
Although the engineering team was concerned about a major overhaul, the benefits of adopting ADS far outweighed the effort required.
2.2 First Iteration
The first step of the design was refreshing the existing table list of all configs using ADS.
As I worked on the table, I sought to understand the most important information for an admin user when deciding to approve or reject a config request.
The primary user of this new portal provided valuable insights into the information her team needed to make decisions.
Information Needed from an Admin’s Perspective:
Information on the Config Itself:
Config ID
Config Name
Config Run Frequency
Number of Shops
Cost of Each Config
Approval Status
Assignment Type (indicating which team is requesting this type of config)
Config Relationship (indicating whether this is a parent or child config)
Information on the Parameters of the Shops Done:
Lead Time
Length of Stays
Occupants
Domain Segment
Currency
Language
Origin (whether this is a domestic or international booking)
Information About the Requestor:
Who Created the Config
When the Config Was Created
Given the extensive information about the configs, we designed an intuitive interface where users could easily drill down into specifics without being overwhelmed by excessive initial details.
2.3 Additional Changes
Through further syncs with the product owner, we decided to nest all actions under a hamburger menu to streamline the user interface.
2.4 Final Iteration
In the final iteration, we addressed edge cases for various scenarios:
Handling approvals of config requests
Handling denials of config requests
Managing system errors on the backend during config requests
Handling filtering
This comprehensive approach ensured the design was robust and user-friendly, accommodating various potential issues.
Stage 2. Research and Ideation
2.1 Opportunity to Align with a New Design System
Given the limited timeframe for this project, I collaborated closely with the product owner to define the requirements for the new approval flow through regular design syncs. An audit of the existing product revealed that the MVP portal had been built without a designer’s input and relied on Bootstrap for its user interface, resulting in a functional but outdated product.
I proposed leveraging Agoda’s existing design system, the Agoda Design System (ADS), to address this issue. Using ADS would reduce the time to production by utilizing its extensive library of pre-built components. Additionally, the PBS Config team would receive support from the ADS team during the adoption phase. This adoption would streamline the design process and align the product with other Agoda applications, ensuring a cohesive and modern user experience.
Although the engineering team was concerned about a major overhaul, the benefits of adopting ADS far outweighed the effort required.
2.2 First Iteration
The first step of the design was refreshing the existing table list of all configs using ADS.
As I worked on the table, I sought to understand the most important information for an admin user when deciding to approve or reject a config request.
The primary user of this new portal provided valuable insights into the information her team needed to make decisions.
Information Needed from an Admin’s Perspective:
Information on the Config Itself:
Config ID
Config Name
Config Run Frequency
Number of Shops
Cost of Each Config
Approval Status
Assignment Type (indicating which team is requesting this type of config)
Config Relationship (indicating whether this is a parent or child config)
Information on the Parameters of the Shops Done:
Lead Time
Length of Stays
Occupants
Domain Segment
Currency
Language
Origin (whether this is a domestic or international booking)
Information About the Requestor:
Who Created the Config
When the Config Was Created
Given the extensive information about the configs, we designed an intuitive interface where users could easily drill down into specifics without being overwhelmed by excessive initial details.
2.3 Additional Changes
Through further syncs with the product owner, we decided to nest all actions under a hamburger menu to streamline the user interface.
2.4 Final Iteration
In the final iteration, we addressed edge cases for various scenarios:
Handling approvals of config requests
Handling denials of config requests
Managing system errors on the backend during config requests
Handling filtering
This comprehensive approach ensured the design was robust and user-friendly, accommodating various potential issues.
Impact and next steps
I left Agoda shortly after I handed off my deliverables to the engineering team. However, I followed up with the Product Manager to see how the implementation went and understand the team's next steps.
Impact and next steps
I left Agoda shortly after I handed off my deliverables to the engineering team. However, I followed up with the Product Manager to see how the implementation went and understand the team's next steps.
