Managing change and improving processes

In 2019, many designers had just joined the team within a few months, and each designer was embedded on a different product team. We were using Sketch, InVision, and Abstract (and Dropbox, which we never fully shook) as our tool kit to design, prototype, and collaborate.

With this setup, we had trouble keeping track of work. Each designer had their own system. Shared design system files were hard to find, and newer designers lacked context on the existing component library because we didn’t have any documentation. The ideal tool would enable the team to easily share assets and documentation so we could build off of each other’s work. Our goal was to be able to move seamlessly between designing, prototyping, and sharing work with stakeholders and engineers.

Based on our team retrospectives, it was clear we were ready to make a change. I took on this project because I wanted to improve the way we worked as a team and to lay the foundation for our design system, and through it, I had the opportunity to perform research, create a migration plan, and manage communication across departments. I also got pretty good at pitching Figma ;)


(How Do You Actually Do the Thing?)

There’s abundant info on why to switch to Figma and what to expect when switching, but how do you make a successful transition? These are some of the ideas that helped me shape the migration process for our team.

Plan and Delegate

This is a no-brainer for any project, but when it comes to workflow changes, it’s easy to talk about changes that never happen. To make sure we didn’t sit in inertia, I made a spreadsheet with explicit action items, owners, and due dates for testing software, making decisions, migrating our services, and communicating.

A boring old spreadsheet and doc in Dropbox Paper for the migration

Document Clearly

I also created a matrix for comparing the tools we tested, the major ones being InVision Enterprise with DSM and Figma. Spending time documenting feature comparisons, tracking feedback, and summarizing takeaways was essential to keep others in the loop. Keeping a matrix also helped the team prioritize needs and avoid getting overwhelmed by neverending feature lists, not to mention it made it much easier to explain the change when it came time to get software approved with the IT, legal, and finance departments.

Bring Others Along

Collecting an sorting feedback with the design team

Button is a highly collaborative company, so it was important to communicate proactively and provide a feedback channel for those who might be impacted. I gave presentations to the product, engineering, and marketing teams so folks had a sense of the what and why and had a chance to ask questions. Regular email updates and requests for feedback kept communication channels open, and speaking to different folks in person helped me fill blind spots in the transition plan, such as scheduling training for collaborators to set up their accounts.

Make Trade-offs

One challenge I came up against during this process was a fear of moving to the .fig file type—this migration would make it harder to access our archive of design files and prototypes, and we weren’t sure if we could convert .fig files back to Sketch if we changed our minds later. In a world where storage is cheap and we can keep pristine, digital copies of everything, there’s a desire to have full access to everything in history. But it didn’t make sense to prioritize archiving over improving our workflow. I found it was helpful to remind the team not to be too precious. At the end of the day, we don’t ship Sketch files or InVision prototypes. Those are artifacts, documents that help convey intentions for the final product. It’s okay to lose some of the artifacts once they are no longer useful. It’s more important that we can continue to move forward.


The benefits of moving to Figma are well documented on the internet.

  • Consolidating services and files
  • Keeping everyone’s files in sync
  • Smoother collaboration — built-in commenting, real-time collaboration
  • Better design system support

Based on positive feedback from the design team and our collaborators, the transition was successful, and we realized these benefits. After we had Figma set up, I also brought in Zeroheight as our design system documentation tool since it integrates easily and stays up to date. Read more about the Button Design System in this blog post.

Button Design System banner

What Did I Learn?

Every project comes with lessons. I learned to better anticipate others’ needs and keep people involved during changes.

This project was also a great exercise in leadership. Even though I was convinced early on that Figma would be a worthwhile change, it was scary to make a decision that would impact other people—and be held accountable for it. I risked potentially wasting time, blocking productivity, and increasing frustration, but being able to communicate to various stakeholders, make the call, and be accountable for the results are all parts of leadership.