Every new product or feature starts the same way. Before anyone can discuss the idea, someone has to draw the obvious: login, home, a list, a detail page, a profile. Then the states nobody draws in the first version: empty, loading, error, success.
It's necessary work, but it's not where design adds the most value. The valuable part comes after: flow, hierarchy, interactions and product decisions.
A recent Claude Code feature goes straight at that bottleneck. You can ask, in plain language, for every screen of your app, and you get back a design canvas where each screen is a live, editable artboard. Not a screenshot. Not a static mockup.
This post covers what it is, what happens under the hood, how to ask for it in an existing app and in one that doesn't exist yet, and the tips that make the difference between a generic result and a useful first draft.
What it is
The result is an infinite canvas with live artboards. Each screen becomes a frame on the canvas, at real device size, organized by flow, with titles and notes.
It isn't limited to mobile apps. The same canvas works for web pages, landing pages, and even social media posts.
The canvas is published as a private page on claude.ai. You see the screens appear as they're drawn, and you decide whether and when to share it with your team.
How to ask
There's no special command or syntax. You just ask. It works anywhere Claude Code runs: the terminal, the desktop app or the web.
A good first request looks like this:
Create a design canvas with every screen of the app in this repo:
onboarding, login, home, calendar, detail and profile.
Mobile 390×844. Use our design system.
For each flow, list the empty, loading and error states the user
can actually reach, and draw only those.
Where the canvas gets its information from depends on whether the app already exists.
In an existing app: let it read the repo
Run it inside your repository. Claude Code reads the code to find the screens that actually exist (routes, pages, components), so the canvas reflects your real app instead of a generic template.
This makes it strongest on redesigns and on adding screens to something that's already there. Reading routes finds what exists. It can't find a feature nobody has built yet.
In a new project: the spec replaces the repo
For something that doesn't exist yet, the source changes. Instead of code, you give it a description. I've used it this way on projects started from zero, and the order that worked for me was:
- Define the foundations first: colors, typography, spacing, the base CSS or design tokens.
- Describe each screen: what it's for, what it shows, the main actions, how it connects to the next one.
- Ask for the canvas before any UI code exists, and review it.
- Only after approving the canvas, build the real screens, using the canvas as the reference.
That way the canvas becomes the agreement on what will be built, and the implementation follows it, instead of the other way around. It works for new projects and existing ones. What changes is only where the information comes from.
What happens after you hit Enter
Roughly four steps:
- It understands the request. It reads the repo, its routes and components (or your description, in a new project) to learn which screens exist and how they connect.
- It picks the look. If your account or organization has a default design system, it uses it. If not, it defines a visual identity and tells you which decisions it made. More on why you shouldn't rely on that below.
- It draws screen by screen. Each artboard is an independent HTML component at real device size, which is why everything stays editable.
- It hands you the link. A private canvas on claude.ai, where you watch the screens appear and decide what to do next.
The part that won me over: everything is editable
This is what separates it from "AI generated a picture of an app".
Because every screen is a live component, you can:
- Tweak it directly. Change copy, colors and spacing in a properties panel, and see the screen update right away.
- Comment on a screen. Leave a comment like "make the card bigger and swap the icon", and Claude makes the change on that screen.
- Keep iterating in conversation. Ask for a new variation, a new state or a new flow without starting over.
- Take it further. Link screens into a clickable prototype, or share the canvas with your team for feedback.
Five tips for a useful canvas
The quality of the canvas depends a lot on the quality of the request. These are the things that matter most. Two of them were sharpened by a reader's comment on the first version of this post, from someone who had clearly pushed the feature hard.
1. Name the screens and flows
"Design my app" gets you something generic. Name each screen and group them into flows: onboarding (welcome, sign up, permissions), auth (login, password reset), main (home, list, detail, profile, settings).
2. Set the format
Say what you're designing for: mobile at 390×844, web at 1440px, a landing page, a social post. Otherwise you'll get a reasonable guess, which may not be your guess.
3. Ask for states per flow, and only the reachable ones
States are where a lot of the time savings are, because they're the screens nobody wants to draw by hand. But asking for empty, loading, error and success on every screen is cheap to type and expensive to read back. Twelve screens can easily turn into close to fifty artboards, and many of them will describe situations your product can't reach: an empty list that onboarding always fills, an error state for something that can't fail on the client. Finding and discarding those can take longer than drawing the real ones.
What works better is asking for states per flow, plus one line asking which states are reachable and why. You get fewer artboards, and each one is there for a reason.
4. Pin the visual identity before you start
If there's no design system, Claude will propose one, and it will be slightly different every time you run it. Because the canvas is editable, it's tempting to fix the mismatch right on the artboard. Do that a few times and the inconsistencies settle into the frames: fine for one canvas, a problem by the third.
Fix it upstream instead. Define your tokens (colors, type, spacing) or point to your design system before generating anything, and when something looks off, change the source and regenerate rather than patching individual artboards. In a new project, this is step 1 of the order above.
5. Iterate in small steps
"On the login screen, change the CTA to 'Continue with email'" works much better than asking it to redo everything. Small, specific requests keep what's already good and change only what you asked for.
A full prompt you can copy
Putting the tips together, this is a prompt I'd use as a starting point:
Create a design canvas with every screen of the app in this repo.
Flows:
- Onboarding: welcome, sign up, permissions
- Auth: login, password reset
- Main: home, list, detail, profile, settings
Mobile 390×844, one artboard per screen, grouped by flow with a title for each.
States: for each flow, list the empty, loading, error and success states
the user can actually reach, and why. Draw only those.
Use our design system. If there isn't one, stop and propose the tokens
(colors, typography, spacing) for my approval before drawing any screen.
Use real copy from the app's domain, no lorem ipsum.
For a new project, replace the first line with a short description of each screen, and paste your design tokens instead of "use our design system".
The "real copy" line matters more than it looks. Real copy makes layout problems visible early: long names, button labels that don't fit, empty states that need an explanation.
What it doesn't do
It's worth being clear about the limits, so expectations stay realistic:
- It doesn't replace designers. It gives you a starting point. Decisions about hierarchy, interaction, accessibility and the product itself are still human work, and they're the ones that matter most.
- It needs a system to start from. In an existing app, that's the code and the design system. In a new one, it's your description and your tokens. Without either, it just moves the blank page one step later.
- Vague requests give generic results. If you don't name screens, formats and flows, you get a plausible but bland app.
- An improvised identity drifts. Without pinned tokens, each run looks a little different. Fix the source, not the frames.
- Review it like any first draft. Check contrast, touch target sizes and edge cases before treating anything as final.
Who it's for
- Designers skip the rough draft and start at refinement: hierarchy, interactions and product calls.
- Engineers see the screen before coding, and can discuss layout and states with something concrete instead of a description in a ticket.
- Product managers validate a flow early, bringing real screens into the conversation before the sprint starts.
The way I see it: designers keep making the calls. Claude delivers the starting point.
Wrapping up
The time between "we have an idea" and "we have screens to discuss" used to be measured in days. With an editable canvas generated from your repository, or from a clear description when there's no code yet, it can be minutes. And what you get is something you can keep working on, not a picture you have to redraw.
If you try it, start small: one flow, one format, pinned tokens, only the reachable states. Then iterate.
Have you tried it yet? I'm curious whether you've used it more on existing apps or on new ones.
