Please don’t delete your shared components 🙏

In software product, intangible programs make iteration much easier. We adds or remove lines of codes and a feature could go live or sunset. Yet, people is a nature that is unwilling to change, which means a dramatic change could provoke user’s rage. Thus, it’s better not to take out an already used feature at one night.

The components in Figma has many similarities with software applications. We have Figma as the platform, shared components as the product, and designers as the end users. To make the product enjoyable to the users, one way is by making gradual upgrades and respecting their workflow. Salesforce’s article, Feature Retirement Philosophy, provides a good guideline of gradual upgrades: advance notice, recommended alternatives, and uninterrupted support.

For a shared library in Figma, things get complicated when you delete a shared component. People’s design files remain the same when a component they used gets removed. They would notice a component is no longer supported while directing its library. Thus, for a shared design element that everyone uses in their designs, it’s important to keep things documented and not delete them.

Ideally, every component has their Figma lifecycle. For me, they’re “Ideate, Create, Update, Deprecate, and Archive”. I’d like to elaborate on the latter twos.

Following my early point, the gradual component changes include deprecation and archiving. Deprecation discourages the usage of a component but it’s still available to designers. Archiving a component is the same as retiring or removing a component. So a thing is no longer available to designers and it usually has a delay after deprecation. I prefer archiving because I would save the deprecated component for future reference.

Deprecating

There are some common ways involved while doing component deprecation:

1 — Changing layer name

Layer name is the first touch point for using a component. Searching, using, and receiving updates. Users can read a component name during these activities. If I deprecate a button component, I’d rename it to something like “⚠️Button [deprecated:2022–07–19]”. This approach ensures the 3 following things. The emoji gets more attention while one reads the name. Keeping the original component name makes sure we don’t lose the context. And the timestamp helps to learn how our system progresses.

2 — Adding extra visual aids

According to a popular article on Medium, having visual aids for a deprecated component can get people’s attention immediately when they receive the component update. For instance, a visible overlay on top of a button. However, the overlay forces people to handle clean-up tasks, otherwise the deprecated components would be a distraction in their design files.

3 — Providing alternative solutions

Most often, a deprecated component follows with a new solution. I usually put a sticky note nearby, mentioning the alternative and providing the link to its page/library. So anyone can follow the breadcrumb to learn how to migrate.

4 — Last but not least, giving people a heads up.

This can be done in any form of medium. By communicating your plan, your consumer would be well prepared and have a better expectation of what’s coming next in their design files.

Archiving

Archiving a component is like deprecating one. The tips of visual cues and proactive communication still apply. In Figma, my archiving behavior means un-publishing the component from the shared “cloud”. In a more accurate Figma’s words, it’s hiding a component. I personally prefer to add a period or underscore before the layer name, to turn it into a private component. That way, I can tell a component archived or not from its name without digging into it too much.

That’s my thought on deprecating and archiving a component in a collaboration environment. They work for me but may not work for you and your team. After all, the best solution is what works for you. :))

Thank you for reading this far :) You can find me on LinkedIn or personal site. All statements here are my own and don’t reflect the opinions of my employer.

This article is also curated in Minimal Musings, my sharing about design systems or remote work. Finally, my repeated song for the past few weeks is …

See you next time 🍻

– Chien-Chun Wu