The Great Migration from Sketch to Figma

5 key differences between Sketch and Figma design system libraries

Design Systems

Design Tooling

6 min read

Background

I’ve used the big three UI design tools in my career as a designer. Like many students who had Adobe Creative Cloud included in their tuition, Adobe XD was my first prototyping tool. When I started working, I learned both Figma and Sketch quickly with the familiarity from Adobe XD; however, I highly favored Figma as my tool of choice.

I joined Rubrik in the Spring of 2021, which was when the product design team was about to transition from Sketch to the then newly-procured Figma. The question at that time was who would drive the design system migration.

Although I was green, my excitement for Figma allowed me to convince my manager to entrust me with such a high-impact project. Over a couple months, I began to learn the ins and outs of libraries in Figma, a side of Figma which I previously never discovered. The following are 5 key differences for design system managers to note when migrating existing component libraries from Sketch to Figma.

Role

Product Designer, Visual Design Team at Rubrik

Timeline

July – September 2021

Stakeholders

Product Designers, Engineers, Product Managers, Product Marketing Team

Text styles aren’t associated with color

The first difference I encountered early on was how Figma handled text styles. The text styles we had in Sketch required all text properties, including text color. While this ensured the correct colors were being paired with certain text styles, we ended up with a large list of text styles, since multiple colors were valid for multiple text styles.

In Figma, text and color styles are stored separately. The benefit of this logic is that we could eliminate duplicate text styles that only varied in color, so that we are left with the main styles of varying font sizes and weights. We kept documentation of all the valid color and text pairings, and created text components with both styles applied for common text usages.

Sketch

Text styles are defined including font size, font weight, line height, and color.

Pros:

When creating new text fields, designers don’t have to set the color style separately, saving them an extra step, and less incorrect pairings.
Color and other font properties can be overridden if needed.

Cons:

A lot more text styles needed to be created in the design system, in order to cover all valid combinations of text styles and text colors.

Figma

Text styles are defined with only include text properties (font size, font weight, line height, text casing, etc.), without color.

Pros:

Less text styles needed, because text styles can be paired with any text color available.
Text components can have the text style and color already applied to it, and designers can still override styles when needed.

Cons:

When creating new text boxes, designers need to set the text color themselves. The correct text and color pairings is knowledge they must know or need to reference, making incorrect text and color pairings more likely.

Combining similar components with the power of variants

After wrapping up styles, I moved onto components, starting with buttons. Variants in Figma were a relatively new feature at this point in time, but once I experimented with the versatility of component properties, this became another big revelation in my migration effort.

In Sketch, our design system library was fairly large, in part because every state and variation of a component existed as its own symbol (aka component), and because we created every one of those symbols in 3 different themes (which I’ll cover next). Rebuilding these components in Figma, I only created one component for each element with a unique name, and was able to include all the “variants” inside that component set. This vastly reduced the number of components in the library and made it easier for designers to toggle between related versions of a single component.

Sketch

Individual states and variation of a component were created as separate symbols.

Pros:

Symbols could be grouped by using slashes in the names. This allowed them to show up together in the symbols menu.

Cons:

Design system library becomes huge as every new component could require adding up to 20 new symbols in the Sketch library.

Figma

Components could have variants for different states, variations, etc.

Pros:

Design system library could be more lean, with less individual components.
Designers could easily toggle between variants in the component panel.

Cons:

The ability to create variants under a component encourages creating all different combinations possible, resulting in more upfront work from design systems managers.

Head start on prototyping with variant interactions

Our team was previously using InVision to create basic prototypes for testing, so the team was especially excited about Figma's built-in prototyping tool. I was pretty familiar with Figma’s prototyping capabilities, having used it in my past work roles and for school presentations. However, variant interactions did not exist back then. I signed up to use Figma’s beta version of variant interactions, and I was massively impressed with what variant interactions could accomplish.

In the past, I have to admit Figma didn’t handle hover interactions very elegantly, especially for repeated elements. Most methods relied on overlays to mimic the effect. Variant interactions solved that problem, allowing variants to be “changed” to another variant on different triggers.

Sketch

Prototyping was done outside of Sketch, using InVision or another tool.

Cons:

To create a prototype required exporting static mocks as images, uploading them to the separate prototyping tool, and adding hotspots to move from one screen to the next.
Extra cost paying for another design tool just for prototyping

Figma

With variants, components could also have built-in variant interactions.

Pros:

Gives designers a head start on prototyping, making prototyping less time-intensive and more accessible
Interactions can be more granular and high-fidelity when prototyping with editable design layers rather than static images.

Cons:

Built-in clicked states sometimes break when adding a clickthrough destination on the same layer.

Separate library for separate themes, swapped easily

Perhaps this migration may have been more efficient if it was delayed by several months, because Figma was rolling out incredible design system features throughout the entire duration. The Swap Library feature was released after I had already migrated the majority of the components to Figma. However, that didn’t deter me from experimenting with how it could alleviate redundant work for designers.

The main application of the Swap Library feature was repurposing design layouts with different branding. This feature was primarily created for agencies, but could also be helpful for teams that work with multiple style guides, such as dark and light modes.

So, I created a separate library file for each of our themes, and made sure the names of the components were consistent. After testing out the swap action a couple of times myself, I demonstrated the feature to other designers on my team, and their reactions were priceless, as if they had just witnessed magic.

Sketch

Components from all themes were created in the same library.

Cons:

The library file became so large in size that it became difficult to load. Even small changes took a long time to update because of this.
To change designs from one them to another required swapping each component one at a time.
Sketch’s component menu was a dropdown menu that opened more dropdown menus. It was time-consuming to use and difficult to navigate if you didn't know which category the component was part of.

Figma

The Swap Library feature enabled swapping a file in one theme to another theme.

Pros:

The Swap Library feature saves designers time by allowing them to create mocks in another theme by just the click of a few buttons.

Cons:

Transitions are not perfect, usually fault of the components not being named exactly the same or a bug in the components’ composition.
Takes time for design system maintainers to ensure all components are properly mapped between libraries.

Real-time collaboration with multiplayer mode

And of course, this comparison between Sketch and Figma wouldn’t be complete without mentioning the real-time collaboration capabilities of Figma. Their original tagline, “Meet me in the browser,” references their online multiplayer technology which allows team members to work together from the convenience of their browser or desktop app, if they so choose.

Sketch

At the time, Sketch required another software, Abstract, to upload files to the cloud.

Pros:

Only you are in the file at a time, creating a sense of a quiet space to focus on designing.
Designs could be shared with stakeholders via "collections".
Abstract had a comments feature for stakeholders to leave feedback directly in the collections.

Cons:

It was incredibly slow, saving work took a long time.
In addition, the technology was often buggy, causing a lot of designers to lose work and consequently hours of their time to redo the same work. As backup, designers downloaded Sketch files onto their computer to ensure their work wouldn't be completely lost.
The software running also took a lot of computer RAM, resulting in overheated laptops.
There was no real-time collaboration in the design file, so we needed to hop in Zoom meetings to screen-share rough work.

Figma

Figma is online by default, with powerful audio and observation tools.

Pros:

Collaboration is more accessible, without needing to screen-share on Zoom. You can just follow the other person in the Figma file directly and use the audio chat feature to talk.
Figma is more fun to use. Their focus on collaboration fosters a sense of community even when teams are working remotely.

Cons:

There is no official offline mode, meaning you cannot work for too long if you're not connected to internet.
Seeing people’s avatar pop in the file can cause anxiety for some. Persistent collaboration can create a constant feeling of being observed or someone looking over your shoulder.
You need to pay attention to file permissions and security access, especially if you're working on something confidential or private.

Takeaways for design systems designers

This list is by no means exhaustive of all the differences to note for design systems folks. Auto layout, effects styles, and smart animate are just a few other transformational features for designers to leverage.

Reflecting back on my experience as an IC driving a high-impact design tooling project, here are 3 main considerations for teams about to embark on a similar journey:

Leverage Figma's education resources, help center, and forums. When I started this project, there was so much design system specific functionality that I did not know about. I took time to learn about the features and experimented them on my own. Figma's customer success team was also very helpful when I contacted them about specific problems I encountered.
Don't get sidetracked by minor inconsistencies. As you rebuild components, you naturally perform an audit of the design system, and inevitably run into discrepancies between design and the implementation. Make note of all those items for future roadmapping, but don't let them become long detours that delay the overall migration effort.
Create Figma onboarding resources and hold office hours. Before unveiling a new tool to the team, consider the different level of familiarities on the team. Although some designers on the team were able to switch over to Figma comfortably, some members needed more time to adjust as they had never used it before. After the initial onboarding presentations, I held designated design system office hours and workshops for designers to learn how to incorporate new Figma features in their workflow.

Check out my other work

Configuring Chip Components

Refactoring chip components by creating visual and usage distinctions

The Need for Low Fidelity

Developing a wireframe library for better design discussions with stakeholders

Refactoring Filters

Improving the usability and usefulness of table filter components