Figma's shift from hub to spoke

A year ago, all my design work started in Figma. Today, none of it does. It starts in code. Pretty quickly, when I did open Figma I found myself using it in much the same way I'd use Safari Developer Tools, for diagnostics. It gave me a way to break components apart at a granular level and feed precise component specs back to my coding agents. That shift wasn't gradual. Figma became something I opened later, or not at all.

What Figma was

Figma's pitch, for most of its history, was that it's the place where your team designs together. That positioning made it more than a design tool. It was the place where the whole product team converged. Engineers reviewed specs there. PMs left comments on flows. Researchers annotated prototypes. Design exploration, component libraries, handoff, stakeholder review. All of it flowed through Figma.

The competition shifted

Then the ground moved. In 2017, Netflix's Reed Hastings famously said that their biggest competitor wasn't HBO or Amazon. It was sleep. The point was that Netflix had already won the streaming wars and was really fighting for a share of people's finite attention. Figma is experiencing the inverse of this. They used to compete with Sketch and Adobe XD for designers' attention. They won that fight. But while they were winning, the nature of the competition changed underneath them.

Figma's real competitor now isn't another design tool. It's the collapsing distance between intent and implementation. Google Stitch generates high-fidelity UI from a text prompt, for free. Bolt, Lovable, and a dozen others can spit out a working app from a description. Tools like Claude Code skip the design phase entirely, going from idea to working component without a visual tool in between. The floor for "good enough" has risen dramatically, and it keeps rising. Half of these tools probably won't exist in a year (Google has killed enough of its own products to fill a cemetery), but it doesn't matter, because new ones will replace them overnight. When any number of free or cheap tools can produce usable interfaces, Figma is no longer competing for which design tool you use. It's competing for whether you use a design tool at all.

This is why the feature releases don't land the way they used to. Figma is shipping at a rapid pace, but each release feels like it's solving problems within a workflow that's already obsolete. Figma Make generates a shareable prototype, not shippable software. The output lives inside Figma's ecosystem and stays there. Figma Sites publishes webpages, but deploying from code was already trivial. The features aren't bad. They're just aimed at a version of the design workflow that fewer teams run every month.

My own workflow is a good example. I used to build and maintain design systems primarily in Figma, with code as the output. Now I work code-first. When I do open Figma, it's to create a visual reference for a specific component that's precise enough to hand to Claude Code as context. Figma went from being the canvas where I did my thinking to being one input in a code-centric process.

The friction problem

Figma has always been high-friction at every boundary. That was an acceptable tradeoff when it was the best option. It's not anymore. Moving work into Figma is friction. Working inside Figma, where every interaction is mediated by a visual canvas rather than code, is inherently slower than the alternative. And moving work back out of Figma is more friction still. Bridge tools like Code Connect exist, but they're clunky and brittle. They don't adapt well to a system that's changing rapidly, which is exactly what happens when AI-assisted development lets you iterate on components in minutes instead of days.

That changes the math for every team that pairs engineers with designers. If I'm shipping UI with Claude Code and my design partner pulls something into Figma to refine it, whatever comes back needs to justify the round-trip. If I'm going to jump through the hoops of environment translation, spec discrepancies, and ongoing sync overhead, the payoff needs to be worth it.

This connects to an older argument that the design community thought we had won: the fight for a seat at the table. Designers earned that seat by demonstrating that design adds quantifiable value to products. Better usability, higher conversion, clearer information architecture. But that argument was built on the assumption that design work required a designer. The skills that justified the seat are increasingly things AI can do well enough to ship. Design still matters, but the work that earned designers the seat no longer requires a human to be doing it.

The roles themselves are blurring. An engineer who's prompting instead of writing code and a designer who's offloading UI iterations to Claude are doing increasingly similar work. The boundaries between "design tool" and "development tool" are dissolving. Designers who tie their value to Figma fluency rather than design judgment risk becoming a bottleneck in a workflow that's optimizing for speed.

Working software replaced the shared canvas

Figma won as a design tool, but its bigger win was as a collaboration layer. It was the place where engineering, product, design, and research could all look at the same thing and react to it. That was valuable when the alternative was passing Sketch files around, syncing assets through Dropbox, and building click-through prototypes in Keynote that went stale the moment someone changed a screen. Figma made design work visible and accessible to the whole team.

But the best way to get feedback from a PM or an engineer was never a static set of screens you dragged around by hand. It was always going to be something that feels real, something they can tap through, something that behaves the way the shipped product will behave. Figma was the best available approximation of that. Now it's not.

The week Claude Code launched, I used it to build a prototype app that doubles as a living design system, with theme tokens, a typed component library, visual testing through Storybook, and AI-powered interactions all running inside it. The motivation was partly to stress-test a new tool and partly to route around the friction I'd been living with in Figma.

When I want stakeholder feedback, I hand them something that works, not something that represents how it might work. When I want to test a component variant, I change the code and see it running immediately. The design system isn't a Figma file that gets translated to code. It's code that we explore visually. I wrote more about the Figma plugin I built alongside it in a separate post.

The same pattern applies beyond design systems. When the artifact a designer ships is already a working prototype, engineering handoffs disappear and feedback becomes interaction with the thing rather than commentary on a frame of it.

Figma's response, and why it's the wrong one

At Config 2025, Figma doubled its product count from four to eight. Figma Make, Sites, Draw, Buzz. This is hardly a new playbook. Establish yourself in one market, then expand into adjacent ones to grow the userbase and justify enterprise pricing. It's exactly what Adobe did with Creative Cloud. But none of these products address why Figma is losing its position at the center of product development. They're building outward into adjacent markets while their position as the place teams converge erodes underneath them.

Figma Make deserves a closer look because it represents Figma's biggest bet on AI. To their credit, they're investing in it. You can now bring your design system into Make as a package and connect a backend to a prototype. But it still runs in its own walled garden, disconnected from the broader development toolchain. You can't install arbitrary packages, can't use your own component library the way you'd use it in an actual codebase, can't access the ecosystem of tools that make AI-assisted development powerful. I tried to meet Figma halfway. I built a design system, packaged it for Make, and pointed it at a component I'd already designed. The output wasn't close. And the harder question is: why would I wait for Figma to slowly close these gaps when I can already do all of this, better, somewhere else?

Figma used to have an uncanny ability to ship exactly what I needed next. Auto layout, variables, and dev mode each landed right when the pain was sharpest. Now I look at the releases and I can't tell who they're building for. Figma's plugin API makes the priorities even clearer. There's a strong case for building bespoke tooling inside Figma, plugins that solve real workflow problems and make the editor worth staying in. But the API is buggy, the documentation is outdated, and none of it has meaningfully improved in years. This isn't a resource problem. A single small team could iterate on this in a matter of weeks. The plugin API could expose the hooks needed to build real AI tooling on top of your own models. Instead, AI features are locked inside Figma Make. It's hard not to read that as a choice: a walled garden over a platform.

There's a precedent for this. In the mid-1990s, Apple had won the personal computer revolution and spent a decade responding to a shifting market by expanding into everything: dozens of Mac SKUs, the Newton, printers, a gaming console, experimental web tools. Each product had a reasonable pitch. None of them addressed why Apple was losing. When Steve Jobs returned in 1997, he cut 70% of the product line in his first year and focused the company on four products. The iMac shipped a year later.

The parallel is hard to miss. A company that dominated its category, watched the ground shift, and responded by launching adjacent products instead of defending the core. But the analogy breaks in an important place. Jobs inherited a company whose core market was still growing. People were buying more computers every year. Apple's problem was execution, not demand. Figma's position is harder. The market for design tools that mediate between intent and implementation is in the early phase of a contraction that will likely accelerate. Apple needed a better product. It's not clear that a better Figma solves the same problem.

What's left when the hub isn't needed

There's some ambivalence in this. Figma was how I thought out loud for years. It gave me a way to externalize ideas and make them legible to the people I worked with. That mattered. But the tools that let me do that now are different, and I'd rather follow the work than the tool.

None of this means Figma disappears. But building your workflow on the assumption it stays at the center is a bet against the direction everything is moving.

Figma's Config keynote this spring argued that design and code are converging, and that "Figma wants to be by your side every step of the way," taking designs "from idea all the way to production." They're right that the line is artificial. But they're dissolving it with Figma Make, another artificial boundary, while code-first workflows are dissolving it for real. Design and code are converging, just not on Figma's canvas. The canvas as a metaphor will linger, but increasingly you'll see designers working directly in a browser, a simulator, or even the command line. The right answer for Figma was always to build on the strength of its foundation and make the hub indispensable, not to ship more products. The window for that may have already closed.