The Complete Claude Guide
← Back to topic
Chapter 12 · DESKTOP

Claude Design: from idea to canvas

Design pairs a conversation with an editable canvas. Current documentation supports starting in chat, Artifacts, Claude Code or the standalone experience. Design is in beta and depends on plan and permissions.

Verified against source on 2026-09-30

Video

Design one screen, not an entire product

By the end, you will create a fictional course-interest screen, revise it and inspect an export. Outputs are illustrations, not a recording or a design created in your account.

Claude Design joins conversation and canvas: describe the purpose, receive a design, then revise through chat, local comments or direct editing. Documentation checked on September 30, 2026 describes Design as a paid-plan Artifact template in beta as well as the existing standalone path. Organizational availability may depend on administrators.

Start with one screen and fictional content rather than “build a perfect website”. This lets you test understanding, readability and behavior without connecting a real system.

Supply context and controlling content

Open a Design template through Output or Artifacts if available, or the Design route in your account. If an organizational design system exists, check that it is appropriate. Do not connect a work repository simply for practice.

Design a fictional internal-course interest screen.
Audience: employees who want to understand the course before expressing interest.
Content: title “Introduction to AI tools”, three units, date not yet set.
Order: title, short explanation, learning content, date status, interest button.
Label the button “I'm interested”, not “Registration approved”.
Prototype only: no sending, database, connections or personal-data collection.
Design mobile first, then desktop, with readable text and clear keyboard focus.

Check content before colors. The screen should not invent a date or promise confirmation. Ask what the button does; a prototype does not need to store real information.

Edit through chat and comments

Use chat for structure:

Move “Date not yet set” before the button so it is known before expressing interest.
Keep the course title unchanged. Do not add a date.

Use a canvas comment for a local edit if supported:

Increase the button's tap area. Keep its label unchanged.

Check that the comment was received and acted on. Current documentation warns that local comments may not appear or be read. If nothing changes, paste the request into chat. Silence is not proof of an update.

Direct editing can move, resize and align elements. Recheck narrow layouts after moving anything; desktop alignment can harm mobile presentation.

Inspect visuals and behavior

Read the design at phone and desktop widths. Look for clipped content, conflicting text direction and headings covering controls. Date status must be clear without relying on a footnote.

Review basic accessibility: contrast, text size, focus order and button labels.
List changes and anything that still needs manual checking.

This is a review request, not accessibility certification. Tab through controls, inspect focus and click the button. If an unrequested live form opens, stop and remove it.

Try an alternative without losing the original
Preserve the current design and identify where it is saved.
Create an alternative layout with course content in cards.
Keep every fact and the date status. Publish neither version.

Current documentation says Design lacks a complete version history. Do not assume Undo can restore every old state. Verify that the earlier copy exists or export before a large revision.

Compare understanding, date visibility, button clarity and phone readability. Do not choose solely by what looks modern.

Export and hand off to code

Choose the offered export by purpose: PDF for viewing, standalone HTML for browser checking, ZIP for working materials or another available format. Handoff to Claude Code starts development; it does not prove the design is a working product.

Prepare a development handoff list: components, controlling content,
button behavior, mobile states and unresolved decisions.
Do not add a backend or publication.

Open the export and check content and layout. If developing further, verify connections, persistence and tests separately. Sharing needs an appropriate audience and permission; this exercise stays private.

Practice at three levels

Easy: no invented facts

Create one screen. Success: title and three units remain intact, without invented dates or registration approval.

Intermediate: a local edit

Increase the button through comment or chat. Success: visible change with no unintended label edit.

Challenging: alternative and export

Preserve an alternative, compare and open an export. Success: the earlier design survives and the exported appearance and supported behavior are checked.

Troubleshooting

No Design: check plan, beta and administrator controls. A design brief is useful, but do not claim it is an actual canvas.

Comment disappeared: use chat and inspect again.

Attractive but incomplete: restore controlling content. Do not hide the unset date to simplify appearance.

Export differs: inspect format limits. PDF is not an interactive prototype.

Many iterations: documentation describes shared usage limits. Make focused requests rather than regenerating everything.

A design is ready when someone understands what is offered and what remains undecided, not merely when the canvas looks good.

Mechanism animation (illustration)

Filmed demo · Video is added in the media phase

Recap

Comprehension check

Which control suits a change in a specific area?

Recap

Sources and further reading

← Previous Back to topic Next →