A step-by-step approach to managing and prioritizing requests in your design system.
This article is an adaptation of my talk from the Into Design Systems Conference earlier this year. I’ve been thrilled by the positive feedback and inspired by how many teams have applied their own versions of our process. By sharing this in written form, I hope to reach even more teams looking to bring structure and clarity to their evolving design systems. For those who didn’t catch the talk, or simply prefer reading, I hope you find this article helpful. Enjoy!
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.
When I joined to lead the design of the system in 2022, a key challenge was helping leadership understand the value of a 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 4 platforms weekly. With nearly 100% monthly active adoption of ADS across our consumer-facing teams, a new challenge arose — dealing with 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 both 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 experienced this 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. Next, I’ll walk through these solutions and share resources to help your team.
Overview of our new process
This is how 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 contibuting team who needs the change — pretty straightforward so far.
Lets 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.
Out team supports a couple of different requests:
Feature requests — such as new components or added functionality in existing components, utilities or patterns.Visual assets — Icons, illustrations, country flags, logotypes and 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 we prioritize the requests
Next, I’ll 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 — Although it has a lot of similarities with more established frameworks, such as the RICE scoring method which Stuarth Smith recommends in 3 ways we’ve energised our design system governance, which I can recommend to read.
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 that this year selector was requested for a imporant 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 would be 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 organisation, so that’s medium as well.Change frequency: Given its complexity, we forsee a lot of tweaks and change requests down the line, which might make this feature high in maintenance. This is something we in general want to avoid, 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 medium.
4 — Ease of implementation
How much work is required? We prioritize low-hanging fruits, as even small fixes can unblock teams quickly. We’d rather tackle 10 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 the change.
On-call squad
So that’s how we score our requests, but who does all of this? Given the fair amount of 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.
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 send it back to the requester, giving them a chance to improve it for another review the following week.
Our framework and process is well-documented for all teams to 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. And, 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, I’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 whole team can share the responsibility of leading our rituals, freeing me to focus on strategic work while providing growth opportunities for the team.
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.
Further reading and references
See my Notion page for all community resources related to this article — find our request framework, Figma request templates insightful articles.This article was based on my talk at the Into Design Systems Conference which is available for free on YoutubeMy other talk “How we migrated to Figma and what we learned” is also available to watch on YoutubeShip Faster by Building Design Systems Slower By Josh Clark, Big MediumMaking design system governance a breeze — not a bottleneck, and the follow-up article 3 ways we’ve energised our design system governance by Stuart SmithThe definitive guide to running productive and happy on-call teams by AtlassianRICE: Simple prioritization for product managers by Intercom
If you’ve made it this far — thank you so much for reading and I hope you’ve found it helpful 🌟 You can find me on Linkedin or subscribe to my Medium profile for more Design Systems content!
Prioritizing design systems was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
