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, 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. Include empty, loading and error states.
Use our design system.
The most useful detail: 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.
What happens after you hit Enter
Roughly four steps:
- It understands the request. It reads the repo, its routes and components, 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 coherent visual identity and tells you which decisions it made.
- 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 great canvas on the first try
The quality of the canvas depends a lot on the quality of the request. These are the things that matter most.
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 the states
Empty, loading, error and success. This is where most of the time savings are, because these are the screens nobody wants to draw by hand, and the ones most often forgotten until development.
4. Point to the brand
Your design system, colors, fonts, or simply the repository. Without a reference, it will create a coherent identity, but it won't be yours.
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.
For each main screen, also include the empty, loading, error and success states.
Use our design system. If there isn't one, propose a simple identity
and tell me which decisions you made.
Use real copy from the app's domain, no lorem ipsum.
The last 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.
- Vague requests give generic results. If you don't name screens, formats and states, you get a plausible but bland app.
- It reflects what it can read. If the repo is half-built or the screens are only in someone's head, describe them in the prompt.
- 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 own repository, 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, all the states. Then iterate.
Have you tried it yet? I'm curious how designers feel about starting from a generated first draft instead of a blank canvas.
Top comments (1)
The repo-reading tip is the good bit, and it cuts the other way for the case you open with. Reading routes finds the screens that already exist, so it's strongest on a redesign and weakest on the new feature nobody's built yet, which is exactly where the blank canvas hurts most.
The states line I'd push on a bit. Asking for empty, loading, error and success on every screen is cheap to type and expensive to read back. I ran twelve screens that way and got close to fifty artboards, and maybe a third described situations the product can't reach: an empty list that onboarding always seeds, an error state for a call that can't fail on the client. Finding those took longer than drawing the real ones would have. Asking for states per flow instead of per screen worked better, plus a line asking which ones are reachable and why.
The other joint is "if there isn't one, propose a simple identity". It will, and slightly differently each run. Since the canvas is editable you end up fixing the mismatch on the artboard rather than upstream, so the drift settles into the frames. Fine for one canvas. Less fine by the third.
On your last question, starting from a generated draft beats a blank one for me, but only once the system exists. Before that it just moves the blank page one step later.