Figma Is Still Useful. It's Just Not Where I Start Anymore.

A month ago, Figma's stock dropped 7% in a single day. Anthropic had just launched Claude Design, and the design community reacted the way it usually does when a new tool threatens the tools we've built careers around: loudly.

I watched the debate from a strange angle. Not because I had a contrarian take, but because the shift people were arguing about had already started changing how I work.

After a stretch away from the industry — time that gave me more distance from the day-to-day than I expected — I came back to UX and found the landscape had moved. The tools had shifted. The conversation had shifted. Designers were debating Claude, Figma, and AI workflows the way they used to debate handoff tools and design systems.

I came back mid-shift. And the distance turned out to be useful.

The old workflow

For most of my career, the rhythm was predictable:

Discovery research. Stakeholder interviews. Wireframes in Figma. Component libraries. High-fidelity mockups. Review rounds. Handoff notes. Repeat.

Figma was the center of gravity. And for a long time, that made sense. I could move from rough concept to polished deliverable in a way that felt professional and efficient.

But when I looked honestly at where my time went, the picture was less clean.

A lot of my week was not spent thinking through the product. It was spent producing the artifacts around the product: building several wireframe options so stakeholders could compare directions, polishing mockups before the idea had been validated, writing handoff documentation for patterns that already existed.

That work wasn't useless. The artifacts mattered — but producing them was eating time that should have gone to thinking.

And a lot of "design work" was really assembly work.

Where the shift started

When I came back to UX, I started testing the new tools on actual work, not just reading about them.

Claude Design became the biggest shift. The workflow feels different from traditional design tools because it starts with conversation. I can describe a direction in plain language, get a first version back, refine it inline, and explore alternatives quickly. If I want to take the idea somewhere else, I can say that and get another version in minutes.

The practical difference is how many directions I can actually afford to try.

In Figma, I might explore two or three before committing, because each direction takes time to build. With Claude Design, I can explore eight or ten. That does not replace the thinking. It gives me more raw material to think with.

For client work, that changes the conversation. Walking into a review with several interactive prototypes is different from walking in with static screens. Stakeholders respond differently when they can see and feel multiple options.

What I did not expect was how much of this happens directly in the conversation.

Claude's live artifacts — interactive HTML files that render right inside the chat — changed how I think about early-stage exploration. I can ask Claude to generate six different directions for an onboarding flow, laid out side by side in a single file, and react to them immediately. I can ask for sliders to adjust animation timing, or controls to toggle density and spacing, and copy the parameters that feel right. There is no export step. No separate tool to open. The design exploration and the conversation are the same thing.

This reframed something I hadn't considered: HTML is actually a more expressive design medium than I gave it credit for. Claude Design is itself built on HTML. Engineers on the Claude Code team have started replacing Markdown with HTML for the same reason — it is visual, interactive, and much easier to react to than a static document. A UX designer who understands that HTML is not just a developer's format has a real head start. You do not have to write it. You just have to know what to ask for.

Claude is not the only tool worth watching.

Google Stitch has become harder to ignore. It started as a simple text-to-UI experiment: interesting, useful for quick concepts, but limited. As of mid-2026, it has added multi-screen generation, real-time streaming, and multiplayer editing — all still free. The pace of improvement has been meaningful. The limitation is still important: Stitch does not read your design system the way a code-aware workflow can, so the output can feel generic without careful prompting. But the trajectory is worth watching.

Paper.design is interesting for a different reason. It treats design and code as the same artifact. Every element renders as HTML and CSS, which removes some of the translation that usually happens between design and development. It also has an MCP server, which means AI agents can read from and write to your design files directly. It is still early and rough, but the direction is compelling.

Mobbin has not changed as much, but my use of it has. When I'm generating more options faster, I need better references. Mobbin helps me check whether a pattern exists in the wild and understand how other products have solved a similar problem before I commit to a direction.

The point is not to use all of them. The point is to notice what the best ones have in common: they shrink the gap between having an idea and being able to react to it.

What stays

This is not a story about replacing Figma.

Research stays. Faster visual output does not help if you do not understand the user, the workflow, or the business constraint.

Systems thinking stays. Someone still has to understand how a component fits into the broader product, how one flow connects to another, and where the edge cases break the happy path.

Judgment stays. The hardest part of design has never been putting things on the screen. It is deciding what belongs there. AI is good at producing options. It is not good at knowing which option is right for this user, in this context, with these constraints.

And so does Figma, especially in mature enterprise environments.

If an organization has spent years building a design system in Figma — tokens, variants, auto-layout structures, governed libraries, engineering references — that system has real value. It is not just a file. It is infrastructure.

For those teams, Figma is still the production environment. It supports review, governance, handoff, and consistency in ways that matter.

What changed for me is simpler:

Figma is no longer always the first tool I open.

It is where I go when I know what I'm building.

What I stopped doing

I stopped overbuilding throwaway directions.

I used to create three polished wireframe options in Figma, knowing two would be discarded. The work existed mostly to make the final direction feel chosen. Now I explore those directions earlier and faster, then bring the strongest one into Figma when it deserves more precision.

I stopped making early concepts pixel-perfect.

Early mockups need to communicate the idea well enough to get useful feedback. They do not need to look final. I used to over-invest in fidelity because the tool made that feel natural. Now I try to match the fidelity to the stage of the work.

I stopped writing documentation that does not add value.

If a pattern already exists in the design system, and a developer can inspect the relevant values directly, another layer of explanation creates more process than it removes. Some documentation still matters. Redundant documentation does not.

I am not spending less time on design.

I am spending less time on the parts that were never really design.

What this means for product teams

If you lead a product team, look at where your designers actually spend their time.

Not where the process says the time goes. Where it really goes.

If most of it is spent producing throwaway artifacts, polishing early concepts, or documenting patterns that already exist, the workflow probably has room to change.

The tool is not the skill. A strong designer will become more effective with these tools, not less. But the leverage only works if the underlying craft is strong: research, systems thinking, product judgment, and taste.

For teams with mature Figma systems, the shift is not about abandoning that investment. It is about using Figma more precisely.

Less first draft. More final artifact. Less exploration. More governance. Less blank canvas. More source of truth.

That is not a demotion. It is clarity.

For teams without a mature design system, this is the moment to build one. AI-assisted design tools are only as good as the structure they can draw from. If your codebase and design system are inconsistent, the output will be inconsistent too.

Figma is not going away.

But its role is changing.

The design workflow is changing. The design skill is not. The teams that move fastest are the ones with designers who understand both — who know when to reach for a new tool and when to rely on the craft underneath it. That combination is what produces better products, clearer decisions, and faster alignment. The tools are just how you get there.