And how pre-configured presets could make it even better
Recently, Figma released a set of new beta functionalities, which opens up a whole new level of component configuration for your design library. One of those features allows you to expose nested instances that are inside other (nested) components. If you haven’t seen it, you should check it out, but be warned, because you’ll want to re-configure your entire library again.
Luckily, I was in the process of re-working and improving on an existing design library for a client, so I was able to dive into it quite a bit. Although it’s in beta, it feels like it is safe to use, and I did not run into any issues so far. You can read more about it here. These are the things that I learned while using it and ways to improve your workflow when applying it to your work:
Rename layers
Depending on how you name your components, there is a big chance that the naming of the instance does not make sense immediately when another designers look at hem in the context of the main component.
Luckily, Figma allows you to rename the instance, which give you the ability to make it more specific depending on how and where it’s used. This way, the property panel becomes easier to understand and more accessible for other users. Keep in mind that you are not able to rename it from the properties panel, this is only possible from the layer’s panel.
Keeping it simple and efficient
I noticed that it was tempting to configure more than was needed and that it’s important to limit the amount of configurations you add, to avoid confusion for other designers. Configuring only the essential options can also be a way to showcase the limitations of a specific component. Combined with the preferred values feature, it can be a powerful way to integrate specific component behaviour in Figma.
What would bring it to the next level
With all the additional options that the beta offers, it can be tempting to try to force as much as possible in a single component. This can make the library lighter and easier to maintain. The downside is that you need a way to show developers, what all the possible options are (and aren’t).
Currently, I’m using instances of the main component to show all the variations (with or without the nested instances) inside the library file. Basically by grabbing an instance, configuring the use cases and placing them on the canvas as documentation. But these configurations, are still a custom version of how I interpreted and configured the properties.
This brings me to the preset idea I mentioned in the title. I think on top of this, it would be really convenient to be able to configure presets. This way you can allow designers to pre-configure specific use cases, name them accordingly and make them available to the rest of the team. A specific combination of elements, like the example below, would be then be more accessible and less error-friendly.
Documenting use cases will be even more integrated in the library this way, and it leaves less room for interpretation of certain specifications. For example, there is currently no way to immediately understand that the product tile, in the example above, needs a ‘Sale’ tag when something is on sale. Someone, who might not be familiar with the system, could easily add only a discounted price while not knowing that an additional label is also part of the use case of discounted products.