Tao of Figma

Best practices for lean component libraries.

Have a naming convention.

Components, their properties, and their values should have a consistent naming convention. For example:

Consistently named components in Figma
DoComponent names are consistent.
Inconsistently named components in Figma
Don'tComponent names are inconsistent.
Consistently named properties in Figma
DoProperty names are consistent.
Inconsistently named properties in Figma
Don'tProperty names are inconsistent.
Consistently named property values in Figma
DoProperty values are consistent.
Inconsistently named property values in Figma
Don'tProperty values are inconsistent.

Naming convention should also apply to:

Consistently named hidden components in Figma
DoHidden component names are consistent.
Inconsistently named hidden components in Figma
Don'tHidden component names are inconsistent.
Consistently named deprecated components in Figma
DoDeprecated component names are consistent.
Inconsistently named deprecated components in Figma
Don'tDeprecated component names are inconsistent or not labeled at all.

Put properties in a logical order.

Top-down order of component properties should match the reading direction of the component.

Using toast component in Figma as an example
For example, this toast component has an optional icon all the way to the left, then an optional link, and an optional dismiss icon.
Toast component properties in Figma ordered left to right
DoProperties appear in order. Notice that the instance swap property for the icon is right under its corresponding boolean property.
Toast component properties in Figma ordered randomly
Don'tProperties don't appear in order.

Favor boolean component properties over variants.

Use boolean properties for toggling the visibility of component layers. This will reduce the component size and make it much more manageable.

Toast component has 40 variants instead of 5
The toast component from above would look like this if we used variants instead of booleans.
Toast component properties using booleans
DoBoolean property is used to hide any optional layers.
Toast component properties using variants
Don'tVariants are used instead of boolean properties.

Name your layers.

All component layers should have names. While semantic names are best, it it's okay to have something as simple as "container" or even "frame" (just not "Frame 1453583").

Component layers with semantic or cleaned up names
DoComponent layers have names.
Component layers with default frame names
Don'tComponent layers don't have names.

Don't nest components in unnecessary frames.

Placing components inside (unnamed) frames can make it more difficult to use the component, because it creates additional nesting in the Assets panel.

Of course, you should still use this feature intentionally :)

How a toast component looks in the Assets panel when placed inside a named section
DoA section is used intentionally to group components. (Note that section used instead of a frame).
How a toast component looks in the Assets panel when placed inside an unnamed frame
Don'tComponent was most likely placed in a frame to organize the library file, without considering how it impacts the Assets panel.

Don't create recursive components.

Don't use an instance of a component to create another variant of that component. This creates a poor experience for everyone who maintains and uses the library.

A recursive component
Instance of an Accordion Item is used to create another variant of the same Accordion Item component. Confusing, isn't it?

Set most commonly used variant as the default one.

Place the most commonly used variant in the top left corner of the component set to make it the default one. This will greatly reduce the amount of time designers spend on component configuration.

Most commonly used button variant is in the top left corner of the component set
DoMost commonly used button variant is in the top left corner, which makes it show up by default when searching Assets.
Not as frequently used button variant is in the top left corner of the component set
Don'tWhile the component set looks organized, it's not user friendly. The small, filled button variant is the default one, even though it's most likely not as frequently used.

Make icon components obvious.

You can add "Icon" at the end of the name. This makes it easy to differentiate it from a different component with a matching name:

Menu and menu in the Assets panel
DoMenu icon has "Icon" at the end of the name.
Menu icon and menu in the Assets panel
Don'tThere's no indication that the menu icon is an icon.

This becomes even handier in the instance swapping settings (since the thumbnail is much smaller that it is in the Assets):

Menu and menu in the instance swap settings
DoMenu icon has "Icon" at the end of the name.
Menu icon and menu in the instance swap settings
Don'tIt's hard to tell right away which component is the icon.

Don't create unnecessary components.

Not everything has to be a (sub)component, especially when it comes to component parts. The selection tool makes it easy to update component parts without resorting to creating another (most likely hidden) component.

Using a selection tool to select a matching part of all toast componenent variants
DoSelection tool eliminates the need for creating many subcomponents.
Extracting a part of the toast component as a subcomponent
Don'tDo icon + text really have to be their own component?

Don't create unnecessary documentation.

The best way to learn about a component is by playing with it. Adding documentation inside Figma is usually not effective, because most designers don't keep the component library file open as reference. They primarily interact with the components through the Assets panel. Adding unnecessary documentation also creates more unnecessary management work for the library maintainers.

If you want to have documentation, the best way is to have a simple website that everyone at your company can access.