Transitioning our Design System from Sketch to Figma
Tags: Sketch, Figma, Design Systems

One of the features of our components was hidden layers of content. Toggling them would surface new features, such as icons and badges. Our symbols could not rely on this tactic, which helped cut back on our total component count.

Thanks largely to one person on the team, we were able to port our design system into Figma in time for the design team to use it. Our bugs were relatively light, and it didn’t take long for the Figma components to be superior to their symbol counterparts. Easily our biggest issue was its management, mentioned later in the challenges section.

The day-to-day differences in supporting Figma

The change from automatic to manually created design artifacts is where the bulk of both our pros and cons come from.

Benefits to supporting Figma over Sketch

Superior quality of design system artifacts. Automatically generated symbols can only be so high in quality. Structure that made sense in React didn’t make a lot of sense as folders in Sketch symbols. The human touch unsurprisingly created a better UX for the assets themselves.

No longer supporting a forked library. Our html-sketchapp tool was forked and had active internal refinement. Bugs happened, CSS hacks were sometimes used. Dropping support for Sketch meant less development resources for this tool. Some of our biggest pain points with the design system as a whole was getting this program to translate our code well, and we do not miss this headache.

Design collaboration is superior. Since the design system team would also use Figma to work on new projects, we ourselves benefited from its collaborative tools. This is even more true when our work is all remote. We sometimes had to open up Sketch for legacy work, and it felt like we were going back in time.

Abstract had a tendency to eat work. If you didn’t use the software properly, sometimes people would lose a huge amount of work. Our generated system did not suffer from this, but it did occasionally happen with design explorations from various designers.

Challenges to supporting Figma

From the perspective of design systems, a lot of our challenges are tied to its management. There are certainly some more common asks such as more fleshed out auto-layout features and more powerful search, but those are mostly nice to haves for us.

Version control isn’t quite up to what Abstract can do. With Figma, modifying our library feels like maintaining a codebase that only exists on production, that many people can edit. Several times we have had unaccounted for modifications and deletions to our library, often taking days to even detect. With Abstract, our Sketch library had a much better process: branching, more robust commits, superior permissions handling, easier and safer reversion. We haven’t had the Figma library completely break yet, but it feels more like a question of when, not if.

Increased breaking changes in library updates. One way to deal with the version control issue is mimicking a common code workflow of local and staging environments. Backups are ready, production gets updated with what is in those other environments. Problem mostly solved, right?

The issue with this comes down to unique IDs to components. Figma uses some sort of unique ID behind the scenes for its assets, and they don’t quite follow components across copy/pasting or layer recreation. Take this example: A simple button exists in your library, with proper layer naming, a text layer, and a background color. Inside the component, you delete one or both properties, then recreate it with the exact same properties and name. You publish your work. If consumers of your library update, all of their button instances will get reset.

We have broken many of our components this way. Buttons, input fields, tabs, all start having default values in dev handoff files. Developers have to do a lot of back and forth, and designers end up taking the blame for looking sloppy. It is too easy for someone to go in and break the IDs on accident, and once they do, there’s hardly any detection system for us. We have done some makeshift testing with internal instances, but lacks the visual regression powers of Abstract.

When we auto-generated Sketch symbols, we got around this problem with slugs. Here is an example of such code:

<SketchSymbol

name='Button/Large/Solid/Primary' /* Symbol directory setup */

slug='button-large-solid-primary' /* Unique symbol identifier */

>

<Button large primary>Button</Button>

</SketchSymbol>

As long as we maintained the same slug throughout the component’s life, every update had continuity, even if we revamped all of the behind the scenes aspect of the component.

Increased release management overhead. A byproduct of these issues is the increased overhead in maintaining Figma assets. Sketch assets would only be updated following a code release. As long as we knew what was in code updates, we also knew everything that would change in the symbols. With Figma, all UI updates in code requires manual Figma updates. In addition, Figma could be updated independently to code updates. We now needed to track all Figma updates, worry about the hidden problems mentioned earlier, and have a communication strategy just for Figma. These process changes adds a non-trivial amount of project management and communication overhead. How can we be sure the code updates are in Figma? That they accurately represent what is in code? Who is keeping track of all the individual contributors to the library?

A more accessible, public roadmap and release callout would be nice. Sketch as a whole was easier to predict about what they were up to. With Figma, it’s a lot of guesswork, looking through Slack groups, Twitter threads, and their blog. Being in product development, I know the trouble of having a public roadmap, but it would still be nice to know the general direction.

For updates, Sketch’s updates page provides valuable release information, which has helped us identify what’s changed and what bugs might happen or be resolved. With Figma’s release page, a lot of information falls through the cracks, making it difficult to know what’s really changed.

Things we’re looking forward to with Figma

Number one for us is better version control and general guardrails. Next to Abstract, our Figma library library feels so fragile.

Refined Auto Layout options. Like most other Figma users, we’d love to see better width adjustments and padding options.

A Figma code tab that integrates with our codebase. Since leaving the Zeplin workflow, we’ve been eyeballing their connect component feature.

Continuing to refine our own process with Figma.

Was it worth it?

A design system should ultimately support whatever tools its designers want to use. We knew early on that tools can change, and are always committed to empowering their workflows. Our strategy of code as the source of truth gives us this flexibility. The time spent adjusting to a program was ultimately worth it for everyone, and while version management could be better, we also feel confident that Figma will continue to rapidly evolve.