Why I Stopped Opening Figma

Sep 2026 · 7 min read

I open a Figma file a team shared with me for review. One screen, three frames sitting side by side, desktop, tablet, mobile, the same content poured three times into three different widths, and every one of them slightly out of sync with the other two. A button got renamed on desktop and nobody told mobile. The tablet frame has a card that simply does not exist anywhere else. Somebody spent days on this, and not one pixel of it will survive the trip to production.

That picture is the whole reason I barely open Figma anymore. And before anyone says it, no, this is not a guy who never learned the tool and is making peace with it. I built the libraries.

I was the libraries guy

A big chunk of my career went into design systems, the big ones. At CEMEX we lived in Sketch, and I spent a long time building and maintaining the symbol libraries that kept a lot of designers drawing the same button the same way. Later, at BigCommerce, I owned BigDesign, and that meant the whole package: the React component library, the pattern library, and yes, the Figma library that mirrored all of it for the designers.

So I know the tool from the inside, the variants, the auto layout, the endless negotiation of keeping a drawing of a component in step with the actual component. And the more mature the system got, the more obvious one thing became to me.

The point where code got cheaper than drawing

Once your design system lives in code, a real component and pattern library with a base setup on top of it, with the basic constructs already solved, the full page types, the list page, the detail page, the settings page with its forms, something flips. And I mean any code. In our case it happened to be React, but React is just one flavor of front end, and the same thing holds for Vue, for Web Components, for SwiftUI or Jetpack Compose on native. The framework is not the sledgehammer here, the library is. Composing a new screen out of those real pieces in code is faster than composing a picture of those pieces in Figma. Not a little faster. And what you get at the end is not a picture, it is the thing.

Is there a catch? Sure, you have to know how to code. That was the honest limit for a long time, and it is why the drawing step kept its place for everyone who did not. But for those of us who did, the Figma frame had turned into a detour, a step you did because the process expected it, not because it moved the product any closer to shipping.

FigCommerce

At BigCommerce I tried to close that gap for everybody else too. I built a Figma plugin, which we jokingly named FigCommerce, that took the structure of your Figma file and turned it into React code. The idea was to automate the boring half of prototyping: read every screen in the file, map the frames to our components and page types, and hand you back a high-definition base for an app, so the only thing left to do was code the logic and wire the interactions, this button goes to that screen, this form posts there.

It worked, within limits. The plugin was only ever as good as the Figma file it read, which meant the designer had to build the frames with a discipline that most real files, bless them, do not have. Still, it taught me where this was going. The drawing was becoming an input to code, and once the drawing is only an input, you start asking why you need it at all.

Then AI showed up

The final nail in the coffin was AI. At first there were tools like v0 doing more or less what FigCommerce did, prompt or picture in, UI out. But that early AI prototyping scene was built almost entirely on shadcn. If your company had its own library, and any company big enough to care about design has its own library, the AI struggled to use it. You got a very pretty shadcn app that looked like everybody else's shadcn app, and then you spent the afternoon translating it back into your real components.

That gap just vanished as Claude got better and better. Today you can plainly develop directly against a custom design system, even a poorly documented one, and oh boy do I know some poorly documented ones, because Claude will go dig into the node_modules folder by itself and figure out how the components actually work: their props, their structure, the events they fire, the composition patterns the authors had in mind and never wrote down. The documentation stopped being the bottleneck. The code is the documentation, and now there is something that reads it for you.

What about responsive?

One of the things I always disliked about Figma is that responsiveness was never baked into its architecture. It is a canvas of fixed frames, so a screen that needs to work on a phone and a wide monitor means designing it twice, or three times, or going down a rabbit hole of constraints and auto layout tricks to fake a behavior that the browser gives you for free. That opening scene with the three frames? That is not a lazy team. That is the tool working as designed.

With the AI approach that whole chore is gone. You think in one format, desktop or mobile, whichever is the primary one for what you are building, and you let the AI and your component library deal with the other screen sizes. The library already knows how its grid collapses and how its navigation turns into a drawer, and the AI knows how to lean on it. You design one thing, and it is right everywhere, because it is the same code everywhere.

What Figma is still good for

I do not think the canvas is useless. For showing how a user moves from one place to another, the big boxes and arrows of a flow, laying a few screens next to each other is still a lovely way to think out loud with a team. A whiteboard with better typography.

Then again, do you need Figma for that? Not really. Excalidraw will do boxes and arrows beautifully, with that hand-drawn look that tells everybody in the room it is a sketch and not a promise, and Google Drawings is sitting right there in the Drive your whole company already uses. Both of them, by the way, for free. Paying for a seat of a professional design tool to draw arrows between rectangles is a hard thing to justify once the rectangles stop being the deliverable.

But after that, the jump is straight to a high-definition prototype, and that prototype can even be wired to live data. The deliverable has changed. It is no longer the clickable Figma prototype with its hotspots and its fake scroll. It is a working artifact, and depending on the job it takes one of these shapes:

• A web artifact, a real web app anyone can open from a link.
• An Electron app, when the idea wants to live on the desktop.
• An Expo app, when it has to be held in a hand and tested on an actual phone.
• A humble Chrome extension, when you need to intervene in something that is already live, or hook into real data, so the prototype sits nested inside the real product, in the exact context where it would eventually live.

That last one is my secret favorite. Nothing ends a design debate faster than showing the new thing running inside the real page, with the real header and the real customer data around it, instead of floating on a gray canvas.

What you leave on the table

So that is the nail in the coffin for Figma and its relatives, at least for me. Not because the tool got worse, it did not, but because the medium it was simulating became cheaper to use directly than to simulate. I spent years building the bridge between the drawing and the code, the libraries, the plugin, the handoff rituals, and the AI walked straight across the river without it.

If you resist this new way of working, I understand, the canvas is comfortable and it is where a lot of us learned the craft. But you are leaving so much on the table. You are giving up designing against real constraints, real screen sizes, and real data, in exchange for a picture that someone else will have to interpret. In my experience, the moment you see your first idea running on an actual phone in the afternoon you had it, you do not really want to go back to drawing it.

I wrote about the engineering side of this same shift in The Front End Is Back, and about the more personal side in Getting the Whole Self Back.