Build your components usefully
Figma components are becoming more and more powerful as they can be your best allies when building a digital product. They have a brutal potential that will make life easier and take away a lot of headaches if they are used correctly, otherwise they can become your worst enemy. As always, great power comes with great responsibility.
But, the question here is, is it possible to create the components we need without spending hours and hours on it? Let’s start from the beginning.
1. The basics
The main idea of components is to have reusable parts that allow us to maintain consistency and homogeneity in our design.
These components are divided into two types, masters and instances. The master components are the ones that define the structure, behavior and functionalities of our instances.
But… What is an instance? An instance is nothing more than a copy of a master component with the same structure and properties, allowing us to make changes in content. It is like if the master component were a mold and the instances were copies of that mold, but with the advantage that when modifying the parent mold, the copies are modified in the same way, so it is very easy to maintain.
However, the main advantage is that any change of structure that we make in our master components will be transferred to our child components (instances), although in the instances we will be able to make customizations like colors, text properties, etc. What we call overrides.
In addition, this year’s Figma Config event has released some new properties that allow us to simplify and make our components much more powerful. These are text properties, boolean properties and instance changes. We will talk about them in more detail later on.
When should a component be made?
A fairly simple rule of thumb when considering whether or not to create a component is to think about whether you will use that element more than once. If the answer is yes, the best thing to do is to create a component. Working with components will help to maintain visual coherence as well as making it easier to transfer information to the development team.
The main idea of the components is to have reusable parts that allow us to maintain consistency and homogeneity in our design.
2. Properties of the components
Boolean. Hidden layers in our components.
It is normal for a UI to have several elements (buttons, inputs, cards, etc). Each of them could be a component and, within them, they will have visible or hidden elements in order to cover all the available options.
Let’s explain this with a very simple example.
Let’s imagine that we have an input, with several states: Default and Filled. When our input is in the second one, we want to show an icon to accompany the content written in the input. To do this, instead of creating two different components, we will only create one and apply a boolean property to our icon so that it appears when it is needed.
This way we will have one component that will be used for two states. This will be our base component.
In the master component, we can specify whether we want the default icon or whether the input will be displayed without an icon by default.
Important. Having components with a lot of hidden layers can reduce the performance of our Figma files, because these hidden layers also consume memory and, if we abuse this property, it can become quite tedious to maintain our components.
In short, hidden layers yes, but with sense.
At the same time the elements of a UI have different states (default, active, hover, disabled, error, etc.) and this is when the variants come into play. This property allows us to have different versions of our components, in order to have these different states.
Back to our example:
We could have an input with erroneous status, which we imagine marks the input in red, and a support message appears indicating the type of error. This would be a variant of our input component.
Change of instance
This is the moment when it starts to get interesting and gets a bit more complex. In a component we can include instances of other components, in this way we can have a component formed by other components and have nested components. The problem is that managing these instances sometimes becomes very tedious if we don’t use the “instance change” property.
What this property allows is to manage the instances of our components without having to navigate within them, in other words, if we have a component formed by instances of others, it allows us to change them in an easy way.
A very simple example:
We have an input with a text and an icon (which is an instance of a library), both form a component. To be able to change the icon of the input without having to have a variant for each icon, it is as simple as applying the property “Instance change” to the icon, which as we have mentioned is an instance, this is important because otherwise we will not be able to apply this property.
Once applied, a new property will appear in all the instances of the input component to change it for the icon we want. This is not only applicable to this example, there are a thousand applications.
3. Component libraries
When working on very small or isolated products or projects, the components are usually hosted on a separate page, but this is a problem, because if you have several files of the same project, you will not be able to use the components in all of them.Therefore, we recommend that regardless of the size of the project, always have our library file at hand. This way, if the project grows, we will have some of the work advanced.
This will ensure design integrity and make it easier to maintain the components. The only thing to keep in mind is that if we update the library, we will have to update the files that the library is using.
Normally our components have generic content, such as demo texts, button labels or placeholder in inputs. We will not be able to change the structure of our components in an instance but we will be able to write texts, fills, shading, borders, etc. This allows us to adjust them perfectly to the context and needs of the UI we are designing.This is what is called an override. How to maintain overrides?
- Between variants. Figma, by default, tries to keep the changes we have made in the instances between the variants of our component, but this is when it turns a bit “tricky” and we have to know certain details when building our components, so that everything works correctly. In order to change from one variant to another, our layers between variants must match completely, both in name and hierarchy.
- When changing instances. The importance here is in the distribution of the variants within the component and choosing correctly which one is going to be the default value, so that when switching between them the default values of both correspond and Figma can maintain the overrides automatically (this also has to be combined with what we mentioned above, layers with the same name and structure).
Figma is a tool that in just a few years has made creating and maintaining component libraries a slightly easier and less tedious task, offering designers a number of possibilities. Maintaining the correct order, structure and naming of both layers and components is essential for your component library and workflow performance to increase exponentially.