Design System for Figma — The Power of Dynamic Elements
Over the course of the previous year I’ve been trying to follow a more solid design system using Figma. The power of tools such as Figma Components reaches its peak of performance if as a designer, one can dominate its flexibility within a process one feels confident in following.
Here I am a few months after discovering the tool, exposing how I approach the organization of elements and components. This article aims to generate discussion about what other people may be doing differently and it welcomes feedback, as it is in no way a process set in stone.
For the sake of time, Figma Components will not be explained here in depth. In case you’re not familiar with Figma Components, Figma has this great article.
Getting the scope of each element
When designing sustainable interfaces, it becomes important to be aware of the composition of each element. More complex elements have wider branches within them, resulting in a natural hierarchy of elements.
Let’s use toggle buttons as an example of an element. In its purest form, a toggle button is the result of the sum of two sub-elements — a background rounded-edge rectangle + a circle that will move to right and left when clicked.
Therefore, we can break the toggle button into multiple pieces. These pieces are parts of the skeleton of the toggle button. At this point we can predict that the toggle button itself will be part of the skeleton of an element of higher hierarchy, and so on.
Jumping into Figma straight away might become a problem at some point in the design process because we did not anticipate which elements would be part of our element. What are the sub-elements that allow this element to exist? The more complex the element, the more likely it is to impact the sustainability of the elements we’re building.
Designing on paper first can help. The lack of fidelity on a quick sketch gives us the freedom to risk and test different sub-elements before making a decision. My experience has told me that jumping to Figma after that makes the job much easier.
First components — Quarks
Throughout this article we will build a set of three different toggle buttons that differ in their background color and position of the toggle circle.
We’ve already broken down the most simple sub-elements of the toggle button composition:
- three backgrounds — each one with its specific color
- a white circle — shadowed for skeuomorphic purposes
We get to this conclusion because we know that we want three types of toggle buttons that differ on the color of their background. The white circle, on the other hand, does not have changes in itself across the other toggles (only its position on the toggle, which is external to itself).
These basic elements are called Quarks.
Quarks are the the basis of the basis. And for that same reason, we must turn them into Components.
Why create Components?
If you think creating Components is isn’t worth the time and the effort, you should try not creating them. You’ll cry and hate yourself for not having done it before. On top of that, you’ll have a Figma document with over 30 artboards that contains 200 copies of an element that is not a Component, and now you want to change its color. Imagine that.
Previous experience has led me to the conclusion that you should create Components when:
- you will — most likely — want to change some aspect of that element later
- you will use that element somewhere else
In past projects I have lost a lot of time redoing elements, turning them into Components and then redistributing these Components across the interface. These two rules of thumb were hard to learn but they’ve proven to be very useful.
Atoms come into the picture
Quarks alone usually have no value to the design. They need to be combined to originate the Atoms we want.
Atoms are elements that result from the combination of Quarks, forming elements with a higher level of complexity and fidelity.
Because we want to have more control over the construction of an Atom, we will turn them into Components. In case we ever need to change the position of the Quarks inside the Atoms, it will be much easier thanks to the power of Components. A unique change on the Atom Master Component will apply changes across all the distributed Components.
Designing with a prototype in mind — Dynamic Elements
At this point we have three components — Active Toggle, Inactive Toggle and Gold Toggle — that we can use in our interface.
In the majority of times, a prototype will be mocked at some point during the design phase. After testing it with users, we will gather insightful data and iterate on our interface.
The construction of prototypes — really detailed ones — requires many element states. Usually elements are named according to their multiple states such as “button-red-hover”, “button-red-visited” and so on.
While building prototypes, I feel the need to quickly change between element states. In the toggles’ case, instead of using each Atom separately, I use what I call a Dynamic Element.
A Dynamic Element is a Component that groups all the sub-elements that represent different states or variations of one sub-element.
Using Dynamic Elements solves the problem of changing between states of an Atom between screens in the prototyping phase. By making use of hidden layers, we can use the Dynamic Element of the toggles (that contains all the Atom toggles) and hide whichever layer we want to be seen in each screen.
We can do this by quickly selecting the Atoms we want to hide and hit Ctrl+Shift+H (Windows) or Shift+Cmd+H (Mac). There is also the option to select the layer we want visible, head to Object > Hide Other Layers and all the other other layers inside the Dynamic Element will be hidden.
Dynamic Elements are basically a bag. A magic bag, actually. And we can place each magic bag on our interface. In this case, we have a magic bag of toggles that contains all the existing toggles inside of it. We can place multiple magic bags on the interface we’re building and say, “hmmm, you here, become a gold toggle. You there, you should be an inactive toggle.”
Such elements were inspired by Thomas Lowry’s post as well Tom Johnson’s response, where they describe using different variations of an element (icons, in their case) inside one single Component.
Name Dynamic Elements > Conquer the world
In this specific case, the Dynamic Element contains all the Atoms of toggles (Active toggle + Inactive toggle + Gold toggle). The word dynamic is used to describe such Components because they can take many forms. By hiding layers, we can display toggles in a dynamic way.
If we have these elements throughout our interfaces, it becomes important to identify them. Otherwise, they do not announce all the power inside them (the ability to change between many states inside them). Therefore, it becomes important to name these accordingly.
Going through the prototyping phase, I felt the need to have something that would make these Dynamic Elements stand out. It is important to say I am not in any way an expert in naming methodologies (and you’ll agree in a second). That’s a field I am still exploring but I can tell you what has been working for me.
I use emojis.
More specifically, I use three unicorns, as in 🦄🦄🦄
There is no way we are missing a Dynamic Element this way. Whenever an element has three mystical beings at the beginning of its name, we know for a fact that inside of that Component there will be a variation of states. We can open it, hide/unhide layers and get back to the prototyping phase.
BUT FIGMA ALREADY HAS THE INSTANCE THING!!!
True, it does. But I feel it lacks understanding.
When you select a child of a Component the Instance option allows us to change to another component. In other words, it would replace Dynamic Elements. Instance is even smart! It’ll suggest other Components similar to the original one we want to change, and prioritize that choice.
In this case, we are trying to change the big blue elipse Component to another Component. Instance suggests others that may be the right option to change to.
But let me tell you another story.
Above you can see an example of what Instance looks like when we have a lot of Components. It becomes hard to be navigate through all the Components — in this specific case, there’s a page that is not available on my screen due to the huge amount of Components displayed.
Sometimes Instance can even betray us. Some of the suggestions we get when trying to change Components might not even be close to what we’re looking for — and then we may have to swim through the ocean of Components, as displayed above. Because it’s organization is highly dependent on the naming of Components, it can backfire.
Keeping it clean and tidy
I usually include these elements in Frames named after the type of content the Components represent for accessibility purposes.
I find it important to have these elements accessible. If anything needs change, we know where to find these. Usually I use a structure such as the above, where I have:
Quarks
- 3 different backgrounds for the button (Component)
- 1 white circle (Component)
Atoms
- 3 different toggle buttons (Component)
Dynamic Elements
- 1 element that contains all the toggle variations (Component)
The different sub-elements and the elements they represent are clearly displayed, as well as Dynamic Elements.
Prototyping with Dynamic Elements
Prototyping with Dynamic Elements became much easier.
Using only one Component named with three unicorns, we know that we have all the states and variations inside of that Component. By hiding layers, it is possible to quickly jump between states and avoid the mess of looking for other variations in the Instance menu.
How are you using Components and organizing your elements on Figma? My goal is to improve on this approach. Here are some questions:
- In which cases might this approach block me in the future?
- Where am I wasting time and resources and how can I avoid that?
- What are your best practices and how can we all learn from them?
Links that might be of use
- You can find a diagram flow of the Component process on juauz.com/figma.jpg
- Click here to explore the Component organization by getting a copy of the Figma file I used as an example (with elements + prototype)
Considering a range that goes from “I should’ve closed this tab 5 minutes ago” to “Where can I hire this guy?”, I hope this helped you in some way. By the way, the hiring thing would be on juauz.com — thank you!
