It has transformed the way designers collaborate, build interface systems, create components and communicate ideas before development begins.
Figma is an excellent tool.
But knowing how to use Figma does not automatically make someone a web designer.
That distinction may sound provocative, especially today, when the boundaries between UI design, UX design, product design and web design have become increasingly blurred.
Yet the distinction matters.
Because a website is not a collection of screens.
It is a system running inside a browser.
And browsers do not behave like design canvases.
The problem is not Figma
The problem begins when proficiency with a tool is confused with understanding the medium.
The same mistake has happened before.
Years ago, visual web editors promised that designers could create websites without needing to understand what was happening underneath. Dreamweaver became symbolic of an era in which the visual representation of a website often felt more important than the structure that made it work.
Modern tools are far more sophisticated.
Figma is not Dreamweaver.
But the temptation is surprisingly similar: to believe that if something works inside the design environment, the problem has already been solved.
It has not.
A Figma file can represent a responsive system.
A browser has to execute one.
And those are very different things.
The web is not made of fixed screens
Design tools encourage us to think in frames.
Desktop.
Tablet.
Mobile.
Perhaps a few intermediate sizes.
But the Web does not move from one frame to another.
It exists continuously between them.
A real visitor may arrive on a browser window that is 917 pixels wide.
Or 1,284.
Or 713.
They may zoom the page.
They may increase the default font size.
They may use a device with an unusual aspect ratio.
Their browser may render a font slightly differently.
Their operating system may change scrollbar behaviour.
Their content may be longer than expected.
The web designer therefore has to think beyond individual breakpoints.
The real question is not:
What should this page look like at 1440px and 375px?
It is:
What rules should govern the layout at every width between them?
That is a different way of thinking.
A web designer designs behaviour, not screenshots
A screenshot describes a state.
A website must describe behaviour.
What happens when the title is twice as long?
What happens when a card contains three lines of text instead of one?
What happens when an image has a different aspect ratio?
What happens when the navigation no longer fits on one line?
What happens when the browser window is resized?
What happens before a webfont finishes loading?
What happens if JavaScript fails?
What happens when content is generated dynamically from a CMS?
What happens when an editor adds something the designer never anticipated?
These are not edge cases.
They are the normal operating conditions of the Web.
This is why a web designer needs to understand concepts such as flexible layouts, wrapping, intrinsic sizing, spacing systems, responsive typography and content flow.
Not necessarily at the level of a frontend engineer.
But deeply enough to understand the consequences of the design decisions being made.
A web designer does not simply design how a page looks.
A web designer designs the rules that determine what happens when the page changes.
Responsive design is not three layouts
One of the most persistent misunderstandings in interface design is that responsive design means creating desktop, tablet and mobile versions of the same page.
That is useful for communication.
But technically, responsive design is not about those three states.
It is about everything that happens between them.
A developer does not build a desktop page, a tablet page and a mobile page.
They build one system whose behaviour changes according to available space.
That system may use CSS Grid, Flexbox, relative units, min-width, max-width, clamp(), wrapping rules, container queries or breakpoint logic.
A designer does not need to write all of that code personally.
But if the designer does not understand what those mechanisms are trying to achieve, the design risks becoming a series of static instructions rather than a coherent responsive system.
That is the difference between designing screens and designing for the Web.
The browser always has the final word
There is another fundamental difference between a design file and a website.
The browser is an active environment.
Resources load at different times.
Fonts can arrive late.
Images may be compressed, lazy-loaded or replaced.
Network conditions vary.
JavaScript can block rendering.
Third-party services can slow down a page.
Content can shift while the page loads.
A perfectly stable composition in Figma can become a poor user experience once it reaches production.
This is where performance becomes part of web design.
A large hero image is not only a visual decision.
It is also a loading decision.
A custom font is not only a branding decision.
It can affect rendering, layout stability and perceived performance.
An animation is not only an aesthetic decision.
It can affect accessibility, responsiveness and processing cost.
The moment a design enters the browser, visual choices become technical choices.
That does not mean designers must become developers.
It means web designers need to understand that their work has consequences beyond appearance.
Accessibility makes the distinction even clearer
The same principle applies to accessibility.
A button may look perfect in a mockup.
But is it keyboard accessible?
Does it have a visible focus state?
Does the color contrast remain sufficient across all states?
Does the interface still make sense when text is enlarged?
What happens when someone uses a screen reader?
Does the structure follow a meaningful semantic hierarchy?
None of these questions can be fully answered by looking at a static design.
Accessibility is partly visual, but it is also behavioural and structural.
A web designer needs to understand that distinction.
Again, this does not require every designer to write semantic HTML by hand.
But it does require awareness of the environment in which the design will eventually live.
Figma is a representation of the product
This is the crucial distinction.
Figma represents the website.
The browser is the website.
That does not reduce Figma’s value.
Architects use drawings.
Industrial designers use prototypes.
Engineers use simulations.
Representations are essential because they allow ideas to be explored before they are built.
The problem only appears when the representation is mistaken for the finished medium.
A design system in Figma can describe components, spacing, typography and layout relationships extremely well.
But until those rules are translated into HTML, CSS, JavaScript, CMS templates and real content, they remain a model of the system rather than the system itself.
You do not need to be a developer to be a web designer
This is where the argument can easily go too far.
Saying that web designers need to understand the Web does not mean that every web designer should also be a frontend developer.
Those are different disciplines.
A designer can be an excellent web designer without writing production JavaScript or building WordPress themes from scratch.
But a web designer should understand the basic mechanics of the medium.
They should understand why content wraps.
Why layouts break.
Why some animations are expensive.
Why responsive typography matters.
Why accessibility cannot be added at the end.
Why a CMS changes the way components should be designed.
Why real content is rarely as tidy as placeholder content.
Why performance is partly determined before development even begins.
Understanding these principles creates better collaboration with developers.
More importantly, it creates better websites.
The real test begins after the mockup
At an agency, there is a useful reality check.
The project does not end when the design is approved.
Eventually, the website goes live.
And once it does, nobody cares how perfectly aligned the original Figma file was.
If the navigation breaks at an intermediate width, the website has a problem.
If the page shifts while loading, the website has a problem.
If a CMS editor enters a longer title and destroys the layout, the website has a problem.
If a beautifully designed interaction cannot be used with a keyboard, the website has a problem.
If the homepage requires eight megabytes of assets to reproduce the visual concept, the website has a problem.
“In Figma it worked” is not an answer.
Because Figma was never the final environment.
The browser was.
A better definition of web design
Perhaps the problem is that we have gradually reduced web design to interface design.
The two disciplines overlap heavily, but they are not identical.
Interface design asks:
How should this interface look and feel?
Web design must also ask:
How should this interface behave in the conditions of the Web?
That includes:
- visual hierarchy;
- typography;
- layout;
- interaction;
- responsive behaviour;
- accessibility;
- performance;
- content variability;
- browser behaviour;
- implementation constraints.
The web designer exists somewhere between visual design and technical reality.
That is what makes the discipline interesting.
And difficult.
Figma should make us better web designers, not replace web thinking
None of this is an argument for abandoning Figma.
Quite the opposite.
Figma is extraordinarily useful when it is used for what it does best: exploring ideas, building design systems, collaborating, testing visual relationships and communicating intent.
But tools should support professional understanding, not replace it.
Knowing every Figma shortcut does not make someone a web designer.
Neither does knowing every CSS property.
Web design is not defined by a particular application or programming language.
It is defined by understanding the medium well enough to make good decisions within it.
Figma is part of that process.
The browser is where those decisions are tested.
And ultimately, the browser always wins.
A web designer does not design pages. A web designer designs systems that have to survive the real Web.
