Is the Designer Becoming a Developer Too?

Between AI, prototypes that increasingly resemble real products, and design-to-code tools, the boundary between design and development is becoming thinner. But does this really mean that designers need to learn how to code?

2026-09-10

Over the last few years, the relationship between design and development has changed much faster than we might have expected. For a long time, the process was fairly linear: the designer created the interface, prepared the prototype, and then handed everything over to the developer. From that point on, a second phase began, made up of interpretation, adaptation, and implementation.

Today, that separation is becoming much less clear. Design tools are moving closer to code, while development tools are becoming more accessible to people coming from a design background. Artificial intelligence is accelerating this process even further, allowing us to transform an interface into something functional without necessarily starting from a blank page and manually writing every line of code.

The numbers show how concrete this change already is. In its 2026 AI Report, Figma found that in just one year the percentage of designers also involved in development increased from 21% to 41%. During the same period, developers participating in design activities increased from 44% to 60%. This does not mean that the two professions have become the same thing, but it clearly shows that the traditional boundaries between them are becoming much more permeable.

The old handoff is becoming less important

For years, we talked about “handoff” as a very specific moment in the project. The designer completed the work, prepared specifications, components, measurements, and behaviours, and then handed everything over to the development team. In theory, it was an orderly transition. In practice, it was often the beginning of a long series of questions.

How should this component behave in an unexpected situation? What happens if the text is much longer? What is the error state? How should this screen adapt to an intermediate resolution? Is this value fixed or dynamic?

Many problems appeared precisely because design and development worked on the same product at different moments.

Today, that model is changing. Figma increasingly describes a circular process in which design and code are no longer two opposite ends of a line, but two environments between which work can continuously move. With Figma Make, for example, a designer can start from a frame, turn it into an interactive code-backed prototype, modify it, and continue iterating without completely leaving the design environment.

The change therefore does not concern tools alone. It changes the way we think about the entire process.

Design no longer necessarily needs to be “finished” before development begins.

So, does a designer need to learn how to code?

This is probably the most immediate question. And in my opinion, the answer is: it depends on what we mean by coding.

A UX/UI designer does not necessarily need to become a frontend developer. They do not have to know how to build a complex application, manage a backend, design software architecture, or master every JavaScript framework.

But understanding how code works is something different.

Having at least a basic understanding of HTML, CSS, responsive design, components, states, variables, data, and conditional logic can significantly improve the way we design an interface.

Not because designers need to replace developers, but because this knowledge allows us to design with greater awareness.

If we understand how responsive layouts really work, we are less likely to design dozens of static screens without considering what happens between one breakpoint and another. If we understand reusable components, we will probably pay more attention to design-system consistency. If we understand the concept of states, we are more likely to think about loading, error, empty, disabled, and success conditions.

In this sense, code does not necessarily become a new profession.

It becomes a new language worth understanding.

Understanding code is different from writing it

This distinction matters.

We can understand a language very well without becoming professional writers. In the same way, a designer can understand the fundamental logic of development without aiming to become a developer.

For a designer, knowing that a particular solution requires a disproportionate amount of technical work is useful. Understanding that a component can be reused instead of rebuilt every time is useful. Knowing that apparently simple behaviours can become much more complex when real data, permissions, errors, and edge cases are involved is useful.

This knowledge also changes the conversation with developers.

The dialogue stops being simply “this is the screen, build it like this” and becomes much closer to “this is the goal we want to achieve: what is the best way to build it?”.

That is a major difference.

Because a digital product is not a Figma file translated into code. It is the result of a series of shared decisions.

Tools are changing the designer’s role

The most obvious acceleration is coming from artificial intelligence.

Figma Make already allows users to generate working code through natural language, inspect it, modify it, and continue working on the product within the same environment. Figma is also experimenting with workflows in which a designer can work directly on a real codebase, make changes, and even reach the point of creating a pull request.

Only a few years ago, this scenario would have seemed much less realistic.

It means that a designer can begin to intervene directly on the product without necessarily knowing every technical detail of the implementation. But it also means that understanding what is happening becomes even more important.

Artificial intelligence lowers the technical barrier.

It does not eliminate the need to understand the result.

This is the same issue we have already seen with AI-generated interfaces: being able to produce something does not automatically mean being able to evaluate whether that something is correct.

The risk of the “designer who does everything”

There is, however, another risk we should avoid.

When tools make it possible to do more, it is easy to conclude that one person should therefore do everything.

Design, research, copywriting, development, testing, analytics, strategy, and perhaps product management as well.

But expanding our skills does not mean eliminating specialisation.

An experienced developer will continue to have knowledge that a designer does not acquire simply by using an AI code generator. In the same way, knowing how to use Figma does not automatically turn a developer into a UX designer.

Deep expertise still matters.

What is changing is that there is now a much wider area of overlap.

The designer can get closer to code. The developer can participate earlier in the design process. The product manager can prototype an idea without waiting for a dedicated phase.

This overlap can greatly improve the way teams work, provided that it does not turn into the belief that every profession is interchangeable.

From mockup to real product

One of the most interesting advantages of this evolution is the possibility of testing the real behaviour of an interface much earlier.

A static mockup can hide many problems.

A card looks perfect until the title takes up three lines instead of one. A table works until fifty columns appear. A form looks clear until we need to manage validation, errors, permissions, and missing data.

When the prototype gets closer to the real product, these problems emerge earlier.

And that can improve the quality of the design.

Code-backed tools allow designers to experiment with more realistic content, real interactions, and responsive behaviours without necessarily waiting for the final development phase. Figma itself describes this convergence as a continuous movement between canvas and code rather than a one-way process.

For the designer, this means being able to validate decisions more effectively.

Not only seeing how an interface looks.

But beginning to understand how it behaves.

What should a UX/UI designer actually learn?

If the goal is not to become developers, which technical skills are really the most useful?

In my opinion, some have a much greater impact than others:

• understanding the basic structure of HTML and CSS;
• knowing responsive design and breakpoints well;
• understanding components and properties;
• understanding interface states and behaviours;
• understanding the logic behind a design system;
• knowing how real data is used;
• understanding the main constraints of frontend development;
• understanding APIs, databases, and authentication at least conceptually;
• being able to read the general structure of code even without being able to write all of it;
• learning to use AI tools without treating generated code as a black box.

There is no need to learn everything at once.

But the better we understand the medium in which our designs will eventually be built, the better equipped we are to create realistic solutions.

Collaboration remains the real skill

Perhaps the most important question is not whether the designer should also become a developer.

The real question may be:

how well should a designer be able to work with development?

According to Figma’s 2026 report, 41% of respondents say that AI is already changing the way teams collaborate, compared with just 7% two years earlier. The most interesting transformation is therefore not simply an increase in individual productivity, but the way different skills begin to mix during the product-building process.

A designer who better understands development can communicate more effectively.

A developer who better understands design can identify experience problems earlier.

And when both work on the problem instead of simply defending their own file or their own code, the product improves.

Conclusions

Is the designer becoming a developer too? Partly yes, but probably not in the most literal sense of the question. The change does not necessarily involve turning every UX/UI designer into a frontend developer. Instead, it is making the boundary between what is designed and what is built much thinner. Tools are bringing canvas and code closer together, allowing designers to get much closer to the real product and developers to participate much earlier in design decisions.

This inevitably changes the skills that are useful in the profession. Understanding how a component works, what it means to design a truly responsive layout, how states are managed, or which constraints are introduced by real data is no longer marginal knowledge. These elements directly affect design quality. A designer does not necessarily need to know how to write all the code required to build a product, but understanding at least the logic behind how that product will be implemented can make them far more effective.

At the same time, it is important not to fall into the opposite misconception: if AI allows a designer to generate code, that does not mean that the developer’s expertise has become unnecessary. Tools can lower the entry barrier, automate parts of the work, and allow professionals to move into areas that were previously further away from their own discipline, but deep expertise continues to matter. A prototype generated in a few minutes and a robust, accessible, high-performing, maintainable product are still two very different things.

The real transformation, therefore, may have less to do with the rise of a professional who can do absolutely everything and much more to do with the disappearance of some rigid boundaries. The designer no longer simply hands a mockup to the developer. The developer does not necessarily wait for the design to be completed before becoming involved. Both can work earlier, together, on the same problem.

And this is probably the most interesting direction. Not designers becoming developers or developers becoming designers, but professionals who better understand each other’s work and can move more freely between design and implementation.

For a UX/UI designer, learning some code therefore makes sense. Not because they need to change profession, but because understanding the material with which their designs will eventually be built allows them to make better decisions.

The future of design may not be about choosing between canvas and code.

It may be about learning how to work effectively with both.