For a long time, the pitch for AI tools was essentially about text. Write faster. Summarise better. Answer questions. Useful — but not transformative if you build software for a living. That changed when Anthropic shipped Claude Design. This is a post about what Claude Design is, how I’ve used it on real projects, and why it has quietly become one of the most valuable things in my workflow.
What is Claude Design?
Claude Design is a standalone design tool from Anthropic Labs, available at claude.ai/design. It’s currently in Research Preview — that badge matters, and I’ll come back to it. It is not a tab inside the regular Claude chat interface; it’s a dedicated environment with its own canvas, file system, and project types.
The tool handles visual design — not by generating a static image and leaving you to guess, but by building interactive HTML prototypes, full page layouts, and working component code from natural language prompts. You describe what you want in plain English, you get a working design back rendered live on the canvas, and then you iterate on it the same way you’d continue any conversation.
The key word is conversational. There is no switching between a design tool and a chat window — the chat panel sits on the left, the canvas on the right, and the conversation is the design tool. You say “make the navigation a bottom tab bar instead of a sidebar” and it happens. You say “now show me this in dark mode” and you get dark mode. The iteration loop that used to involve Figma files, stakeholder pings, and a lot of patient redrawing is now just typing.
You access Claude Design directly at claude.ai/design — no separate signup if you already have a Claude account.
How I've used it so far
I’ve run Claude Design through two real projects and the results have been concrete enough that I want to document them properly.
Redesigning chaitanya.dev
This site needed a ground-up design pass. The previous version had accumulated decisions rather than made them — fonts that were fine, a layout that worked, colours that didn’t clash. Nothing actively wrong; nothing cohesive either.
Claude Design starts new projects with a context-gathering step. Before building, it asked me to confirm the scope, visual direction, and what outputs I wanted. I asked for several distinct visual directions — and what came back was a canvas showing multiple complete design options side by side, each a full page in a different visual language. I could pan across the canvas and compare them directly. I chose the Swiss-influenced direction — a consulting rebrand with a strong typographic system, bold serif display type, and a clean editorial hierarchy.
From there the conversation became specific: a responsive mobile pass, dark mode, and a blog post template. Claude built each as its own artboard on the shared canvas. A verifier agent ran in the background after each major change, catching rendering issues before I saw them.
What usually takes half a day — opening Figma, building frames, exporting, second-guessing — took a focused conversation. More importantly, the decisions were made quickly enough that I stayed in the same frame of mind I’d started in. Design sessions that drag tend to drift. The site looks the way I originally intended because I didn’t have time to talk myself out of it.
Parikrama UI design
Parikrama — the Hindu temples atlas I wrote about last week — has more interface surface area than a blog. I opened with a loose prompt: I want to build a new idea to life. I have a dream of having all information about Hindu temples in one place. I want to visualise this. Ideally on a map type with filters applied. Give your creative mind a challenge.
Claude Design’s first move wasn’t to build — it asked questions. About scope (everything from village shrines to global landmarks), primary use (pilgrims planning visits), key filters (deity, architectural style, pilgrimage circuit, era, festivals), and what visual direction to explore. I answered in a batch. Then it built three complete design directions on a single canvas: Pradakshina (dark starfield, temples as luminous points), Parikrama (warm parchment cartography, the route builder as the hero), and Kalachakra (editorial dark mode, a timeline scrubber as the hero interaction). Each showed a hero map view, a filter panel, a temple detail card, and its signature interaction.
I chose Parikrama and asked for real geodata, 100+ temples, haversine distances for the route builder, a festivals-this-month filter mode, and a mobile map-to-list gesture — all in one message. Claude delivered a working Leaflet map with a sepia tile filter to match the parchment aesthetic, temples spanning India, Nepal and SE Asia, a route builder with live km and day estimates, festival mode keyed to Kartik month, and a segmented control that swaps between map and list on mobile. The verifier agent caught a duplicate-map initialisation bug and fixed it automatically.
The yatra planner at the bottom — a strip of saved temples with distances between stops — was right on the first attempt. The only change I made was asking for the distance figures to be muted, not prominent.
What’s next: M.I.R.A.
M.I.R.A. is a personal AI assistant I’m building as a Progressive Web App. I started a Claude Design project for it as a palette exploration, then uploaded the architecture document — a full technical spec — directly into the project using the Import function. Claude read it, identified ten screens that the architecture specified but the design didn’t yet have (authentication flow, push notification permission, draft editor, offline state, settings, and more), and built them out systematically, adding new phone frames to the existing canvas.
The canvas for MIRA now covers the full app — the core screens, the onboarding and permissions flow, asynchronous states, notifications and edge cases, and settings. Claude Design is where this project went from a visual sketch to something that actually reflects the architecture. I’ll document the full design process in a follow-up post once the build is underway.
What Claude Design can actually do
It helps to be specific about the capabilities, because the range is wider than “make a mockup.”
- Project types. When you create a new project, you choose between Prototype (Wireframe or High Fidelity), Slide Deck, or Other. Wireframe mode produces greyscale structural layouts; High Fidelity produces polished, coloured designs. Slide deck produces presentation-ready slide sets. Other is a free canvas for anything — animated showcases, component libraries, experiments.
- Multiple design directions on a canvas. For any sufficiently open brief, Claude Design’s first response will often be a multi-direction canvas: complete design options laid out side by side so you can compare them visually before committing. This is the step that most compresses design time — you’re choosing between real, rendered options rather than imagining them.
- Questions before building. For complex projects, Claude Design will ask clarifying questions about scope, use case and visual direction before generating anything. Answering these upfront leads to a significantly better first pass.
- HTML pages and interactive prototypes. The outputs are rendered HTML/CSS/JavaScript files, not image exports or Figma frames. They run in the browser, respond to interaction, and can be dropped directly into a repository or hosted anywhere. Interactions — hover states, transitions, live filter updates, map pan/zoom — are real web behaviour, not simulated.
- Design canvas. All the files in a project live on a shared canvas. You can place multiple HTML artboards side by side, compare light and dark versions, and view transitions between screens by navigating between them in the live renders.
- Component and file structure. Projects have a Design Files panel with Folders, Pages (HTML files) and Components (JSX files). The verifier agent automatically checks files after major changes and flags or fixes rendering issues.
- Import. You can drop images, documents, reference screenshots and Figma links directly into a project. Claude will use them as context for what it builds. This is how I fed the MIRA architecture spec into the project.
- Export. The Share menu lets you export the project as PPTX, PDF, or a handoff package for Claude Code. The Claude Code handoff produces a dev-ready folder with specs and structure — you can take it straight to a build.
- Design system. You can set up a shared design system for your organisation, which any project can draw from. This keeps type, colour and spacing consistent across designs.
- Iterative refinement. You keep the context of the entire conversation, so every iteration builds on what came before. You’re not starting from scratch each time. You’re steering.
Prompts worth trying
If you haven’t used Claude Design yet, these prompts will show you what it can do quickly:
- For multiple directions: “I want to design a mobile app for tracking personal finances. Give me three distinct visual directions on a canvas — minimal/clean, data-forward/dense, and warm/personal. Show a home screen and a transactions list for each.”
- For a working map prototype: “Build a working map view for a restaurant discovery app. Use Leaflet with a clean tile style. Show restaurant pins, a filter bar for cuisine type, and a detail card that slides up when you tap a pin.”
- For a dashboard: “Design a mobile-first personal finance dashboard. Dark mode, clean and minimal. Show account balance, recent transactions and a spending breakdown chart. The chart should be a donut, not a bar.”
- For importing context: upload a wireframe screenshot or architecture document and say: “This is the architecture for the app. What screens are missing from a design perspective? Build the ones that aren’t covered yet.”
- For iteration: “Take the previous design and replace the sidebar navigation with a bottom tab bar. Add a persistent search bar fixed at the top.”
The pattern that works best: give Claude Design enough context upfront — scope, use case, feel — let it ask questions if the brief is complex, and plan to spend at least two or three turns in the conversation. The first response gives you a canvas to react to; the second and third turns are where it becomes your design.
Why this matters for developers who aren't designers
I’m not a designer. I can make reasonable decisions about layout and colour, I understand enough about visual hierarchy to know when something is off, but I don’t have Figma muscle memory and I can’t sketch a component hierarchy with the fluency of someone who trained for it.
For years, that meant my personal projects had a ceiling: either they looked like developer-built things (functional, not beautiful) or I spent longer on the design layer than I had budget for. Claude Design changes that calculation. It doesn’t make me a designer — the taste and the decisions are still mine. What it gives me is a design conversation partner that can take an idea and show me what it could look like, fast enough that I don’t lose momentum, and precise enough that I can respond to what I see rather than to what I imagined.
Claude Design is in Research Preview, which means it will change — and that’s worth naming. Some behaviours are rough at the edges, some outputs need iteration, and the feature set will evolve. But the core loop — describe, compare directions, choose, iterate, ship HTML — already works well enough to build real things with. Both this site and Parikrama are evidence of that.
A lot of software that should exist doesn’t, because building it to a standard you’re proud of is hard when you’re one person doing every role. The tools that close the distance between idea and execution are worth documenting. Claude Design is one of them.
— Chaitanya
Working on something like this? Let's trade notes.
I'm always up for a good conversation about enterprise architecture, agentic AI and the AI-native SDLC. Subscribe for field notes, or write if a specific problem is on your mind.