During Config 2023, I watched the talks about Figma’s new features, which got me thinking.

Is Figma transitioning from a design tool for designers to a no-code tool?

This feeling was reinforced after watching the launch of the Figma variables feature. Variables is a no-code feature because it allows designers to create fully functional prototypes without writing a single line of code.

On the one hand, it’s fantastic because it allows designers to create almost real prototypes without developers. On the other hand, designers will move to develop the prototypes with code logic.

Here, I want to share my thoughts and feelings on this topic.

Figma variables feature

What are no code tools?

“no-code tool” refers to software that allows users to design, build, and launch web applications or mobile apps without writing code. For instance, well-known no-code platforms include Webflow, Bubble, Glide, and Adalo. With these tools, you can create websites or applications without writing code.

Contrary to traditional text-based coding, these tools leverage visual programming and offer a user-friendly interface for app creation. In other words, you can create an app through an interface, not by writing code.

The main benefit of these tools is that they allow product designers, entrepreneurs, and other non-technical professionals to bring their ideas to life while creating a prototype or fully functional application.

However, “no-code” doesn’t mean “no logic.” Understanding the basics of how data flows, and functions work is still essential in the no-code environment to build an application.

Comparing Conditional Statements in Code versus No Code

Why I think Figma is on the way to a no-code tool

In my opinion, Figma is on its way to becoming a no-code application, primarily because of the variables feature.

If we can create a fully functional prototype using the variables feature, what’s stopping us from leveraging it further for complete app development?

We will get a functioning application if we can connect the prototype to a database. So if Figma incorporated a database, everyone could build an application straight from Figma.

There are some tools that accomplish this today, for example, Buzzy, Bravo, and several others.

If Figma be on this track, they can open themselves up to more markets, as they opened themself to developers with the Dev Mode.

It wouldn’t surprise me if they entered the no-code market at some point. This could be an excellent opportunity for Figma to expand its user base, attract more users, and penetrate into new markets, especially those dominated by popular no code platforms.

For instance, they could offer an app hosting environment similar to Webflow and Framer.

Because of the efficiency, we push designers to be more technical

I remember when we used Illustrator and Photoshop to design websites and applications. It was uncomfortable because these tools weren’t built to create apps or websites.

Then Sketch came along, and the real benefit of this tool was its more modern interface, and it’s killer feature called Symbols (referred to as components in Figma).

For the first time, we created an element and duplicated it repeatedly to be more efficient. This opened the door to what we now call a UI kit, which involves building a set of components and continuously creating an interface with them.

In other words, we built Lego pieces and played with them. Figma took it to another level; they improved the components and added the components’ properties, and now it’s a more powerful feature.

All these improvements allow us to connect our designs to the code. It helped us to create a full design system. Up to this point, everything is okay. We can work closely with the developers and provide them with screens built with “Lego” components, and they construct the app for us.

Now, Figma is encouraging us to code ourselves. We don’t necessarily have to write the code but can construct logic and create fully functional components.

Developers no longer need to build these — we can do it ourselves. To be more precise, developers still need to create these components with code, but the designer can create them to a certain level where developers don’t need to write the code. They can copy and paste it because all the logic is already there.

So, what’s going to happen next? Are designers going to have to do more tasks than developers used to do? Are we going to have to become more like them? These are big questions, and we don’t know all the answers yet.

We build “Lego pieces” and play with them

What are the benefits of Figma if it is converted to a full no-code tool?

Real prototyping
Designers can create real prototypes with full functionality. Unlike traditional prototypes that simply connect screens, you can build the prototype realistically.

This way, all stakeholders can understand clearly your design and how it will work, including all the interactions and small details. Additionally, you can test your assumptions with a prototype and get better results. Because it looks and feels almost 100% like the real product.

Build a real product
No-code tools make launching real products easier.

This means cost-effectiveness — there’s no need to involve a developer for every need, and designers can deliver solutions independently.

For instance, if you’re a freelancer working for a client, you can design and develop the application yourself. This is also beneficial for the person hiring you as you can provide them with a solution from A to Z.

In addition to fast launches, you can make super-fast iterations of the product and deliver improvements quickly to your client.

I want to put a disclaimer here and say that, for now, this will work only for a simple app and not for a complex.

Designer ownership
When designers use a no-code tool, they gain complete control over the technical aspects of the app. This means that designers can achieve the exact results they want. For instance, there will be no more debates about the size of an element or its color — if there’s an error, the designer can fix it immediately.

Where it’s Not Good for Designers

Limited Design Flexibility
No-code tools have some limitations regarding design flexibility. It means that designers may be unable to include all the interactions or features they want in their applications. These tools often follow standard guidelines, restricting the ability to create unique and creative interactions.

This contrasts with writing code, where almost everything is possible or, as one developer told me, “With money and time, it’s possible to develop everything.”

Consuming time
Building a prototype, web application, or mobile app with a no-code tool takes time. It will be a fully functional application, but it is necessary to invest time in it to make it happen. It means designers may need to spend a lot of time building it, which means investing time in technical work.

Dependency on your technical knowledge
Designers may want to build a complex interaction for the app, but because they do not know how to create it in the prototype, they will not use it. When we don’t know how to do something, we can do something simple, even if it’s not the best.

This is like a chef having a complex vision of a dish in mind. However, if they don’t know how to cook it, they will settle for a simpler version that may not be as good.

Increasing Challenges for Junior Designers in the Job Market
When we raise the level and complexity of the job, it will be much more difficult for junior designers to get started.

Today, it is very difficult to start as a product designer, so if the technical level required is raised, it will make it more difficult.

Increasing complexity is similar to climbing a higher mountain

What is the role of the designer in this situation?

After observing the advantages and disadvantages of no-code tools, the subsequent question becomes:

What happens to the designers if our tools transition to no-code apps?

Research: Just as before, we need to understand the user and, together with the product manager, define the scope and design a solution to it.

Visual Design
Our tools may become rigid block buildings, limiting the designer’s ability to deviate from structural principles. This is disappointing as it might mean that only design system designers will build the system, while other designers will only build the flow.

Design
I believe our principal task will remain the same; we will need to create solutions for problems and find the optimal flow and interactions. We will continue as we do today, finding the best flow, interactions, and of course, addressing edge cases — something designers like to do, but not really.

Creating prototype
Here I foresee a significant change. Designers will need to build a fully functional prototype before developing the apps. This prototype will allow developers to understand every detail before development.

In addition, the designer will be able to build the prototype and conduct a usability test, and again here, the team will ask him to build it with the smallest details, which takes a lot of time.

I see two points here. First, we may focus more on building the prototype and less on the design itself.

This means that if the product team asks the designer to construct a complex prototype (which isn’t simple), the designer might work more on the prototype instead of investing this time in resolving the issue. Herein lies the risk: Designers may transition into more technical roles, straying from their original designer roles.

Secondly, a team might have a designated designer whose sole role is to build prototypes. In this scenario, I can see the workflow functioning. However, if the designer is tasked with creating a design and constructing a fully functional prototype, the designer could act as an almost developer.

To summary

In the article, I wanted to highlight a topic that came to my mind after viewing Config 2023: Whether Figma would transition to a no-code tool.

In this article, I shared with you what no-code tools are and why I thought Figma was on the path to becoming a no-code tool. In addition, we reviewed how it could benefit designers and where it might have the opposite effect.