6

It’s okay to detach instance on figma

 1 year ago
source link: https://uxplanet.org/its-okay-to-detach-instance-8e9ff86ed12e
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

It’s okay to detach instance on figma

Sometimes it’s better to be apart than together, so it’s better if I detach from you for a while.

1*Ze-tRqfdRUemH69v6_3Wvw.png

If we frequently use Figma and there is a design system in it, we will often encounter cases where we need to Detach instance. This is because we are at an early stage and need to explore new designs to solve new problems.

But sometimes, Detach instance cause confusion when we want to change the design because the design contains Auto Layout and Variants. Like it or not, we need to detach the design 😔. As the result, when we detach the design, we usually feel guilty because we have taken the design out of the system, thus making it inconsistent and not modular again. Before we dig deeper into it, we need to know what the component is.

What is the component?

*please skip this section if you already know

1*FseOezaaBMkAncRvkxTtyA.png

I want to share a little about the Components in Figma first. If you have used Sketch before, you will know about the “symbol” feature in that app. Component and Symbol are conceptually equivalent to the words “template.”This feature allows us to create a master template of our design and when we duplicate it, it will create an instance. So, any changes made by the master will impact every instance.

It can be likened to a parent and child: the parent sets the rules and the child will follow the rules.

Too rigid

The component feature in Figma (also with Auto Layout and Variant feature) possibility will have a risk with a new designer or a team that has rarely used or is not familiar with how to use that feature. It can make themconfused and frustrated because that feature is too rigid. The feature requires disciplined architecture and can’t allow for a quick and experimental change to our design. If we are forced to detach, this can make the previously created design no longer linked to the parent design, thus making our design inconsistent in the future.

Now, what can we do to deal with that problem?

Yes, agree that all features provide significant value to us. That is incredible consistency and modality. But we know that if a design is created through the iteration process, we need to try trial and error first to find a design solution that fits the problem that we are facing. Meanwhile, that feature is too rigid and can hinder the creativity of designers. Therefore, to deal with this problem, we have several options:

1️⃣ Option 1Can detach if we are in the early stages of the design process and we need to explore solutions as much as possible. At this stage, don’t hesitate to detach. Don’t let our time run out to edit the Auto Layout or Variant. Better yet, allocate time to exploring the ideas.

2️⃣ Option 2 — Think again before detaching if we just need a little adjustment or are in the final stages of designing. At this stage, we usually need to fix minor changes in the design. Because the exploration is not radical as in the early stages, so we need to reconsider to Detach instance.

Therefore to encourage the adoption of the use of the features to them. We can try to copy the master of the component and then detach it. After that, we can edit the copy of the component. Once we have finalized everything, we can rearchitect the Auto Layout and Variant. After that, we can import it into the master component where it will automatically apply to all instances.

For some people, this process seems quite easy. But for others, it feels inconvenient and complicated to do that. When we work in an environment that uses the system, we have to adapt by learning to use it.

Takeaway

When we look more broadly, this problem not only causes a headache for designers but also for engineers when they are developing inconsistent designs that we give to them. This will certainly make the development time longer and, in the end, it will affect the user experience when they are using the application.

This feature has two sides: a good one and a bad one. The good is this feature can save a lot of time and minimize the risk of generating inconsistent designs over time. But on the other hand, as a team, we need to be committed to that. Providing an adjustment periodto make all members understand the work pattern to be used. It is quite well worth the payoff for a simpler, more sustainable, and more scalable design system.

Thank you for reading! I hope you enjoy reading this article. Since you made it this far, I’ll introduce myself.

My name is Jufry Heryanta, and I’m a Product Designer at Tokopedia.

If you have any feedback or just want to chat with me, drop me a message at [email protected] or connect on LinkedInand Instagram.

1*YqgsoJZdz7Yj0iUqlbQtGA.png

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK