Creating a more collaborative and efficient process when migrating to Figma
How we migrated our design team to Figma — Part 2
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:
- Organization
- Team (Figma)/Section (Abstract)
- Project
- File
- 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.
