How to move your team to Figma (or any new design tool)

A step-by-step guide for switching design tools

You’re switching design tools. Congratulations! It’s going to be so amazing once you move. With the new tool, you and your team will have smoother workflows, better collaboration, and lots of time saved. But the road to get there is unknown, and there’s a lot of room for error. Cross-functional workflows will get disrupted, your team is wary, and the department’s fate is in your hands.

Don’t know where to start? Never fear, this guide is here!

In this guide, I outline the steps to take your team from your current design tool to your new tool, where everyone is working proficiently and you’re unsubscribed from your old tool. There are many steps along several different project phases. There are also decisions to be made during each phase, and many stakeholders to wrap into the process — design, engineering, visual, content, product, program management, and leadership. You’ll want to know when to involve them each and how. In a nutshell, I’m giving you a step-by-step outline to move your team from one design tool to another.

I also touch on some important notes about people management. This process is inherently messy, so the more you know, the better prepared you’ll be to roll with the punches when they come up — because they will come up.

With Adobe’s acquisition of Figma, you may be rethinking if that’s the right tool for you. This process will work no matter what tool you’re onboarding, so read on!

Who am I?

I’m a senior UX designer at a multi-billion dollar corporation where we recently switched from using Sketch and Abstract to Figma while updating our design system. Typically someone from DesignOps would lead the charge on a big initiative like this, but I had previous experience with Figma and love creating organized processes, so I jumped in to help out. I ended up leading the charge along with a few others, working cross-functionally with many teams throughout the process. It was fun and a lot of work, and it went about as well as it could have. I want to share my learnings so others can easily put together a plan for their team when they switch tools.

Ultimately, this work should be done on a company-by-company, team-by-team basis, depending on the size of your organization and your processes. I hope this guide gives you some useful frameworks to help your transition go smoothly and efficiently.

Things you must know

There are a few very important things to note before getting into the to-do list, and they all have to do with people. The to-do list is easy. Managing people, on the other hand, isn’t so straightforward. This part is a must-read before you dive into planning.

Bless the mess

First, if you are the project leader, to keep your sanity, remember that this process is going to be messy. No question! And that’s okay. Any change this big involving so many people is going to have its missteps. You will lay out guidelines for the move, and many people will not follow them, and that is to be expected. Some people are hyper-organized, while some people just don’t pay much attention to detail. We’re all built a little differently, and that’s what you want in a diverse team. Make space mentally for mistakes from the beginning to save yourself stress.

Find balance

While you should make space for mistakes, also set expectations and hold people to a certain standard. There’s a fine line between the two, and knowing how to walk it will make this process so much easier. My advice would be to let go of perfection, but know when rules need to be followed, and enforce them as needed. As people make mistakes and fail to meet your standards, address what is being done and nudge them to follow the protocol.

Until then, my recommendation is to joyfully lead this effort, because it’s going to take a strong advocate to bring the whole team along!

Bring all stakeholders along

Note that this move won’t just affect your design organization. It will impact engineering builds, project timelines, and how much output your leadership can expect from several cross-functional teams during the time of the move. Bring all stakeholders along, including leadership, so they know what to expect. You will want to work with them to extend deadlines and get additional resources where needed.

For deadlines, my advice would be to extend them more than you feel is needed. Under promise and over deliver — as the saying goes. The bigger the organization, the more time you’ll need.

Be a fearless leader

Finally, people hate change. Just look at what happens every time Facebook launches an update! But eventually, people come around. As a project leader, despite what happens, it will be in your interest to lead the project with strength and joy. It may sound a little “woo-woo,” but people are naturally much more likely to follow someone who strongly advocates for what they’re doing. Smiling even when you don’t feel like it will often make things easier.

Deciding your timeline

How much time should you leave for your move? Depending on how big your team is, how well-established you are with your current design tool(s), how much knowledge your team has of the new tool, and how much bureaucracy your company has, I recommend leaving between 8–24 months from start to finish. Here I’m defining start as the moment your internal action team kicks off the pre-move process (below), and finish as the moment when everyone is working in the new tool and you’ve unsubscribed from all of your current tools.

There are 6 timeline phases when switching design tools.

Obviously, moving a small team will be much quicker than moving a large team. If you’re a budding startup with a small team of 5–10 designers, your planning conversations can go quickly, and you can be more flexible with your timeline because you have direct oversight into how each of your team members is impacted. If you’re a big corporation with multiple teams participating in the move, the whole process will take much longer. You’ll have to account for numerous meetings with all stakeholders and more leeway as all designers get up-to-speed once they’re in the new tool.

Leave more time than you think you’ll need

Since your team will be doing this on top of their normal workloads, leave more time than you think you’ll need. It’s hard to estimate how long some of these tasks will take, especially since many of your team members may be learning the new tool for the first time in addition to moving files from your old tool and getting work done.

If you don’t give your team enough time, it’s inevitable that they will feel the pressure to deliver under a tight schedule. They may feel the need to work long hours, and if that’s the case, you may risk team members getting burnt out and even leaving the company.

Planning a longer timeline will make room for the unexpected. People will take vacation, parental leave, and medical leave. You may even lose key project stakeholders, leaving you to assign a new project lead. This person would need to rebuild relationships both internally and externally, which will only push your timeline back.

As you plan your timeline, be mindful of major deadlines so the team isn’t caught in a sticky situation. Move at the wrong time, and designers may be learning how to use a new tool when they’re supposed to be delivering work. Not ideal. I recommend working with your program management team to balance the workload, properly time deadlines, and manage expectations across the various stakeholders. The move is just another factor in your normal timeline-creation process.

With big initiatives like this, things tend to come up. Remember that work is part of life, and not the other way around. You may feel pressure to tighten timelines for leadership or other reasons. Budget more time than you think you’ll need in order to leave room for what is human.

Early decisions (12–18 months out)

You’ve decided which tool to move your team to. Now it’s time to make early decisions for a successful transition in the coming months. This involves tackling tasks that will take the longest, like building your design system in the new tool, which will heavily impact your success later on.

Assign action team: Assign one project owner, with 1–2 additional people in lock-step with them as project leads. You’ll want multiple people to be in on all of the details so, if one takes a vacation or goes on leave, you won’t have to put the whole project on hold. You’ll want:

• 1 owner: The person who makes all of the major project decisions and who drives the timeline.
• 1–2 leads: These people will have all of the same information as the lead and who will help make key decisions as needed, but who will defer to the lead for most decisions.
• 1 design system leads: This person will oversee building the design system in your new design tool.

Build design system (DS): This will take the most time out of anything you’ll do, especially if the person/team building your DS in the new tool also has to learn how to use it. Your components will likely have to be built in a completely new way, which can take some time up-front. Start this as soon as you can and gauge the rest of your timeline based on how it progresses.

Note: You’ll want the design system to be at least 95% complete (ideally, 100%) before you move your team in so they have all the assets they need. It will be hard to fully QA them before everyone moves in and starts using them, so be prepared for bugs. The real test will be when your team members start using the components. I’ve outlined a process for reporting bug fixes in section: During (1–2 month duration).

Begin to socialize the migration: Socialize the move with both leadership and individual contributors. Share the benefits of the new tool with each of the stakeholders, highlighting the points that are most pertinent to them. Letting them know early on will build trust and prepare them for what is to come.

Begin to determine timeline: Once your design system is built about half-way, you should be able to determine how much longer that effort will take. Plan a tentative move date based on how much time it will take to build the rest of the design system and do the steps outlined in this guide. You can begin socializing this date when you have it.

Create sub-action groups: Because this move will most heavily impact individual contributors on the design team, you’ll want to partner with designers so you know what they need for success. Form sub-action groups that will be responsible for creating tool organizing principles, managing the move timeline, and more. A few ideas include:

• Project, folder and file structure team: This team will come up with your project, folder, and file structure.
• Documentation team: This team will create documentation for onboarding, standard ways-of-working, and how-tos specifically for your team.
• Project management team: Work with your project or program managers to nail down dates for meetings, onboarding, and tutorials throughout the whole transition process.

Set the foundation (6–8 months out)

Once you have your action teams together, your design system well under way, and an initial timeline planned, it’s time to start the real work. In the previous phase, you started making early decisions for a successful move, now it’s time to set the foundation.

Socialize timeline and determine best practices: Once you have an idea of the timeline, you’ll want to socialize it across all teams so people feel like they were included in the process. You’ll also want their input on some major decisions when the time comes, like file template and naming conventions, standard ways of working, and when your current tools will expire. Let your team know that your action groups will share their work in the coming months.

Don’t forget to bring along non-design stakeholders, including engineering, product, content, and more, so they’re aware of what’s going on and will be prepared to shift how they collaborate with the design team in the future.

Create file structure: (NOTE: This goes hand-in-hand with team and folder structure, listed below, so consider them together.) You’ll want to create a file template so everyone on your team is working from the same file structure. This will make it easy for teammates to collaborate on a project, even if they’re new to a file.

There are a lot of nuanced decisions to make here. Do you want to have one file per feature? One file per flow? Will you have different pages for WIP vs. delivery documentation vs. archived work? Again, determine your file structure in tandem with folder structure.

Figma has a limited team, folder, and file architecture.

Create team and folder structure: Decide what team and folder structure is best for your organization. Some common ways to organize folders within a team space are by process and by project. This should be decided in tandem with file structure.

TIP: I recommend mocking up your folder and file structure in the new design tool to move from theoretical to tangible. It’s easy to have hours of conversation about what these structures should look like, but mocking them makes them real and will help you decide what’s actually best. Bring in existing files that have been formatted using your new file structure. Share this with key stakeholders to get feedback.

Create file naming conventions: Based on the folder and file structure you’ve chosen, create file naming conventions to keep your folders organized. If teammates are left to name their files whatever they want, your space is going to get messy very quickly.

Create file template: Based on your folder and naming conventions, create a file template for people to work from. Put it somewhere teammates will easily find it.

Pre-move (2–4 months out)

This is when all of the preparation for the move comes to a peak. The design system should be nearly complete, the folder and file structure decided, and team members ready to make final decisions about the move timeline.

Solidify timeline: To determine your official move dates, look at everything that needs to happen in this guide between now and the very end. Base your dates on that. From creating documentation to hosting onboarding and tutorials, map these dates on a visual timeline to share with your team.

Determine when current tools expire: You’ll want to extend your current tool(s) beyond your move-in date by a few months to give your team some time to settle in. If engineering is building any designs that exist in your old platforms, this will give them some time to complete the builds while you move your files over.

If your organization doesn’t have the budget to keep current tools past the transition kickoff, you’ll have to set aside a minimum of 3–5 business days and organize everyone around the move. Put all files from your old tool into a holding place determined by your organization so no work is lost. You should also help team members learn the new tool starting a few months before your official move date.

Create documents and resources: Put together some key resources for your team to reference later as they move into your new tool. These could include standard ways of working, tips, and other helpful resources. Some ideas are:

• How to convert a file from your old design tool to your new tool
• List of helpful plugins
• List of must-watch tutorials
• File and folder structure
• Naming conventions
• File template and how to use it

Be judicious in what documents you put together. This takes a lot of time, and much of this information can be found online anyway, but we found that putting a handful of helpful documents together that were specific to our team saved our team time and made people feel like they were taken care of.

The move (1–2 weeks)

Here’s where all the hard work you’ve done comes together. The design system is ready, your documentation is complete, all the teams have been informed during the process, and now you get to move them in.

Admins: Dedicate 1 or more people who will have the power to add members to your new tool. People from design, product, engineering, content, and more will need access to the tool. Depending on how your account-creation and sign-on works, assign the right number of admins to help each team member get access.

Onboarding meetings: Schedule onboarding meetings with your teams. During these meetings you’ll want to share how to create an account, project and file structure, standard ways of working, key resources (like this article on time-saving Figma tips), how this new tool is different from your old tool, and anything else that will help your team members be successful. Give them a lay of the land and share resources available. You may want to schedule a separate onboarding session with each different team to allow for a more personalized experience.

Forum for questions: Create a space where people can ask questions and get help when they need. We created a Slack channel that was monitored by our action team and sub-action groups.

Support (1–2 month duration)

For 1–2 months following your initial kickoff, you’ll want to keep in close communication with your team as they go through the growing pains of using your new tool. Expect to experience the highs of using a better tool and the lows of things not working quite as expected. Provide a range of step-by-step tutorials and open forums to give people the support needed to become comfortable with your new tool.

Tutorials: Host live tutorials either with a member of your team or a representative from the new tool. This is where you’ll teach people how to use the new tool. Some of this may repeat what you outlined in your documentation, but people learn in different ways, so it’s helpful to expose people to the same information multiple times. The more you cover these concepts, the less room for error there is.

Q/A sessions: Consider hosting half-hour sessions at the end of the day 2–3 days per week for the first month or so after the move. Give people the chance to ask questions, demonstrate where they are getting hung up, or share cool tips/tricks that they have learned. This is a great way to keep people engaged after the main move. Even if people didn’t have questions, some will likely sit in and learn from those who do.

Move files into a holding place (Optional): If your team won’t have time to move and convert all files before your old tool is retired, put them in a holding place, like Sharepoint or another folder in your new tool. They can sit here until they are converted, regardless of the status of your previous tool. This way, no work will get lost.

Convert files: Make sure team members are assigned to moving certain files over to the new tool. As files get moved, archive the old ones in your previous design tool.

If people are not doing this on their own time, dedicate a day where everyone is only focused on converting files. Set up an open meeting on your video conferencing tool that anyone can join to ask questions when they need help.

Monitor file naming and structure: As people create and convert their files, make sure they’re sticking to the naming and file structure standards you’ve laid out. It’s easy to let this slide, but making corrections early and often will help people build good habits from day one. Everyone will be happy when the space is still organized months after the move.

Create bug fixing log: Since many of your design system components won’t have gone through a true stress test until your team starts working with them, create a log that all team members can use to report bugs and get them fixed.

Assess (2–4 months post)

Your team is getting more comfortable using your new tool, so now is the time to assess and make sure everything is working as you intended. You may want to make improvements on the file and folder structure, or just reinforce your initial standards.

Assess folder and file structure: Is the folder and file structure working for your team? What about your naming conventions? If not, host a workshop to brainstorm ideas that will work. Socialize new ideas and mock them up, similar to your initial process. Do what is needed to transition to new conventions smoothly.

Continue whatever practices your team needs for success: If your team wants to continue doing weekly Q/A sessions, do it! You may also want to provide more personalized help for team members who are missing out on key benefits of the new tool. Each team is different, so be receptive of what your people need to be successful.

Conclusion

I hope this guide provides enough information for you to move confidently from one design tool to the next. Since this happens once every blue moon, it can be intimidating to know where to start. Every team is a little different, so do what you believe will be best for yours.

Big initiatives like this are messy by nature, so don’t worry if things don’t go as planned. Remain flexible, keep your spirits high, and course correct whenever needed. Everything will come together.

Special thanks

Special thanks to Alison Snyder, Neil Epstein, and Jack Zankowski for their leadership through our move, and big thank-you to Neil Epstein and Jack Zankowski for proofreading this article!

If you’re interested in talking more about switching design tools, reach out to me on Linkedin or Instagram, or at sarahzuhlsdorf.com.