How We Prioritize Requests in Agoda’s Design System

A step-by-step approach to managing and prioritizing requests in your design system.

11 min readOct 16, 2024

Agoda Design System

Agoda’s design system began in 2018 as a small developer-led side project and has since grown into a cross-functional team of nearly 20. A key challenge we faced was helping leadership recognize the value and impact of a well-structured design system.

As the Agoda Design System (ADS) grew and more teams adopted it, new challenges emerged, especially in managing increasing demands.

We now support over 60 product teams and 1,600+ designers and engineers, launching over 100 A/B tests across four platforms weekly. With nearly 100% monthly active adoption of ADS across our consumer-facing teams, a new challenge arose — managing all of the work!

Identifying the root causes

As our workload grew, it became clear we needed a better way to prioritize requests. Conflicting needs from different teams left us struggling to justify why one request was prioritized over another.

At nearly 20 people, internal coordination became challenging, leading to misaligned priorities and dropped requests, frustrating our team and stakeholders.

A common challenge we faced was managing timeline expectations from fast-moving, velocity-driven teams that relied on us. As Josh Clark put it in his great article Ship Faster by Building Design Systems Slower, “When a design system team isn’t delivering new features, components, or patterns as fast as product teams need them, the team believes it’s a bottleneck.”

We faced this issue as well, compounded by the fact that many teams didn’t realize how many requests we were handling, which led to misaligned expectations. Additionally, a lack of transparency eroded trust as teams struggled to track progress or understand our decision-making process.

To tackle these issues, we developed new processes, implemented a prioritization framework, and improved communication. In the following section, we will walk you through these solutions and share some resources that can help your team.

Overview of our new process

This is what our new request journey looks like in ADS. It starts with the request, which can be submitted by anyone at Agoda.

Then, our team will review, prioritize, and groom the request. Once it’s been groomed, it can be picked up by our team or any contributing team that needs the change. It’s pretty straightforward so far.

Let's dive deeper into each part of this journey to learn more:

How we handle new requests

We’ve streamlined how we manage new requests by setting up a dedicated Jira board exclusively for requests. This board organizes everything by status and prioritizes requests from highest to lowest.

You can easily see the type of request and the total number, and there are filters to sort by status or platform for more specific views.

Our team supports a couple of different requests:

Feature requests — These include new components or added functionality in existing components, utilities, or patterns.
Visual assets — Icons, illustrations, country flags, logotypes, etc.
Tokens — New design tokens or overhauls of existing ones.
Tooling — Improvements to our documentation platform, Figma plugin, or tech tooling that our team provides.

Anyone can submit a new request, and we’ve tailored the fields based on request type to gather key details, like a problem statement and proposed solution. We’ve also provided Figma templates that include design specs, use cases, and other essential information to help us fully understand the request.

While the process may seem detailed, it helps us ensure that we fully understand the requester’s needs and that the request is truly essential. We also offer plenty of other avenues for feedback, ideas, and bug reports — such as our Slack channels for each component, which serve as great spaces for discussions and inspiration.

How do we prioritize the requests?

Next, we will explain how we ensure unbiased and transparent prioritization, focusing on business needs:

To do this, we score requests based on four key criteria:

1. Product Area

2. Reusability

3. Alternative Solutions

4. Effort

Each criterion is rated on a scale from “high” to “won’t fix,” and the total score determines the final priority. We intentionally weight these criteria differently — reusability, for instance, carries more weight (15 points) than low effort (10 points) because of its long-term impact.

We chose to customize our framework to our specific needs. However, it has many similarities with more established frameworks, such as the RICE scoring method, which Stuart Smith recommends in three ways. In this way, we’ve energized our design system governance, which we can recommend reading.

To illustrate how this process works, let’s consider an example — a team requests an enhancement to our existing date picker component, asking for the ability to select years far in the past or future:

1 — Product area

First, we assess the Product Area. Does the request address a need from a business-critical project, product, or team?

Let’s say this year’s selector was requested for an important upcoming launch — in that case, it would receive the highest score.

2 — Reusability

Second, we check if the solution can be reused across multiple platforms, features, or teams.

To evaluate all requests fairly, we had to define exactly what reusability means for us:

Platforms & Funnels: For the year selector, it’s relevant across all platforms — hotels, flights, and activities. It could also be used for things like date of birth or passport expiry, so the reusability is high.
End-user impact: Many users could benefit from this feature, but far from all use cases. Therefore, we would score the impact on end-users as medium, as a majority might benefit, but not all.
Impact on our supported teams: We’ve documented use cases from a handful of supported product teams in our organization, so that’s medium as well.
Change frequency: Given its complexity, we foresee many tweaks and change requests down the line, which might make this feature high maintenance. We generally want to avoid this, so we would score this as low.

Overall, reusability would land at medium:

3 — Alternative solutions

Third, do we already have something in place that could solve the problem?

For the example of the year selector, a simple dropdown or input field might work in some cases. But in other cases, it’s essential to keep the year selection within the date picker, so we score this as a medium.

4 — Ease of implementation

How much work is required? We prioritize low-hanging fruit, as even small fixes can unblock teams quickly. We’d rather tackle ten small blockers than focus on a single, larger issue.

Date pickers are complex, with different UX requirements across implementations, so this change would require significant work. Therefore, the score for this feature is low.

Final score

Summing up the scores, we get a total of 30 out of 50, putting this request in the medium-priority category:

This means we might not tackle it immediately, and the requesting team may need to contribute to the change.

On-call squad

So, that’s how we score our requests, but who handles all of this? Given the significant support we need to provide our teams, we have taken inspiration from DevOps and implemented a rotating on-call squad consisting of a designer, engineer, PM, and our QA specialist.

One of the responsibilities of this squad is to review new requests. If a request needs more detail or doesn’t align with the system, the squad sends it back to the requester, giving them a chance to improve it for another review the following week.

Our framework and process are well-documented so that all teams can learn and provide feedback in our internal knowledge hub.

While it may feel over-engineered for some, it offers a solid foundation for decision-making and communicating priorities with stakeholders. Of course, it can always be adapted to fit your team’s specific needs.

3 — Taking action on the requests

Once a request is prioritized, the next step is grooming. Every two weeks, our team meets to groom the requests, creating tickets for design and implementation across platforms. These tickets are stored in separate boards for each scrum team and linked back to the original request, making it easy to track dependencies and contributions from other teams.

From here on, teams can follow their existing processes for getting the work done. We will mark the request as “In progress” as soon as any team starts working on it:

Stakeholders can easily track the progress by viewing the status of all linked tickets within the request. They can also add themselves as watchers to receive automated updates on any changes or comments related to their requests.:

We quickly realized that relying solely on Jira notifications wasn’t effective, as many stakeholders missed updates. So, we added Slack announcements to ensure visibility:

For example, our designer Parn recently shared improvements to our bottom sheet component, along with a quick Figma video tutorial. This kind of proactive communication is highly appreciated by the teams!

Summary of our processes and rituals

This is our request process in a nutshell:

• Submitting Requests: Anyone can submit a request using Jira and Figma templates.

• Review Process: We review new requests in weekly intake meetings.

• Grooming: We groom requests as a team and create tickets, which are then managed by scrum teams.

• In progress: Requests are tracked through Jira and Slack, and stakeholders receive updates via email and Slack.

• Done: When the work is done, changes are announced, and the requester is kept informed throughout the process.

With a clear end-to-end workflow, a thoughtful prioritization framework, and well-established rituals, we’re able to keep stakeholders informed, manage expectations, and handle our workload more effectively.

Key Learnings

Before wrapping up, we’d like to share a few things we’ve learned and some tips to help you get started with your own process.

A clear process is an inclusive process

With a defined process in place, the team can share the responsibility of leading rituals, allowing leads to focus on strategic work while creating growth opportunities for everyone.

Fewer detailed debates

The process has shifted discussions from debating individual requests to refining the overall framework, improving decision-making, and fostering continuous improvement.

Strengthening understanding with stakeholders

The process has clarified the demand for our design system and improved communication with leadership and other teams. Quarterly surveys show significant improvement in communication and transparency since the process was introduced.

Trade-offs and priorities

Balancing trade-offs between better design and faster delivery is an ongoing discussion with leadership. Our request board provides insights that highlight gaps in the system, showing that the design system is always evolving.

Bandwidth and contributions

We currently receive five times more requests than we can handle, and scaling contributions remains a challenge. While our prioritization framework ensures we focus on the most critical tasks, the question remains — what about the rest?

We’re actively exploring ways to introduce contributions at scale while maintaining the system’s integrity, but we’re not quite there yet.

Conflicting timelines

As a platform team, we often face the challenge of aligning our delivery with the faster timelines of high-velocity product teams. We don’t want to become blockers or slow down innovation, but finding the right balance remains an ongoing challenge we have yet to fully solve.

Tips for getting started

If your team is facing similar challenges, here are some tips to help you get started with a process like ours:

1. Define your prioritization framework

Involve your stakeholders early to build a shared understanding of trade-offs and company-wide priorities, not just those of your team. This will smooth the rest of your journey. You can use our template as a starting point and take it from there.

2. Centralize requests

Keep all requests in one place to get a complete overview of the demand of your system. This will also help make the case for further investments to your team.

One thing we’ve learned is that bugs and other “business as usual” tasks take up a lot of our capacity — up to 50% at times. But we didn’t include these in our request board, and thus, other teams were not aware that we were working on these. Consider including them for complete visibility.

3. Establish routines

Create routines and standardize workflows to move things forward efficiently. Identify where feedback loops are needed and bake these into the process.

4. Communicate with stakeholders

Plan how you’ll keep stakeholders informed. Regular communication is key to managing expectations and building trust.

5. Learn and iterate

Track key data points and use them to advocate for your team’s needs. Continuously refine your process as you go. Cater it to your team’s specific challenges and needs.

This article is based on a talk by our Principal Product Designer, Alexander Fanden at the Into Design Systems Conference.

Agoda Engineering & Design