My Role
As a product design intern under the supply team, I owned the project within internal tools aimed at improving how incidents are prioritized and managed. Skills and techniques I utilized include: domain-knowledge acquisition, conducted user interviews, facilitated in-person workshops, high-fidelity prototyping, and usability testing.
Project Scope
I worked on this project from May - Aug 2023 as a part of an internship with Agoda (Booking Holdings Inc.) under the supply team.
Project Outcomes
+ Secure buy-ins for my redesign from design leadership
+ Hand off my designs and documentation to developers by the end of my internship period
Background
Agoda is a leading online travel agency in South East Asia and is a subsidiary of Booking Holdings Inc.
The overarching goal of this project is to improve the usability of the Global Incident Notification (GIN) Form, an internal tool that the NOC team and developers use to prioritize and manage incidents at Agoda.
Challenge
The GIN form is an internal tool utilized by developers and the Network Operation Center (NOC) to prioritize and manage incidents at Agoda. The goal of the form is to better allow stakeholders to be informed of the important incidents that affect Agoda, including their services, network, business activities, etc. and enable them to take appropriate and timely actions based on the situation.
Coming into the internship, both the NOC team and developers described the GIN form as being "too complex and confusing".
"Unplanned GIN Request Form" page of GIN Form
Preliminary research
Given the project's limited context and ambiguous scope, I spent significant time acquiring domain knowledge by reviewing existing research and documentation on the GIN Form's functionality and pain points. I focused on understanding technical concepts, creating clear flow diagrams, and summarizing key insights to communicate effectively with those less familiar with the problem space.
This was important because I believe that approaching the problem with subject-matter expertise will allow me to better accurately frame the problem, communicate with my users, identify user needs, and conduct more meaningful analyses.
Key Insights
As I now gained a lot of domain knowledge about the GIN Form, I conducted preliminary user interviews with 9 members of the NOC team and 5 developers to understand how GIN Forms are used on a day to day basis. In these group and one-on-one interviews, I asked questions about domain knowledge, user experience, pain points, and tech limitations regarding their experience with using the current GIN Form.
Contrasting pain-points and observations emerged as I synthesized my interview notes:
⚒️ NOC Team
We have diverse working preferences
"We have our own methods when completing tasks and filling out the form"
We prioritize efficiency
“Our KPIs (Key Performance Indicators) include productivity and efficiency”
We are familiar with how the current GIN Form works
"We implemented it, so we are experts at the logic and workflow"
💻 Developers
We communicate a lot with NOC
“I have to constantly communicate back-and-forth with NOC on Slack”
We’re not familiar with using the current GIN Form
"I don't know where to click"
We lack specific terminology knowledge about GIN
"I'm not sure how to fill this part out because I don't understand what it means"
With these insights, I then moved onto conducting heuristic evaluation on the pages that both NOC and Developers ranked as being of highest priority.
Heuristic evaluation
In order to better visualize how the developers request planned maintenance with the current form, I sat down with them to go through the form's functionality and each form component. Then, I annotated how pain points I found during user research relate to the UI. I was able to learn about their thought process when they created the form, learning about what they intended by each area of the form and how they wanted the form to be used by their team.
Some aspects that violated the usability heuristics included:
❌ It was easy for developers to make errors that cost a lot of time and effort for the NOC team
Heuristic #5: Error prevention
❌ A lot of terms were unfamiliar to developers
Heuristic #2: Match between system and the real world
❌ The form included a lot of information that was rarely needed
Heuristic #8: Aesthetic and Minimalist Design
Adjusting workflow
With the patterns and insights found from the heuristic evaluation, I recognized that it was not only a UI issue, but providing an effective solution required restructuring the user flow. To give an example from the issue below:
❌ It was easy for developers to make errors that cost a lot of time and effort for the NOC team
Heuristic #5: Error prevention
I identified that a lot of redundancies in communication between the NOC team and developers stem as a result of the low autonomy that developers have when using the current GIN Form. Therefore, I proposed a new change to the flow of how a form is submitted by a developer to request for planned maintenance.
From the proposed flow, I added a “review your form” and “edit form” step. Now the workflow:
✅ Reduces additional work volume for NOC
The review and edit steps allow users to recheck and edit their information before submitting, increasing input accuracy and developer’s autonomy.
Design Changes
I utilized the Agoda Design System (ADS) for the majority of the form redesign to ensure consistency across Agoda's different platforms. However, since ADS is mainly used for their consumer-facing products like their website and app, many components such as input types did not fit the functionality I was looking for. To solve the problem, I made slight modifications to the existing components but tried to keep it as visually uniform with ADS as possible.
Before #1
Red guideline box is redundant for experienced users, but necessary for new-joiners.
The red box includes guidelines which allows developers to understand and remind themselves of how to fill out the form below. Most experienced developers don't refer to the guidelines at all and would scroll past it. However, new-joiners utilize the guidelines as a template but mention that they would rather use documentation provided on Confluence.
After #1
I transformed the red box into an external link.
To decrease the space taken on the page and make the guidelines more informative, I replaced the guidelines with an external link to the documentation on Confluence, providing an option for users to refer to the guidelines if necessary.
Before #2
Developers are confused on how to choose the correct impact level.
Developers are unsure about the definition of each impact level, causing them to have multiple conversations with the NOC team on Slack before being able to select the correct one.
If the impact level is wrongly selected but the form has already been submitted, then a member of the NOC team will have to come back and change it for the developer.
After #2
I changed input style from dropdown to radio buttons with description labels.
Laying out each impact level option with its respective description, expanding upon the requirements of each impact level allows users to choose more accurately and independently, decreasing the amount of work for the NOC team.
Before #3
Developers have to manually input their email.
Requester Agoda email refers to the person who is going to submit the request. Currently the input field is in the middle of the form and requires the user to manually input their email.
After #3
Information is now pre-populated and can be edited.
To decrease the number of fields that the user has to fill in, information is extracted when the user logs in with Okta.
The field is moved to the bottom of the form as it allows the user to review their information at-a-glance before proceeding.
Iterations based on feedback and testing
As the solo designer for this project, I went through 4+ iterations for the design. Since this is an internal tool, the ultimate goal is to make it easy for developers and NOC to use and increase their work efficiency. Therefore, I had multiple feedback sessions with NOC developers to see if my designs lie within technical limitations and aligned with their user needs.
Presenting to Agoda product department
Proposed Solution
Submit and wait for NOC to approve
Start plan and wait for updates
Finish plan and monitor updates
Before
After
What I learned
Challenges
I've learned the importance of asking the right questions, especially when seeking clarification. It’s essential to refrain from asking leading questions that may unintentionally skew the feedback, allowing me to uncover the core issues more effectively. Designing with balance has also been a critical challenge—learning to distinguish between personal preferences and actual problems. This distinction helps in making informed decisions, especially when prioritizing functionality over aesthetics, ensuring that my designs are not just visually appealing but also truly solve user needs.
If I had more time, I would...
Moving forward, I aim to conduct more usability testing with a larger sample size to gather comprehensive insights that reflect diverse user experiences. Testing with a variety of roles, including both experienced individuals and new joiners, will help ensure the design accommodates all levels of expertise. I’m also continuing to refine the incident timeline, a new feature that enhances clarity in tracking issues. Additionally, I’m focusing on designing a dark mode tailored to the needs of the Network Operations Center (NOC) team, who work through the night, to reduce eye strain and improve usability during long shifts.