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 contributing 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 Youtube
• My other talk “How we migrated to Figma and what we learned” is also available to watch on Youtube
• Ship Faster by Building Design Systems Slower By Josh Clark, Big Medium
• Making design system governance a breeze — not a bottleneck, and the follow-up article 3 ways we’ve energised our design system governance by Stuart Smith
• The definitive guide to running productive and happy on-call teams by Atlassian
• RICE: 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.

Part 3: How we migrated our design team to Figma.

As the coronavirus hit the travel industry earlier this year, the design team at Agoda looked at how we could save costs without sacrificing the quality of the work we’re doing. The collaborative features and the opportunity to shrink the cost of multiple license fees to just one were two compelling reasons to review Figma and eventually propose a plan to migrate our whole design organization to the new tool. Here I’ll walk through the research we did and how our working group planned and executed the migration to Figma.

Rolling out Figma to the team

Big changes in big teams need to be carefully executed. As you learned in part 1, we had done our research and learned a lot from other great design teams. We had developed new team structures, workflows, and design system components, and tried them out within our working group for months.

We were finally ready to put it to test with the broader design team! We knew that no matter how much work we had done, it was crucial to get the whole team on board. These are the things we did to straighten out question marks and get people excited about to big change:

Figma week

A full week of presentations, co-working sessions, and pop-quizzes. Each member of our Figma working group presented their work, much of what I’ve covered in this article:

• The rationale behind the migration
• Initial research and ideation
• Organization of teams, projects, and files
• Design systems, UI Kits, etc
• New Workflows
• Sunsetting existing tools

During the presentations, we gathered all outstanding questions and made sure to follow up later on in our Figma Slack-channel. Bigger topics were saved for further action by the Figma working group.

Swag

Everybody loves swag, and our team is no different. We managed to convince the Figma team to send over some socks, t-shirts, pins, and stickers to reward designers in pop-quizzes and design exercises.

Dedicate project owners

In order to make the migration from Sketch as efficient as possible, we assigned each feature(Figma project) to a dedicated designer. This owner would be responsible to keep the project nice and tidy, and the master file(s) up to date. We saw a couple of big benefits of doing so:

• Avoid people waiting for others to do the work
• The ability to set clear deadlines and hold each owner accountable
• Reduced confusion by having a single point of contact on a feature for all designers and stakeholders
• By spreading the responsibility on multiple people we could make sure that no one designer was overloaded with work and responsibilities
• A sense of ownership and accountability might help to raise the bar in terms of design quality

A public Figma channel on Slack

We invited the whole team to a new Figma channel which serves multiple purposes:

• Questions from the team
• Announcements (UI library updates, workflow updates, etc)
• Recommended plugins
• Best practices
• Ideas

Working sessions

We scheduled working sessions with all new project owners to kick-start the migration of the master files.

We all got together in a big meeting room and worked together. The Figma working group was there to help to answer questions and unblock the designers.

Plugins

One of the best ways to work more efficiently is to utilize some of the great plugins available for Figma.

As a rule of thumb, we encouraged our design team to use any plugin that makes work more efficient, but on one condition — It shouldn’t break our designs plugin is no longer updated or if not all designers have access to the plugin.

This is something we learned the hard way as we migrated from Sketch to Figma. Some of our teams had been using the Anima plugin to make the designs more responsive and easier to work with. Importing these files to Figma was a mess and as a result, we had to redesign all pages from scratch using the native tools in Figma — not again!

This article and this website are great resources for Figma plugins that can speed up work.

Initial feedback from the team

Two months into the transition, we surveyed the team to understand what went well and where we’re falling short.

Tool preference

Out of the 30 designers who responded, 100% preferred Figma to Sketch. Figma was also preferred for developer hand-off and file management.

6 out of 10 found the migration from Sketch to be easy or very easy.

This was a huge relief for us and made us confident we did the right thing in migrating the team.

While Figma came out as the clear winner in all categories, it still falls short in some areas:

• Without the git-like ability to branch off and merge files, as in Abstract, a lot of manual work is necessary to keep our master files up to date
• Some respondents felt the rigid file structure (teams > projects > files) in Figma makes it hard to accommodate different types of products and features
• Zeplin still has more features and don’t require export-settings to be enabled manually

Day to day work in Figma

When asked about how Figma has affected efficiency and collaboration in the day to day work, the results were again very positive.

However, when it comes to finding up-to-date designs and staying aligned across different products and platforms, we still have some work to do. The result of the survey was a mixed bag and it revealed some bigger challenges:

Challenges

Based on the result of the survey and additional feedback from members of the team, these were the three main challenges we identified:

Challenge 1 — Finding and sharing designs across multiple projects

Let’s say you’re designing features for a loyalty program. The feature appears on the Search page and is using components from your design system.

With Zeplin you could easily publish your design to 3 separate projects — stakeholders from your loyalty, Search page, and design systems teams would all get the visibility they need without having to browse multiple projects. We could separate projects into phases, statuses, or similar using dividers, and we could tag individual artboards to find the right thing right away.

This is much harder when there’s no separation between design and hand-off.

Challenge 2 — It’s hard to get a more visual overview of your projects

The masonry-style gallery presentation in Zeplin made it easy to get a good overview of the general design direction of a project and to find a specific UI just by scanning the board. The boards could be divided into sections, which helped further.

Apart from the file thumbnail, there’s no way to get this type of overview in Figma. Therefore, our designers have to spend more time browsing files to find the right thing, which is the opposite of what we were trying to achieve.

Since we started to explore Figma, their team has managed to pinpoint and solve many of the issues we were facing as designers. Limitations in the tools we use inside the files when designing.

However, these first two challenges relate more to what happens outside of the files, and we haven’t seen as many improvements in this area yet. For freelancers and smaller design teams, these might be non-issues, but for larger teams, this might be the difference between canceling Zeplin once and for all or keeping it on retainer.

We’re eager to see what the team at Figma has in store for us!

Challenge 3 — Our master files are hard to work with

In order to maintain our master files at scale, we decided to distribute the responsibility to different designers, based on the page/feature they are working on.

The challenge with this is that everyone works differently and has more or less time to make the files organized and easy to use. This harmed the efficiency of our team as our designers had to spend a lot of time cleaning up and tweaking the files before they could implement their own changes.

Out of the three challenges listed here, we felt this was most urgent and easy to tackle, plus it would help to solve many other issues down the line. So we set up a checklist of to-do items for each page owner:

Then we scheduled a kick-off meeting with all project owners to align on the expectations and deadlines. We assigned auditors and scheduled follow-ups and a final individual audit with each owner:

We are currently in the process of auditing the files and figuring out how to tackle the other challenges.

Final thoughts and learnings

Moving to Figma has been a long but exciting process that has given us an opportunity to not just switch tools, but to take a step back and evaluate the way we work, fundamentally.

As we continue to evaluate the tool and our processes, here are some final thoughts and recommendations:

Help out — but don’t forget the heads up!

Designers want to be in control of their work — Seeing someone editing your design might cause frustrations. I learned this the hard way as I was fixing some spacing issues and spelling mistakes for my coworker. If you want to help out, be sure to give a little heads-up or FYI so they know what you’re up to!

Yes, it will slow down the velocity of the team initially

There’s just no way around it — migrating to a new tool is a big undertaking. You’ll need to set time aside for this — time that you’d normally be working on day-to-day design work. New tools, shortcuts, plugins and more takes a bit of time to get used to — initially you probably won’t be as efficient as you used to in Sketch.

Communicate this to your stakeholders in a proactive manner and explain the long term benefits to get them on board with the change!

Don’t let perfection get in the way of progress

Don’t wait to use Figma until the UI libraries are 100% ready until you start doing day-to-day work in Figma.

We found it better to deliver our tickets in Figma even if it means importing sketch files, patching up the pages with screenshots, or similar.

There are three main reasons for this:

1. The longer you wait, the more you’ll have to re-design in Figma later on. It’s easier to go back and replace custom UI with library components later on, compared to rebuilding the whole design from scratch.
2. This will get you up to speed with the new tool faster and help identify areas of improvement in your new process
3. Your stakeholders will get on board with the change faster and you’ll be able to benefit from the collaborative features right away

Thanks to all designers who have contributed to this migration — Namju Lee, Andre Rodrigues, Fendy Ibrahim, Natchalee Touren, Lynn Chen, Haeji An, Shane Stuart, Chutimon Tangtanaporn, Liya Li, and Anita Lee!

References and inspiration

We wouldn’t have been able to pull off our migration without all the resources shared by other designers to the community. Here are some of the pieces that inspired us and helped us succeed:

Read

• Components styles and shared libraries
• Tips for a better developer workflow
• How Spotify organizes work in Figma to improve collaboration
• Uber design platform
• Design At Scale: One Year With Figma
• Our first 6 months with Figma
• Waiting for a sign to start building your design teams component library
• 5 ways to structure your workflow with pages in Figma
• How Shopify facilitates collaboration in Figma
• Taming Chaos: Our Design System Governance at Scale

Watch

• Reimagining Design Systems at Spotify
• In the File: Aligning Around a Design Systems Workspace
• Config Europe — A complete playlist of all talks

That’s a wrap!

This was the final part of how we migrated from Sketch to Figma at Agoda. I hope you found it insightful!

Missed the previous parts?

Part 1: Tools, costs, and learnings from other design teams

Part 2: Creating more collaborative and efficient processes

Rolling out Figma to the design team — tips, learnings, and challenges was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the coronavirus hit the travel industry earlier this year, the design team at Agoda looked at how we could save costs without sacrificing the quality of the work we’re doing. The collaborative features and the opportunity to shrink the cost of multiple license fees to just one were two compelling reasons to review Figma and eventually propose a plan to migrate our whole design organization to the new tool. Here I’ll walk through the research we did and how our working group planned and executed the migration to Figma.

Finding the right balance when defining processes

As designers, our hearts are pumping a little faster when we’re in the zone solving problems — user problems — not chasing people for access to the right files.

Being a part of a larger design and product team means that you’ll need to spend time syncing and aligning with people from adjacent teams, assure consistency between products and funnels, and more. I’m not going to lie — at times this can be very time-consuming. As designers, our hearts are pumping a little faster when we’re in the zone solving problems — user problems — not chasing people for access to the right files. When discussing workflows and processes, it’s easy to add more and more steps, assuming that everyone will dutifully follow the process. But the truth is, the more steps we add, the less likely anyone will follow the procedure.

How can we solve this challenge without adding more admin work for our designers?

Therefore, one key question I’ve asked myself and others on our team as we planned out our migration was — How can we solve this challenge without adding more admin work for our designers? It’s a tricky balance — we want our designers to have the freedom to work in whatever way suits them best. But we don’t want to go back to the mess of the past.

In this article, I’ll explain how we utilized Figma to improve the way we organize our designs (ourselves?) more efficiently and collaboratively.

Organizing teams and projects in Figma

Before the migration, all of our working files were managed in Abstract, which has a very similar structure as Figma:

1. Organization
2. Team (Figma)/Section (Abstract)
3. Project
4. File
5. Pages

It would have been easy for us to just recreate our previous file structure, import all files, and call it a day. However, our shared experience in the Figma working group was that the current setup in Abstract was inconsistent, confusing, and not very well maintained.

Before Abstract, we had all been sharing sketch files on local servers, over emails, and Slack, so at that point, anything seemed better. We were all excited to use Abstract and at the time it was hard to foresee what issues we would run into 3 years later, so we just took it and ran with it.

This time around we knew better — we wanted to carefully evaluate different options and gather as many insights as possible from the broader design team before moving ahead. First, we scheduled a workshop within the working team to brainstorm possible ways of dividing the teams in Figma:

• Figma teams by reporting lines
• Figma teams by platform
• Figma teams by audience
• Figma teams by product

Then we scheduled hour-long sessions with designers across all teams and products to better understand how they currently utilize our tools and any pain points they experience today. Some of the most common feedback we received was:

• It’s hard to know where to find the right design
• Which library should I use on my project?
• The files on Abstract are outdated and I have to chase designers for the latest designs
• It’s hard to stay up to date unless I join multiple sync meetings every week
• I work on my files offline as Abstract is too slow
• How can I get a good overview of our products?

Defining goals for a successful re-organization

Based on all feedback from the broader team, we wanted to consolidate it into a set of goals that we could use to better evaluate our options.

Make work more efficient

• It should be easy to find up-to-date versions of designs for all products.
• Duplicated work should be avoided as much as possible.
• Designers shouldn’t have to move between many teams and projects in Figma more than necessary.

Increase visibility and collaboration

• It should be easy to provide and reach out for feedback.
• It should be easy to stay aligned on design across different platforms, verticals, and horizontals.

A scalable and straightforward structure

• It should be easy for all designers and stakeholders to find the right thing without hesitation.
• It should work well as new priorities or products are introduced and changes in the organization happen.

Evaluating the options and moving ahead

Figma teams by reporting lines

Idea: Mimic how our design organization is split into different reporting lines.

Pro’s: Easy for peers within the team to stay aligned as they are always exposed to each other's work. Easy for the managers to keep track of design progress. Easy to organize design critiques and syncs within the team.

Con’s: Hard, if not impossible, for any stakeholder to know where to find things without having to pull up the organization chart every time. This solution would be prone to changes with new hires, reorgs, and people resigning. Over time it might create isolation between teams and increases the risk of duplicated work.

Conclusion: No go. This solution would provide the least benefits.

Figma teams by platform

Idea: Divide the teams into App, Web, and mobile web.

Pro’s: Increases visibility and alignment between products and features within each platform. In turn, this might create more cohesive products within each platform.

Con’s: This would limit us to only 3–4 teams in total, which would make each team very crowded with designers, features, and products. Not all our products are sharing the same design languages — for example, consumer and enterprise products have very different audiences and very few commonalities.

Conclusion: No go as it’s not scalable enough.

Figma teams by audience

Idea: Divide all design into two teams: consumer and enterprise

Pro’s: Better alignment between designers working on different products facing the same audience.

Con’s: Similar issues as the platform solution. Only 2 teams would make Figma too crowded and not scale well.

Conclusion: No go

Figma teams by product

Idea: Align the teams in Figma with our product portfolio.

Pro’s: Easy for everyone to understand and navigate. Features within each product can be organized as projects. High visibility between designers working on the same product and same or adjacent features. Less risk for duplicated work. Easy to add or archive teams as the product portfolio expands.

Con’s: Less visibility between different products and audiences. It might cause duplicated work as many solutions are shared across different products.

Conclusion: Move ahead

Structuring our files

As a team of 40+ designers and hundreds of stakeholders working with us, we needed to come up with a common file structure across all products and features. These are the different types of files we set up, and what each page in these files contain.

Master file (Source of truth)

The goal of the master file is to replicate our live website as close as possible, including different states and edge cases.

With thousands of experiments constantly running, this is not always easy to do. As a rule of thumb, any experiment that is taken and 100% rolled out to our customers is considered as the source of truth.

Our master files generally contain the following pages:

Cover

This page just contains one frame with our black Master cover. We have predefined cover templates from our Design Systems team to ensure that all files are easily identifiable across the different teams and products.

The cover includes the platform, product, and responsible designer.

Master

This page contains all key screens. This is a great starting point for designers when they need to modify an existing feature or incorporate screens into user flows.

Edge cases

This page contains additional states and edge cases, such as:

• Filled vs empty forms
• Empty states
• Error states
• Designs for Right-to-left reading languages
• Designs for specific countries or regions
• Designs for different loyalty tiers
• Designs for logged-in vs non-logged-in users

Flows

This page contains a collection of common user flows and interactions. It gives us a better idea of how the different parts of the experience connect.

A powerful way of handling flows is to convert the frames in the Master page into symbols and build out the flows using instances of the symbols. That way, any changes on the master symbol will automatically carry over to the flows, reducing extra work.

Master update queue

To avoid breaking changes in our master screens, we have appointed one designer to own each master file and keep it up to date.

Contributors can add their design work to this queue once their designs are live on our products. The owner is then responsible to incorporate these changes into the master screens.

Ideally, this page should be empty as often as possible, assuring that the master screens are always up to date.

Ticket files

To keep our working files performant and easy to navigate, we create a new Figma file for each design ticket we’re working on.

We created a template for this so our designers can get up to speed as quickly as possible. The template includes a recommended page structure and checklists for design alignment, hand-off, and more.

Start

This page includes a cover, a project summary, and a checklist. The cover includes the following information:

• Design Ticket ID (and link to the design ticket on JIRA)
• Dev Ticket ID (and a link to the dev ticket on JIRA)
• Ticket name
• Designer
• Product Manager

The cover page can be swapped between different states:

• Work in progress
• Design shipped
• Taken
• Not taken

This helps other designers, the page owner, and stakeholders to keep track of all design tickets. Each state is color-coded for easy recognition.

Explore

On this page, our designers can explore design options in whichever way they want. While we want to provide some guidance and speed up work by providing a template file, we don’t want to hamper the creativity of our designers.

Hand-Off

This is the page we deliver to our stakeholders — usually Product Managers and developers.

After exploring options and vetting designs in internal design critique sessions, we typically provide our final recommendation here, along with User flows, edge cases, redlines, and such.

To help designers ensure consistency between products and features, we’ve provided a checklist on this page:

• Add Jira-ticket links to the cover page
• Tag internal stakeholders in the design team (for alignment and QA)
• Tag design systems team (for design QA)
• Tag developers and QA
• Double-check typography, colors, spacing, shadows, etc.

Follow-up

This page provides guidelines for what to do with the Figma file after it has been developed.

If we’re running the design in an A-B test we encourage our designers to add a link to the experiment. If the experiment was a success we implement it to our master file, if not, we archive the file.

Northstar explorations

Major re-designs and explorations live in a separate project in our teams. When these designs are ready to be implemented, we break them down into smaller design tickets. Each ticket/file is then moved from the Northstar project into the appropriate feature project.

Archiving files

To keep our projects at a manageable size, we have a separate Archive project for each Team.

Whenever a design ticket has been implemented live or discarded, we update the cover image accordingly and move the file into the Archive.

As the archive builds up, it’s interesting to see the success rate of our design experiments:

How it all comes together

This is how one of our Figma projects look like after a month trial with this new process:

The new structure allows for easy access to the master file and ticket template, as both are pinned at the top of each project.

The tickets are color-coded according to the design status. The name of the tickets includes the ticket ID, platform, and ticket name, making it easy for all stakeholders to search and find the right design.

For each project, we’ve enabled the necessary libraries from our Design Systems — such as UI elements, Icon kits, and more.

By maintaining a source of truth and separating it from ticket files, all designers know where to find the latest designs. The ticket files are lightweight as only the necessary design components are added from the master file.

Design systems

We have a dedicated team of designers who maintain our design systems. They develop UI kits, best practices, type and color styles, and a lot more.

Coming from Sketch, we already had quite robust UI kits and we realized quickly that it wouldn’t be possible to onboard the team successfully unless these kits were ready to use in Figma from day one.

However, the existing setup with Abstract caused confusion for our designers, as the libraries were scattered across many different projects.

To bring clarity to the team and to speed up work, we decided to centralize all UI kits and design languages into a single Figma team.

Within this team we organized our UI kits into different projects:

Fundamentals

• Core styles (typography, colors, borders, shadows, spacers, etc)
• Icon kits
• Brand assets
• Utilities (Native OS components, spacing redlines, annotations, cursors, etc)

Platform-based UI kits

We decided to divide our UI kits into two projects — Web and App.

Each project has multiple UI kits to support all areas of the business, for example:

• Core components (components shared among all products on the platform)
• Enterprise-specific components
• Flights-specific components

Mixing and matching libraries to fit our needs

As Figma allows us to link multiple libraries to our files, we can pick and choose all the libraries we need to design for each product.

Requests

By having a centralized team responsible for our design system, we prevent other designers to potentially mess up our stable libraries that the whole team is dependent on. However, this might cause these designers to feel disconnected and discouraged to contribute to new ideas.

To mitigate this, we created a dedicated project for requests— a space where everyone can contribute to improving our systems. We found Henry Daggett's article on Design system governance at scale particularly helpful when setting this up.

Using our request template, any designer on the team can add their request and ping our design systems team for a review. Requests are divided into the following 3 categories:

• New component/pattern
• Bug
• Suggestion, improvement, feedback

So far proposals from our team have included new UI elements, missing component states, illustrations, and general utilities such as native iOS keyboards.

Continue reading

This was part 2 of a 3 part series on how we migrated from Sketch to Figma at Agoda. I hope you found it insightful!

Read next, part 3: Rolling out Figma to the design team — tips, learnings, and challenges

Did you miss out on Part 1? Read it here.

Creating a more collaborative and efficient process when migrating to Figma was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the coronavirus hit the travel industry earlier this year, the design team at Agoda looked at how we could save costs without sacrificing the quality of the work we’re doing. The collaborative features and the opportunity to shrink the cost of multiple license fees to just one were two compelling reasons to review Figma and eventually propose a plan to migrate our whole design organization to the new tool. Here I’ll walk through the research we did and how our working group planned and executed the migration to Figma.

The compelling promise of Figma

The rise of Figma in the design community over the recent years has been exciting to follow. Many designers in our design team had already started to explore the tool in their spare time and were positively surprised by its capabilities.

Meanwhile, as our design team had grown rapidly, a number of issues impeded our ability to work efficiently and stay aligned across the team.

Figma offered solutions to most of them:

• Real-time collaboration
  Working on the same project and providing feedback is very cumbersome with Sketch. Being able to do this seamlessly would be a big win for our team.
• Focus and efficiency
  Being able to design, prototype, gather feedback, and handoff specs within the same tool would reduce context switching, mistakes (ops, forgot to upload to Zeplin!), and save loads of time.
• Performance
  Sketch in combination with Abstract was starting to seriously slow us down in our everyday work as files took minutes to load, commit and merge. For many of us, Sketch was lagging and crashing on a daily basis.

Analyzing the cost of our design tools

To get a better sense of how a move to Figma would affect our toolset and costs, we documented all the design tools we used, analyzed the annual cost and whether or not they could be replaced by Figma:

Sketch

• 99 USD per year and license
• Used for UI design
• Is replaceable by Figma
• Verdict: Cancel

Abstract

• 180 USD per year and license
• Used for version control and file management
• The file management aspect is replaceable by Figma, the version control is not. We need to investigate if an alternative workflow would be feasible.
• Verdict: Cancel

Zeplin

• 130 USD per year and license
• Used for developer hand-off
• The hand-off is replaceable by Figma
• It’s worth noting that Zeplin also charges for view-only users such as developers and PMs. This easily makes the license fees skyrocket when working with bigger tech teams.
• Verdict: Cancel

InVision

• ≈100 USD per Year and license
• Used for developer hand-off and prototyping
• Both hand-off and prototyping is replaceable by Figma
• Again, the cost can easily skyrocket as view-only users are charged as well.
• Verdict: Cancel

Principle

• 129 USD per year and license
• Used to animate micro-interactions
• This is not replaceable by Figma
• It’s worth noting that a license can be shared across multiple devices and therefore be shared by multiple colleagues, thus driving down the cost.
• Verdict: Keep

Framer

• 240 USD per year and license
• Used for advanced interactions and prototypes
• This is not replaceable by Figma
• Verdict: Cancel
• Only a few people on our team have the skill set to code prototypes. The main use case for these prototypes were user labs, however, the pandemic has prevented us from doing this at the same scale as before thus we decided that Framer is no longer an essential tool

Whimsical

• 144 USD per year and license
• Used for user flows, wireframes, and other early-stage UX work
• This is not replaceable by Figma
• Verdict: Cancel

Miro

• 192 USD per year and license
• Used for user flows, wireframes, and other early-stage UX work
• This is not replaceable by Figma
• Verdict: Keep
• Miro and Whimsical are two very similar tools, and since most of our team is already using Miro, we recommend to keep it and cancel Whimsical

Figma

• 540 USD per year and license
• Used for UI Design, developer hand-off, and prototyping

Conclusion

As we compare the current and proposed toolsets, the total saving is roughly 350 USD per year and license:

• Current: 1214 USD per year and license
• Proposal (Figma, Principle, and Miro): 861 USD per year and license

The cost savings per designer is good, but the biggest savings are made on the Zeplin licenses where we no longer need to pay for developers and other stakeholders, requiring view-only access. It’s not uncommon for the designer-developer ratio to be 1:10 or larger, so considering this in a large organization, the cost savings are tremendous.

Learn from other design teams

With the cost review done, we got the green light to move ahead and continue investigating how the migration could be done.

Luckily we were not the first design team to migrate to Figma. As we started to research how other teams had managed the migration, we were pleasantly surprised to see how much other companies had shared on their transition. We dived into tutorials, blog posts, podcasts, and youtube videos.

Liferay provides a generous repository of Figma resources and insightful articles on their design website. In the example above, they use color-coded thumbnails for each file to display useful information such as project status, stakeholders, and author.

Spotify’s approach to design systems — a family of systems, layered like a cake. The core layer spans across all products and features, such as branding elements, logos, colors, and typography.

The next layer is platform-specific and provides components specific for web, app, and other platforms.

The final layer provides unique systems for each product or segment and allows designers more autonomy in crafting their own components and socialize them throughout their product. They complete the system, like sprinkles on the glazing of a birthday cake.

Credit Karma has one Design Systems Team in Figma with separate projects for assets, components, layouts, OS devices, and more.

Each component is divided into an individual Figma file, where everything about that component is documented in detail — all research, iterations, symbols, states, and dos and don’ts can be found here.

This approach allows for easier versioning, less risk of braking components, and more documentation per component without making it overwhelming. But it also means that designers have to link a large number of libraries to every project (one per component).

Shopify has embedded a checklist in their working files on Figma to help designers cover all the bases as they are designing on different features.

To speed up work and to keep designers aligned, some larger design organizations take it a step further and build their own plugins and extensions.

Uber built these nifty Mac OS extensions which include icons, assets, spacings, branding guidelines, and more. Updates can be sent via push notifications to the whole team.

At Agoda, we built a Sketch plugin to populate our designs with hotel names, facilities, airport codes, room photos, and more. As a part of the migration, we’re currently rebuilding this plugin for Figma.

This might not be worth the efforts in smaller teams, but in teams of 50+ designers, this can prove to be a real time-saver in the long run.

For each product, Spotify has a dedicated project where they host all their specs — the source of truth for that product. This makes for a clear separation between the live product and works in progress.

Getting a glimpse of how other design teams work with Figma provided us a wealth of ideas to explore. To be able to explore these ideas and do so in an organized manner, we decided to establish a formal working group.

Establish a working group with clear responsibilities

What started as a small team of designers from one of our product teams quickly expanded to a working group with designers from different product teams across our organization — Consumer and supply product designers working on both web and app were represented in the working group. So were designers from our design systems teams.

With designers from a wide range of products involved, we could challenge each problem from many different angles and split the responsibilities better. For some of us, this was the first time we had an opportunity to work together with other designers across different teams — exciting times!

We divided the work into the following workstreams and assigned an owner for each:

Organization and setup

• Team, Project and file structure
• Design System and UI libraries

Workflows

• General workflows
• Master file management (our source of truth)

Communication and governance

• Communication channels and contact persons
• Maintenance plans

We could now diverge and dive deeper into each focus area. To keep aligned and share learnings we created a private slack channel. To stay focused and move fast we had weekly syncs with clear action items and follow-ups.

References and inspiration

We wouldn’t have been able to pull off our migration without all the resources shared by other designers to the community. Here are some of the pieces that inspired us and helped us succeed:

Read

• Components styles and shared libraries
• Tips for a better developer workflow
• How Spotify organizes work in Figma to improve collaboration
• Uber design platform
• Design At Scale: One Year With Figma
• Our first 6 months with Figma
• Waiting for a sign to start building your design teams component library
• 5 ways to structure your workflow with pages in Figma
• How Shopify facilitates collaboration in Figma

Watch

• Reimagining Design Systems at Spotify
• In the File: Aligning Around a Design Systems Workspace
• Config Europe — A complete playlist of all talks

Read next, part 2: Creating a more collaborative and efficient process when migrating to Figma

How we migrated our design team to Figma was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

YCS is an enterprise tool where hotels can manage rates and allotment, bookings, promotions and much more. The YCS app was launched early 2018 with a limited set of features. During 2019 we set out to expand on the app and build out some of the wanted features.

Our goal with this project was to provide an overview of hotel performance and operations, thus enabling hotels to make better decisions and accelerate their business with Agoda.

Background

To get a better understanding on where to focus our efforts, we conducted both qualitative and quantitative research. We sent out surveys to hotels and asked them to rank their most important features. We also travelled to some of our key markets to conduct interviews with hoteliers to get a better understanding of their wants and needs.

When we talked to our users, it became clear that we weren’t providing sufficient insights on how they perform. The most common way for hotels to get insights was in monthly meetings with a Market Manager from Agoda, who would bring a printed monthly report and discuss areas of improvements face-to-face.

While this report was appreciated, it didn’t provide all the data our hotels wanted, and didn’t allow them to customize it the way they needed. By providing a more flexible way to generate these insights, we believe that hotels would be able to make better decisions. And we would also reduce the labour-intensive process of printing reports and visiting hotels.

My role in the team

I lead the design of the overall app experience and worked as the UX/UI Designer throughout this project. I worked together with a UX Researcher, Copywriter, Prototyper, Product Owner and a team of Developers and QA Engineers.

Initial research

In order to understand what data our hotels needed and which tasks they normally performed, we had to immerse ourselves into the daily tasks of the hotels and their staff, as well as our Market Managers who provide data to the hotels. We shadowed our staff and took note of the most common tasks they performed during a day, and scheduled hotel visits to understand how they interacted with our systems and what data was most valuable for them.

Not all hotels operate in the same way, and it was important for us to cover as many types of markets, hotels and users as possible on our visits. We targeted specific hotels in our biggest markets from the data of active users on both app and desktop. With the help of local Partner Services teams, we could schedule visits with a diverse set of hotels, from small family-run boutique hotels in Taichung, Taiwan to larger chain hotels in Cebu, Philippines.

During our hotel visits, we interviewed the staff to understand how and when they used our system. We asked them to rank different features and data by importance, using card sorting.

We consolidated the learnings and mapped out the most wanted features across the different types of hotels, markets and roles within hotels. By mapping out feature needs by role, it became clear that different roles have different needs:

• For decision makers, it was important to get insights on hotel performance, in order for them to make strategic decisions.
• For operational staff, they would like to get a good overview of what’s going on at the hotel.

Diving into the data

We decided to focus on the decision makers because they have a bigger say at the hotel. We weren’t catering to their needs at all at the time, whilst operational staff already had the tools they needed on our website. Providing performance data was going to be a bigger challenge for us, and therefore something we wanted to tackle right away.

I started off by creating a mind map of all scores, metrics, events and other interesting pieces of information that might help hotels make better decisions. It included data that we already had, data that was requested by our hotels, data that our competitors provided and some new ideas.

While the different types of data might provide some useful information on their own, we believed that we could generate much more meaningful insights by combining them. So, I had to come up with some formula to generate these insights. Inspired by how Google Analytics lets you generate reports, I grouped the data into different categories:

• Metrics (such as bookings, room nights, revenue)
• Dimensions (such as nationality, promotion type, traveller type)
• Time frame (e.g. today, this week, last month)

By comparing the data using other dimensions or time frames, we could generate new insights.

For example, if a hotelier analyses her bookings for the last 30 days for each nationality, compared to her competitors, she might find that her property attracts a significantly lower number of guests from the Japanese market.

At this stage, our new tool can provide suggestions by looking at her hotel, their competitors and trends for Japanese travellers. For example, there might be certain amenities that are important for Japanese travellers, which her hotel doesn’t provide.

With the insight, she can take action immediately.

Early explorations

With all the potential data points defined and a formula to generate insights, I started to work on some initial concepts. At the time, the landing page of our app was a very basic feed of generic suggestions. The engagement was low and our users were reluctant to take the suggestions, so we decided to replace this feed altogether with our new solution.

We wanted to cater to both our key user groups from the get-go — the decision makers and the operational staff. Therefore, I had to come up with a homepage that displayed both performance related data and activities at the hotel.

The first concept we wanted to try out was a dashboard with two tabs:

• Performance: Hotel scores, performance metrics, competitors and more.
• Operations: Information on new bookings, cancellations, guest messages, reviews and more.

Our assumption was that this would be the clearest way to group the content since there was such a clear distinction between our users. Based on the wireframes, I mocked up high fidelity designs and created a simple prototype with InVision.

Bringing in the users

We invited Bangkok-based hotels to our office to test the prototype. It quickly turned out that the tabbed approach didn’t work. Almost none of the test participants noticed the tabs, and the labels of the tabs (especially “Operation”) were not clear enough.

We renamed the tab “My feed” and designed an alternate layout that combined the performance and operations into one page. We invited more hotels and let them play around with both solutions.

The renamed tab didn’t help the users discover the tabbed navigation. However, when we provided all the content within the same page, we noticed that hoteliers instantly started to scroll the feed to find out more. In this design, we provided filters based on the type of content: Performance, Bookings, Messages etc. Almost all participants tried to interact with these filters.

With these insights, we decided to move forward with the one-page solution.

Accidental insights and improvements

One of the main features on the dashboard was a set of scores that would help hotels understand how well they are performing:

• Offer strength: do they provide competitive rates, and do they have rooms available on Agoda.com?
• Content: Is the content up to date, do they provide high quality photos?
• Reviews: What’s their review score, in what areas can they improve?

We set out to see if the hotels would understand these scores, and if they could find ways to improve the scores by using the new dashboard.

During the first round of usability tests we were using the InVision app on one of our test devices. This app offers a specific mode for usability testing, however I forgot to instruct my researcher on how to turn this on prior to the labs — my bad!

The usability testing mode only enables the users to navigate via the hotspots I have added to the prototype — in contrary to the default mode, where users can swipe between screens, and therefore abandon the intended navigation. Both test subjects in our morning session discovered this trick as they were trying to swipe on the line chart in the left screen below:

They expected to be able to go back and forth on the time-frame in the line chart, but instead they ended up at a different screen, the Content score (middle). Both test subjects had a similar reaction: “Oh! I don’t have to click back and then click again to see the next score — nice!”.

This accident provided two valuable insights to our team:

• Users understand that they can scrub on the graphs in order to reveal more data on the timeline
• Users want to use swipe as the main navigation between related scores

With these exciting insights I set out to adjust the navigation of the scores:

While the users found the swipe navigation easy to use, that was not what they intended to do. So I added dots underneath the scores in order to increase the affordance of swiping, and to indicate how many other scores we provide. I also added a hint of the next score in the corners of the screen to make it more obvious.

This type of navigation is not really possible to prototype in InVision, and therefore I pulled in one of our Prototypers to the project. With Framer, we were able to build more advanced and interactive prototypes, supporting all the new interactions we wanted to test:

Building a prototype in Framer, or any tool that requires coding, is fairly time consuming. What would take me a couple of hours with InVision took us a week or more to develop with Framer.

With this in mind, we decided to limit the prototype to some key features:

• Scores
• The most important metrics
  (Revenue, Average Daily Rate, Room nights)
• The activity feed for operations

Bringing the pieces together

As the development of the prototype was quite time consuming, I had time to build out the remaining designs and document all the new components.

In my initial designs I had set up guidelines on how to use colors in our data visualization. I wanted to distinguish many different things with color:

• Good, Average and Bad performance
• Current performance of your hotel versus past performance
• Your hotel versus competitors
• One metric versus another metric

As I added more data to the designs, I started to run out of colors to use from our palette. On top of this, we noticed that a couple of test participants confused our pink and turquoise with red and green. As a result, they thought they were performing badly on metrics where we used pink, and good where we used turquoise, even if that wasn’t the case.

Our team is usually very hesitant to introduce new colors or UI elements in our designs, but we decided that this was a good enough reason to introduce more colors to the palette.

Going forward

After visiting four markets to do our initial research (Thailand, Taiwan, Japan and Philippines) and three markets to validate our designs (Thailand, Malaysia and Singapore), we felt confident enough to move onto the next stage of the project. Now we had to decide on a plan to build and roll out the new features!

The performance metrics and scores were for the most part new. We had to pull in data analysts and our back-end team to figure out how to calculate scores and generate the data for the hotels.

The operations-focused activity feed contained a lot of information that we already displayed on our website, and would therefore be a lot faster to ship. So we decided to roll out these first, whilst also building the back-end logic for the performance metrics and scores.

At the time of writing this, we’re just about to start development of the MVP version.

Learnings

Keeping it real

Moving between different levels of fidelity when designing is key. Low fidelity wireframes work great for quick iterations of different concepts and idea generation. However, when performing usability labs, it proves useful to use a prototype that is as realistic as possible.

• Hi-fidelity mockups remove distraction and questions on how the real product would look like and work. Non-designers might have a hard time to imagine how to interact with a product by looking at a set of wireframes.
• Allowing real gestures reduces the risk of errors and makes it easier to understand what the user intends to do with the prototype. For example, if you’re designing a UI that affords swiping, make the element swipeable in the prototype.
• Use real data whenever possible. We didn’t have enough time to customize the content of our prototype to each hotel, and this caused them to focus on things that we didn’t care about from a design perspective. Despite using the right currency and hotel names, we noticed that some hotels were distracted by by certain metrics (“This seems wrong, are these really my rates? Is this really my revenue over the last month or is it quarterly?”). We believe that some aspects of our prototype might have performed better if all the numbers were real, as they would be able to connect the dots quicker and provide feedback on the utility of the designs rather than the accuracy of the numbers.

Optimize for the right audience

After talking to 15–20 hotels, we noticed that some hoteliers are used to crunching numbers and analyzing their performance regularly and use it as a basis for their business decisions. Others tend to play by ear. In general, the first group would understand how to read the graphs, analyze the numbers and make sense of the prototype. The second group sometimes struggled with abbreviations, legends for graphs and more. We knew we wouldn’t be able to cater to both groups, at least not in the near future, and therefore we had to make a decision — do we cater to the savvier users, or do we simplify it so that everybody can understand it?

When we interviewed the users, we asked them about our competitors and how they use their tools. The less savvy users did not use any of their performance tools today — therefore it’s unlikely that they would use our tool in the future. Based on that we decided to cater to the savvier users.

Designing a performance and insights feed for hotels was originally published in Agoda Engineering & Design on Medium, where people are continuing the conversation by highlighting and responding to this story.