Figma — Effective Guidelines for Nested Instances in Design Systems
Components (In Figma) and Symbols (in Sketch) set the foundation for rapid prototyping and evolving design systems since they save hundreds of hours of prototyping time with their reusability. However, the cost of quick component usage is the time it takes to create components, and this is where nested instances come into play.
In this article, I will outline several guidelines on how to effectively use (and avoid) nested instances within components based on two specific goals.
- Quickly configuring individual components or component sets without breaking other parts of the system.
- Understanding when and where to use multi-level nesting (instances within instances within instances….).
What is a Nested Instance?
Let’s start with a basic intro to nested instances.
The master component is a sort of a hive mind that essentially has near-absolute control over all its instances. All changes pushed to the component will reflect in the instances.
A nested instance is an instance of another component that is housed as a child layer within a component. The component properties for the nested instance can be available in the parent component by triggering the ‘nested instances’ option when setting properties for the parent component.
Any component properties associated with the nested instance will be accessible in the design panel for the instance of the parent component. This effectively eliminates the need to individually click on the layer for the nested instance to access its properties.
The Advantage of Nested Instances
When a component has a large set of properties, it can become overwhelming to have all those properties available for a component that may only need a fraction of those properties. Nested instances allow for better organization of properties while allowing users to collapse/expand nested instances that may have properties irrelevant to that component for that scenario.
In addition, any changes to nested instances will reflect in all the variants to the parent component.
Effective Guidelines for Nested Instances
Number of instances vs. number of properties per instance
Nested instances are much smaller parts of larger components, so their scope is limited to the usage within parent components.
Overloading nested instances with component properties negates their effectiveness in minimizing the overload with parent components. Keep the number of component properties for nested instances between 2–5.
Avoid using nested instances in components that fall into different categories
Nested instances within a component layer are still controlled by the components that they’re based on. This effectively means that any changes to the component will affect all the nested instances within a component set.
Avoid using nested instances in components that fall into different categories (ex: Using a ‘label’ instance for both a button and an input field). The reason for this is that any changes to a nested instance might be useful to components of one specific category, but not to the other.
Even if you have to duplicate the nested instance for use in component sets that fall into different categories, there’s more individualized control over those component sets without affecting other parts of the UI kit.
When and where to use multi-level nesting
Figma recently upgraded their nested instances feature by allowing users to access component properties for different levels of nested instances. This effectively allows users to component properties of instances within nested instances.
The conundrum of using multi-level nesting is having the same instance multiple times in a single component (ex: a table having multiple table row components) also exposes all the nested instances associated with each of those instances (along with component properties). This would create an overwhelming number of multi-level nested instances and their properties.
In such a scenario, it might seem more effective to avoid using multi-level nesting to have more control over the exposure of nested instances. However, it would be extremely tricky to execute this for table components because there’s editable text at every level (primarily for table headers and table cells).
The strategy here is to selectively choose the nested instances which have properties that require configuration at the parent component level. Disabling the visibility of certain instances that stay the same during the prototyping process will allow for more control over the visibility of only relevant nested instances.
A good rule of thumb to see how often a nested instance is duplicated within a component variant. The more number of times a nested instance is duplicated, the more likely the design panel will overwhelmed with properties from multi-level nesting.
Conclusion
In conclusion, nested instances are an essential part of having individualized control over different component sets without creating a domino effect of breaking the rest of the system. I will be creating more articles on nested instances, and welcome any feedback or any questions on design systems.
