Architecting components
Architecting components
Organize components more distinctly.
As a product’s backbone, a design system must be functional, straightforward, and easy to use, with clearly defined rules and patterns. Sometimes that takes time and a lot of effort, but setting a solid base will help you boost your workflow in the future. And yes, there’s plenty of time when stakeholders are in a rush and want things to be done for yesterday, or there are no financial possibilities to put more focus on architecting the strong base of your design system. Still, if you communicate the pros and cons and get the green light to start working on adequately structuring your design system, this text might be helpful to you.
I will skip the overture and jump on the topic directly. But first, you must understand there is no right or wrong approach; this is useful and helps designers and developers make components straightforward.
Since Figma introduced nested instances, I have been thinking about optimizing them in the best way possible for what I need. In the beginning, I had trouble with having different states repeating in main and nested components. I needed to reorganize the component structure to find a way around it. Instead of having one master component, I started introducing subcomponents as building blocks of a component. Each building block had its variants and states; each was one component section. Those sections are then created as booleans inside the main component, enabling you to show an element and its properties only when you need them.
Let me break this down for you.
Think of each component as the layout with different sections. One section is equal to one sub-component. If you have complex components with varying layout options, having each section as a separate sub-component is a good idea. These sub-components are unique for each component and are hidden from publishing. Their primary purpose is to make your life easier when it comes to maintaining and giving you flexibility while implementing components into your design. In the image below, you can see the structure of the master component.
Each of the sub-components should have a structure of its own. Everything from different sizes to states, variants, booleans, whatever is needed. Why do we have this? It's because each time we use this section in our design, in nested properties, you will have a clear idea of how you can use it, and you will avoid redundant properties. In the picture below, we can see the section(sub-component) displayed in the nested instance.
Our main component consists of only section booleans. In this case, we want to avoid creating any state or properties already in sub-components. The main goal is to allow designers to interact and see only the properties they need at that moment by enabling each section.
.
Conclusion
Attention span is not our best trait these days, so I'll only take a little of your focus for the day. This approach can be applied to most components, although there are some situations where you don't need to go this complex. That depends on the complexity of a given element. It is essential to understand that you want to make clear rules and organize the properties panel so that people who need to become more familiar with your component can find their way around it.
So focus on splitting components into reasonable sections. Treat each section as a sub-component, a building block of a master component. By doing that, you will have clear rules around how components can be used and what they consist of.
Let me know what you think. And feel free to reach out!
Cheers!