Thomson Reuters
Senior Design Director
Eagan, MN
Choosing the right design tool can be a big decision for any team. Keeping up to speed on software is important, but it's often easy to end up with a “grab bag” of tools that can be challenging to work with and difficult to scale as your team grows. People suffer from "tool fatigue" and get confused on what tool to use for the task and time to learn new tools is often an expense that goes untracked. Not to mention orchestrating a migration of your team and design assets to a new design tool can be daunting.
I recently had virtual coffee with my colleague, Kristina Taegel (Senior Designer), and we reflected on the migration of the Thomson Reuters Design Organization from Sketch, Abstract, and Invision to Figma. This article outlines the journey the team took and offers up some practical advice.
AMY: Hey there Kristina! Thanks for joining me for a cup of coffee! Let's start out with the important first step: “Choosing the right design tool for the way a team works.” Teams are more globally distributed and cross-disciplinary in their skill sets than say 5 years ago. When it came to evaluating the capabilities we needed to support our workflow and a rapidly growing team, we spent a LOT of time talking with the account reps at Figma. Many of us were familiar with Figma already, but let's dig into some of the workflow and migration items that go beyond just design.
KRISTINA: Hey Amy! For sure, transitioning to a new application as a large organization poses its own set of challenges. We knew working within a web-based application with real-time collaboration capabilities, would be a game-changer for our team and organization. We had been using Sketch to create our design assets and Abstract to manage our design branches and collections. Even though there are solid integrations between Sketch and Abstract, it meant a lot of synching back and forth. Figma has all of the design, branching, and version controls integrated as well as commenting capabilities for stakeholders, content writers, accessibility, and development partners to easily ask questions and leave comments directly in the design files. These capabilities better supported the way we worked and collaborated with other teams and non-design stakeholders. Having a "one stop shop" significantly reduced the number of applications we used and how we managed access.
From a design perspective, moving to Figma has been highly advantageous. Creating scalable components and variants facilitated collaborative work across the design organization. Components can be built once and used by all designers, ensuring uniformity in usage, brand, and accessibility. Figma offers developers the convenience of accessing code directly from the design file. This is further complemented by design token libraries, which can be efficiently updated across the entire product. Although we had to invest time and resources in training and streamlining our processes, this was a strategic and worthwhile first step towards bringing together a previously fragmented design organization.
AMY: Once the ball got rolling with Figma I think we all took a step back and realized that this was going to be a massive endeavor. You played a key role in building the original component library for the Digital team in Sketch and Abstract. I'd love to hear how you and the rest of the team started planning for the migration to Figma.
KRISTINA: When thinking about the transition from Sketch to Figma the first thing to consider was a lot of clean-up and refining of existing design files. This entailed sifting through files, removing redundant elements, and establishing a clear plan for transferring relevant content. We approached this task collaboratively and divided responsibilities amongst the designers.
AMY: Yah, it was very much an "all hands on deck" kind of scenario in which we had to quickly and effectively catalog, tag, and prep files.
KRISTINA: Exactly. We implemented an emoji key in the design file pages to facilitate the process by identifying the status of the page and the file itself. Additionally, we made certain to preserve the original Sketch files in their entirety, thus ensuring a comprehensive record of all designs. Before I started moving things over, because it was a one-to-one replacement, it was important to spend a good amount of time learning Figma, how components and variants work as well as building the components and making sure they were responsive. The next mountain to climb was rebuilding our component library in Figma. There was a lot of "Youtube University" and reading/viewing Figma's library of tutorials, but a lot of it was building, troubleshooting and playing with components until you got it right. If I am being honest, there were moments of frustration, but I can truly say I learned so much.
After the components were built, we could then re-build the active designs we bought over from Sketch to Figma. For me, it was delegating the work and chipping away at it when I could. This was really useful in getting to apply components and fix any components that weren't working properly before the larger group was using them. It took time, but the payoff was great and we were ready to move forward in Figma.
AMY: I remember the hours of prep on how to execute the migration. We knew it was going to be a bit messy, but we worked really hard to create the least amount of disruption between design and development. Shifting gears just a bit, I know that governance and naming conventions played a big role in how the team prepared to roll out access to Figma.
KRISTINA: Right! File naming and organization needed to be easy to understand, make sense in the context of working in stories, and provide documentation. We decided early on that we would have “legacy files” which would remain untouched and any new work or iterations would be in a new file, complete with a Cover page that includes the Jira story ticket number and link. Change logs were implemented to ensure designers were working from the latest file. This saves time and effort to find the most recent work and features.
It was crucial to establish solid processes to ensure scalability and that everyone was on the same page. However, it is essential to acknowledge that while nailing down these processes was a great starting point, as the system becomes more widely used it is essential to be flexible and prepare for changes. Designers have a lot of ideas, so getting input from their specific use cases presents value in learning, evolving and refining our processes as time goes on.
AMY:So let's fast forward and chat about training and on-boarding the design organization to Figma. Some days it felt like we were “building the plane while we're flying it” mode. You know…doing all the things: designing and delivering products, building design teams, on-boarding staff, creating a community of practice, etc.
KRISTINA: Teaching others how to use the application while simultaneously learning myself was an interesting experience. I found that teaching the basics and providing resources that teams could refer to worked best. My primary objective was to help them get started so that they could become self-sufficient in their learning.
We met weekly with our Figma rep and learned how to use it more effectively in a REALLY short period of time. We set up virtual "Office Hours" so the design team could ask specific questions, troubleshoot problems, and share new things they learned along the way. This was a huge help in coming together as a cohesive design organization.
AMY: I agree. Well, hey, Kristina…my coffee cup is empty and I have to jump. Thank you, thank you, thank you for our nerdy chat. Let's do this again!