claude.ai/design alternatives for Claude Code users

Anthropic announced that claude.ai/design will shut down on December 14, 2026. If you built design mockups there before handing work to Claude Code, you now need a new workflow. This post covers what actually replaces it, and where each option fits.

What claude.ai/design did

claude.ai/design let you sketch a UI in plain language and get a rendered mockup back from Claude. The loop was: describe what you want, see a live preview, iterate until the layout was right, then carry that context into your code. It sat between the "I have an idea" moment and the "start implementation" moment.

For Claude Code users specifically, it was a way to produce a visual spec before the coding agent ran. Without it, the typical alternative is a text description in a CLAUDE.md or a story ticket, neither of which gives the agent a pixel-level reference to work from. After December 14, that visual bridge in Anthropic's own toolchain is gone.

Alternatives, by workflow fit

Standalone AI design generators: v0.dev, Lovable, Bolt

v0.dev (Vercel), Lovable, and Bolt generate full UI components from a description and export real frontend code. They are good at producing something that looks finished fast. Where they fall short for Claude Code users: the generated code is the output, not the spec. You get a component tree, not a design artefact you carry into your own codebase. If your project has a design system, existing component library, or strong opinions about the stack, the generated code usually needs heavy modification.

These tools are worth using when you want to explore a design direction quickly or when the generated code IS the project. They are not a good fit when you want to say "here is what the UI should look like - now build it in my existing repo."

Cursor Design Mode

Cursor's Design Mode (shipped in mid-2026) lets you inspect and annotate a live running UI, then describe changes directly in the editor. It bridges visual feedback and code edits within Cursor itself. If you are already on Cursor, this covers a meaningful part of what claude.ai/design did: getting from "I can see the UI" to "change this."

The limitation is that Cursor Design Mode operates on a running application you can open in a browser. It does not produce a design spec before the build starts - it operates post-render. That is a different point in the workflow: feedback on what exists rather than design before implementation starts. See the full defract vs Cursor comparison for how the two tools sit in the broader pipeline.

Figma (with AI plugins)

Figma remains the baseline for teams that take design seriously. Several plugins (Anima, Builder.io, Figma's own AI features) generate components or export code. The strength: Figma produces a durable spec, has version history, and is the format most teams already use to communicate design intent across roles.

The drawback for solo builders or small teams using Claude Code: Figma is a separate tool with its own cost and context-switch overhead. Getting a Figma frame into a Claude Code agent's context means exporting images, writing descriptions, or connecting an MCP server. It works, but it adds friction.

Excalidraw and whiteboard tools

For rough wireframing before coding, Excalidraw (free, open source) is fast and low-ceremony. You sketch, export a PNG, attach it to a task description. No AI, but also no cost and no lock-in. If the point of claude.ai/design for you was "communicate layout intent to an agent," a well-labeled Excalidraw export does the same job for many use cases.

This is the honest answer for a lot of use cases: the design step does not need to be AI-powered. It needs to produce a clear enough reference that the coding agent can implement it accurately.

The real gap: design inside the coding workflow

What the alternatives above have in common is that they all sit outside the coding workflow. You design in one tool, then carry the output (an image, a description, a component) into Claude Code by hand.

That handoff is where things break. The agent starts implementation without full context on the design decisions. When the layout does not match what you intended, you have to re-explain. The design artefact and the task context drift apart as the build progresses.

The workflow that avoids this is one where the design stage is gated: implementation does not start until the design has been reviewed and approved, and the approved spec travels with the agent's context when it begins. claude.ai/design did not enforce that gate - it was a separate tool you used before firing up Claude Code, not something wired into the pipeline. But the pattern it was pointing toward - design as a discrete, reviewable stage before code - is worth preserving.

If you want design inside the Claude Code lifecycle

defract is the only tool in the Claude Code ecosystem that builds this gate in. The design stage sits between story and architecture: Claude renders a mockup from the spec, you annotate or approve it, and implementation only starts with the approved design locked to the task. The agent gets a visual reference at the start of the build, not just a text description.

With claude.ai/design gone after December 14, this is the only remaining visual design surface inside a Claude Code workflow. If your answer to the handoff problem is "I want design to be part of the pipeline, not something I manage separately," that is what defract's design stage does. You can download it free and run it against your own Claude subscription with no account required.