Figma Became Irrelevant in My 2026 Workflow

If you are planning a new website, you may have been told that it has to be designed in Figma before development begins. AI will often give you the same answer. First create the sitemap and wireframes, then produce pixel-perfect desktop and mobile designs in Figma, get everything approved, and only then let somebody build it.

That is a perfectly valid process. It is not a requirement for every website.

I used Figma on almost every custom website project for years. I built the pages, components, variables, prototypes, mobile versions, and design guidelines. I still know how to do all of that, and I still use Figma when a project genuinely needs it. I just stopped treating the Figma file as proof that proper web design happened.

Your website needs a design process. It does not automatically need a separate Figma production phase.

Do you need Figma before website development?

The short answer is no. You need to make design decisions before they become expensive to change, but those decisions do not have to live in Figma.

A professional still has to work out the content hierarchy, page structure, navigation, visual direction, typography, colors, reusable elements, responsive behavior, interactions, and the actions you want visitors to take. Skipping Figma does not mean skipping any of that.

The distinction matters because a business owner is not buying a design file for its own sake. You are buying a website that should communicate clearly, work properly on different screens, fit the business, and be manageable after launch. A Figma file can help get there. It is not the result.

What Figma is supposed to solve

Figma is very good at giving people a shared place to discuss a design before development. Moving a section, testing another layout, or changing the visual direction is usually cheaper there than after a large application has been built and tested.

That becomes valuable when several designers, developers, product managers, and client stakeholders need to agree on the same interface. A component library also gives a large product team a reference for every button, form state, modal, card, and interaction.

The problem starts when the process is copied onto a project that does not have those coordination needs. A five-page business website, designed and developed by the same person, is not a large software platform. The Figma handoff may simply be me handing the work back to myself.

That does not make the file useless. It means the time needs to justify itself. If nobody will maintain the Figma system after launch, no separate development team needs it, and every page will be recreated immediately in HTML, CSS, or WordPress, I think it is reasonable to ask what the extra production layer is buying.

The design phase still exists

The important distinction is that I did not merge design and development into one milestone. The design phase still happens first. What changed is the medium I use to do it.

Most of my work now happens in Cursor (opens in a new tab). During the design milestone, I create standalone HTML and CSS prototypes that can be reviewed in a browser. They show the layout, visual system, content hierarchy, responsive behavior, and important interactions, but they are not the finished production website.

I present and revise those prototypes just as I would present and revise Figma screens. Only after the design is approved does the development milestone begin. That is when I build the CMS structure, reusable templates, dynamic content, forms, integrations, performance work, accessibility details, and the other parts that turn an approved design into a functioning website.

Some of the prototype HTML and CSS may be reusable, but I do not treat that as permission to quietly develop the website while the client thinks they are still approving the design. The approval point remains clear.

I used to spend a serious amount of time making Figma files properly: pixel-perfect pages, variables, design tokens, components, variants, mobile screens, and clickable prototypes. Then development started, and I had to express most of that logic again in the browser and CMS. Moving the design phase into HTML and CSS reduces that translation without removing the phase itself.

Designing with AI still involves a lot of design

Designing the prototype in HTML and CSS does not mean I give an AI one prompt, accept whatever appears, and send the client an invoice.

The generated direction is normally a starting point. I change the spacing, typography, hierarchy, colors, content, responsive behavior, and small visual details. I reject plenty of suggestions. Sometimes I select one element in Cursor’s browser and ask the agent to change it. Sometimes the change is so small that explaining it to AI would be ridiculous, so I edit it by hand.

AI cannot see the finished interface I have in my head. It can help me reach it faster, but I still need a UI I can inspect and control. I still need to decide whether the page feels clear, whether the most important message is visible, and whether the design supports what the business wants visitors to do.

This is important if you are hiring a professional. Changing the design medium should reduce duplicated production work, not remove the thinking or approval milestone. If somebody skips Figma and also cannot explain how the design will be planned, reviewed, and approved before development, that is not efficiency. They may simply be skipping design.

What a client should still receive

A Figma file is one possible deliverable. The actual design work should be visible whether that file exists or not.

A clear structure

The pages, navigation, content hierarchy, and user journeys should be deliberate rather than generated at random.

A consistent visual system

Typography, colors, spacing, buttons, forms, and reusable sections still need rules, even if those rules live in CSS rather than Figma variables.

A proper review process

You should be able to see the direction, give feedback, and approve important decisions before the entire site is treated as finished.

Real responsive testing

The HTML and CSS design prototype should be checked on representative mobile and desktop sizes before approval.

If a professional can show you those things in a browser-based design prototype, you are not receiving less design because the project did not begin with a `.fig` file. You are still reviewing and approving a design before the production build starts.

When I still use Figma

I still use Figma when the project has an actual need for it.

Large platforms and complex product interfaces are the obvious examples. If there are multiple designers, separate development teams, product managers, and many stakeholders, they need a shared reference. A long-lived design system with hundreds of components and states can save far more time than it costs.

I also use it when the client requires a Figma deliverable for a real reason, or when I am designing something that another team will develop. That is a genuine handoff. The file has a job after I finish it.

On those projects, I would not remove Figma just to prove that a newer workflow exists. That would replace one rigid rule with another. My point is much narrower: a client preference, an AI checklist, or “this is how websites are made” is not enough by itself. The process should match the project.

I did try to connect Figma to the new workflow

I tried using Figma through the Model Context Protocol (MCP), which lets an AI agent access information and tools from another application. I hoped that would preserve the design environment while removing some of the manual translation into development.

The results were not good enough for me. Figma can also export HTML through different tools, but exporting markup is not the same as carrying the reasoning, responsive decisions, component behavior, and prototype logic into the system where I build the finished website.

I would still be maintaining the design in one place and making the real implementation work in another. For a larger team, that separation can be useful. For my workflow, it brought back the exact duplication I was trying to remove.

The Cursor browser needed one small fix

Creating the HTML and CSS design prototype in Cursor’s browser works well because I can select an element and refer the agent directly to it. One part was strangely annoying: the agent could change the HTML, CSS, or JavaScript, while the browser continued showing the old version until I refreshed it manually.

I looked for a setting and did not find one. Many developers already use Vite, Browsersync, or another live-reload setup, so they may never have this problem. I wanted the native Cursor browser to update without adding another system, so I built a small extension around Cursor’s file watcher.

Unofficial Cursor extension

Cursor Browser Auto Reload

Keep Cursor’s built-in Browser synced with the HTML, CSS, and JavaScript you are editing. It detects saves from you or an AI agent, batches rapid changes, and reloads the open preview automatically without a separate live-reload server.

GitHub (opens in a new tab)Marketplace (opens in a new tab)Open VSX (opens in a new tab)

The extension watches for those file changes and reloads the browser when it is open. It is a small thing, but it closes the loop: select something, change it, and see the new result without manually refreshing and finding the same place again. It is also listed on my Open Source page.

What to ask when Figma appears in a website proposal

If you are hiring a freelancer, a small team, or an agency and Figma is included in the website design process, I would not ask them to remove it automatically. I would ask why it is there.

The answer may be that Figma is absolutely worth it. It may also reveal that the provider follows the same process on every project regardless of size. You are not trying to catch them out. You are trying to understand what you are paying for.

This is similar to evaluating a web developer without being technical. You do not need to inspect their CSS or argue about design software. You need them to explain the process, the deliverables, the trade-offs, and how each stage helps your project.

The process should justify the file

Figma can be useful, but “every professional website needs Figma first” is no longer a sensible rule.

For the small and medium business websites I usually build, the design milestone now happens in pen.dev (opens in a new tab) or as an HTML and CSS prototype in Cursor. The client reviews and approves that design first. Development remains a separate milestone afterwards.

This avoids recreating a complete Figma system that nobody will maintain, while preserving the sequence that protects both the client and the project: design, approval, then development.

For a large platform, a complex UI, or a real designer-to-developer handoff, I would still use Figma. The tool did not become irrelevant everywhere. It became irrelevant as the automatic starting point in my own workflow.

Frequently asked questions