How to Use Claude Design to Redesign a Whole Website

A prescriptive, copy-paste guide for using Claude Design to redesign a whole website across mobile, standard web, and ultrawide breakpoints, then hand the bundle to Claude Code for implementation. Assumes you've already built and pinned a brand system with the brand-kit guide. Written for Claude Pro, Max, Team, and Enterprise subscribers.

1. Pre-work: site audit + redesign brief

Do this before opening Claude Design. Pasting a tight audit into your first prompt saves multiple regen rounds.

Page-type inventory

Your site has page types, not just pages. Group existing URLs by type — the redesign work happens at the type level, not URL-by-URL. Typical types for a product site:

• Marketing — home, pricing, discover/landing, blog index, blog post, legal
• Auth — sign in, sign up, forgot password, reset password
• Onboarding — welcome, setup steps, first-run wizard
• Dashboard — the logged-in home, list views, detail views
• Product surfaces — whatever is the core app UX (for Lesson Hollow: Today, Plan, Log, Progress, Rewards, Curriculums)
• Settings — account, billing, team
• Error surfaces — 404, 500, empty states, permission-denied

One redesign session per page type. Not per page.

The 5-item redesign brief

1. Brand system: pinned as "<Brand> v1.0" in Claude Design org settings.
2. Page types I'm redesigning: <list, grouped>
3. What's broken about the current design: 2–4 bullets, be specific
   (e.g. "dashboard cards carry too much chrome, burying the data",
         "pricing page hero fails on mobile — CTA falls below the fold",
         "the typographic hierarchy is invisible at 1920+").
4. Reference sites I'm pulling from: 3–5 URLs + screenshots, with one sentence
   on why each reference lands.
5. Breakpoint strategy: mobile-first 375 → standard 1440 → ultrawide 2560.
   (Or whatever your three anchor widths are. Don't pick more than 3.)

2. Web capture vs codebase import vs blank

Claude Design gives you three ways to seed a session — blank canvas, web capture, or pointing it at a codebase. Pick wrong and you'll fight the tool for the whole session.

Start blank

Use when you're doing a brand-first redesign and want to escape the current look entirely. This is the right mode when (a) the existing design is the problem and (b) your pinned brand system is the new anchor. Claude Design will draw solely from the brand system and your reference sites.

Web capture

Use when you want to port specific visual elements from an existing site (yours or someone else's) into the new design. Useful for pulling real product screenshots into mocks, or capturing a clever pattern from a reference site to adapt. Good supplement; bad anchor.

Codebase import

Use when you're doing a surface-level refresh of an existing codebase — keeping information architecture and component shapes, updating only the visual layer. Claude Design reads your repo, infers the component vocabulary, and applies new brand tokens to it.

Recommended path for a fresh brand-first redesign

1. Start a blank project.
2. Confirm your pinned brand system is attached.
3. Paste your 5-item redesign brief as the opening message.
4. Attach reference-site screenshots (not URLs — screenshots).
5. Then begin the breakpoint loop (sections 3–5 below).

3. Breakpoint 1: Mobile-first at 375px

Mobile first. Every page type gets a mobile layout before any desktop work happens. If it doesn't work at 375px, it doesn't work — widescreen is not a license to hide essential controls.

The batched mobile prompt

One prompt per page type. Bundle the four or five most important page types into a single session to share context.

Design the mobile-first layout for the <PAGE TYPE> page, at exactly 375px
viewport width.

Inputs:
  - Brand system: <Brand> v1.0 (already attached)
  - Content inventory for this page type: <paste the actual content — headings,
    body, CTAs, lists, form fields, data, exactly as they appear live today>
  - Primary user intent on mobile: <one sentence — what are they trying to do
    on their phone, specifically?>
  - Reference sites for this page type (mobile view): <2–3 URLs + screenshots>

Constraints:
  - Touch targets: every tappable element ≥ 44×44px.
  - Primary CTA visible above the fold — no exceptions for marketing pages.
  - No horizontal scrolling. Anywhere.
  - Typography: use the type scale from the brand system. Do not introduce
    new sizes.
  - Color: use semantic tokens from the brand system (bg, fg, primary, accent,
    muted, border, etc.). Do not introduce new colors.
  - Navigation: propose a single primary mobile nav pattern (sheet, bottom
    tabs, or hamburger) and apply it to every page type in this session.
    Don't mix patterns.

Output:
  - The layout at 375px wide, rendered realistically.
  - Annotations calling out: fold line, touch target zones, primary action.
  - The CSS variable names used (so I can verify token discipline).
  - A one-paragraph rationale: why these decisions were made for mobile
    specifically, not just "scaled down from desktop".

Mobile-specific tips

• Portrait rhythm. Mobile is a vertical scroll column. Use vertical rhythm (8px baseline, consistent section spacing) more aggressively than on desktop.
• Thumb zone. Primary actions belong within comfortable thumb reach — typically the middle-to-lower portion of the screen on modern phones — not pinned to the very top.
• One column. Multi-column layouts rarely work at 375px. Stack everything.
• Collapse defensively. Dense information (pricing comparison tables, data grids) should collapse into accordions or tab pickers, not shrink to unreadable text.

4. Breakpoint 2: Standard web at 1440px

Don't design the standard desktop version from scratch. Evolve the mobile one.

Adapt the mobile-first <PAGE TYPE> layout to 1440px viewport width.

Constraints:
  - Keep the mobile version's content hierarchy and primary action placement.
    The same things should still be the most important.
  - Introduce multi-column only where it reduces cognitive load, not to fill
    horizontal space.
  - Max content width for reading surfaces: 72ch (about 640–720px).
  - Navigation: the primary nav pattern from mobile evolves here — hamburgers
    become persistent top nav, bottom tabs become sidebars, sheets become
    inline panels.
  - Whitespace: at 1440, generous space around content panels. Don't fill
    every pixel.
  - Typography: use the display scale from the brand system — at 1440,
    hero headlines can step up to the display or h1 size that's too big for
    mobile.

Output:
  - The layout at 1440px.
  - A side-by-side comparison to the 375px version, showing what changes
    and what stays.
  - Annotations on the comparison: "this stays, this evolves, this only
    appears at desktop".

Standard-web-specific tips

• Content doesn't get wider, it gets more breathing room. Reading measure is capped at ~72ch on desktop; mobile is already constrained by the viewport. Desktop adds margin, not width.
• Introduce sidebars carefully. A sidebar at 1440 should earn its place — persistent nav, filters on a list view, or context panels. Not decoration.
• Hover matters now. On mobile, hover doesn't exist. On desktop, hover is a primary feedback channel. Claude Design needs explicit hover specs at this breakpoint — see section 6.

5. Breakpoint 3: Ultrawide at 2560px

This is the breakpoint most redesigns skip, and then users with 27"+ monitors see a 1200px content column floating in a sea of background. The ultrawide anchor is not "make everything bigger" — it's "use the space to make the product denser, faster, or more informative."

Adapt the <PAGE TYPE> layout to 2560px viewport width for a 27"+ monitor.

Goal: make the extra horizontal space earn its keep. Don't just widen
margins — add value.

Constraints:
  - Reading surfaces still cap at 72ch. Never stretch paragraphs to 200
    characters wide.
  - For product surfaces (dashboards, detail views, work views): introduce
    a persistent context panel on the right or left side that shows
    secondary information the mobile version hides. Examples:
      • Dashboard: main content + persistent activity feed on the right.
      • Detail view: main detail + related items / metadata sidebar.
      • Settings: nav rail on the left + main panel + preview on the right.
  - For marketing surfaces (home, pricing, blog): resist sidebars. Use
    the extra space for larger editorial imagery, multi-column grid
    sections, and more generous section rhythm. Don't invent a sidebar
    where the mobile version had none.
  - Typography scale: the display size used on mobile hero steps up again
    — verify contrast and weight at this size.
  - Density option: for data-heavy product surfaces, offer a "dense mode"
    that reduces padding and lets power users see more rows per screen.

Output:
  - The layout at 2560px.
  - A three-way comparison: 375 / 1440 / 2560, side by side.
  - A short paragraph for each comparison: "this is what the extra space
    buys you here."

Avoid:
  - Centered 1200px content column at 2560. That is a mobile design on a
    big screen.
  - Fixed edge-to-edge layouts that don't scale cleanly to even larger
    monitors (32", ultrawide 3440×1440).
  - Sidebars for sidebars' sake. Only add them when they add real value.

Ultrawide-specific tips

• Max-width is a brand decision. Some brands cap content at 1440 and let the background breathe (editorial, calm, premium). Others go edge-to-edge with multi-column density (productivity, technical, data-rich). Pick one posture and commit; don't mix.
• Persistent context panels. The killer feature of ultrawide is showing secondary information that mobile has to hide behind a tap. Use it.
• Information density is a preference. Offer users a compact/comfortable toggle rather than hardcoding one. Power users want dense; new users want spacious.
• Test at 3440×1440 (ultrawide) and 2560×1440 (27") separately. They are different aspect ratios. 3440 is way wider; a sidebar strategy that works at 2560 can feel empty at 3440.

6. Handling states

Pages in isolation aren't the job. Every page type has states you need mockups for:

• Interactive: default, hover, focus, active (pressed), disabled.
• Data: loaded, loading, empty (first-run, filtered-to-nothing), error.
• Permission: logged-in, logged-out, unauthorized, rate-limited.

For the <PAGE TYPE> layout at <BREAKPOINT>, show me all states.

Interactive states (show one example interactive element with all 5 states
visible side-by-side): default, hover, focus, active (pressed), disabled.

Data states (show the full page in each state):
  - Loaded (realistic data, a reasonable amount, not 2 items)
  - Loading (skeletons or spinners — pick the pattern and apply consistently)
  - Empty first-run (no data yet, with a clear path to create the first item)
  - Empty filtered (user's filter returned nothing — help them recover)
  - Error (something broke — show how it's communicated without panic)

Permission states (only where relevant):
  - Logged-out view of the page, if accessible.
  - Permission-denied view ("you don't have access to this").

Constraints:
  - Use the brand system's semantic state colors (destructive/success/warning/
    info + subtle variants) from the pinned system. Don't introduce new colors.
  - Empty states should include a specific, action-oriented next step. Not
    "Nothing here yet."
  - Loading states should preserve layout — use skeletons at 1440 and up,
    spinners on mobile.

Running this prompt once per page type at each breakpoint is the most usage-efficient way to get state coverage. Don't ask for one state at a time.

7. Handoff to Claude Code

Once your designs are stable, Claude Design packages everything into a handoff bundle — a zip containing the designs, the component specs, the CSS tokens, and a manifest Claude Code can read.

Prepare the bundle

1. In the design session, trigger the Claude Code handoff (exact control location may shift as the product evolves — look for "Handoff" or "Send to Claude Code").
2. Review whatever Claude packages — verify it includes: all breakpoints, all states, the pinned brand system's tokens, component specs, and any assets (icons, illustrations, images). Ask Claude to add anything missing before you download.
3. Add notes for the engineer (you or Claude Code): "preserve route structure, don't touch page content, replace chrome only" — whatever the scope rules are.
4. Download the bundle zip.

The single-instruction Claude Code prompt

Give Claude Code this exact instruction, attaching the bundle zip:

Attached is a Claude Design handoff bundle for a full redesign of this site.

Scope:
  - Replace visual chrome (layout, spacing, typography, color application,
    component appearance) per the bundle's designs.
  - Do NOT change content (headings, body copy, CTAs, form fields, error
    messages).
  - Do NOT change route structure, page files' export signatures, or
    data-fetching code.
  - Do NOT invent new components outside the bundle's spec.

Implementation plan (execute in this order, one commit per step, on a new
branch `design-handoff-vX`):

  1. Apply the brand system's tokens to globals.css (@theme block, :root,
     .dark). Preserve existing semantic token names if they match; add any
     new tokens the bundle introduces.
  2. Update components/ui/* to match the bundle's component specs. Use CVA
     variants. One commit per primitive.
  3. Walk page.tsx files one at a time. Apply the bundle's layout
     decisions, keeping content intact. One commit per page.
  4. Update layouts (header, footer, shells) last — they touch everything.
  5. Verify all states (hover/focus/loading/empty/error) match the bundle.
  6. Run the build, fix any token references that don't resolve, and open
     the site at 375, 1440, and 2560 viewport widths for visual verification.

For each step: show me the diff, wait for confirmation, then commit and
continue to the next step. Do not batch.

The "show me the diff, wait for confirmation" pattern is what keeps a full-site redesign from becoming a single gigantic commit you can't review. Ride the steps; don't let Claude Code run end-to-end unsupervised.

In practice, expect to re-anchor Claude Code between steps — especially between step 2 (primitives) and step 3 (pages). If it starts batching, interrupt and re-state the "one commit per step" rule.

8. Usage-economy tips

A full-site redesign can burn more usage than a brand kit. These habits make it sustainable:

• One session per page type, not per page. Dashboard-list and dashboard-detail are one session if they share a shell. Pricing and home are separate sessions because their logic differs.
• Three anchor breakpoints, not five. Mobile (375), standard (1440), ultrawide (2560). Fluid CSS handles the in-between.
• Design mobile first and evolve. Never design desktop first and squeeze down. The squeeze-down always produces worse mobile than mobile-first + evolve.
• Batch states into one prompt per breakpoint. The "Show all states" prompt above is structured this way deliberately. Don't ask for them one at a time.
• Inline comments and sliders over reprompts. Same rule as the brand-kit guide. If it's 70% there, ride it.
• "Keep X, change only Y." The phrase that constrains the model and saves usage.
• Export aggressively. After each page type's three breakpoints are stable, export. Don't lose work to a session crash.
• Skip Claude Design when the answer is clearly code. If a page is a pure form or a dense data table with no visual design decisions, go straight to Claude Code with a text brief. Claude Design is for visual decision-making, not form layout.
• Close the session when the handoff bundle is downloaded. Once work is exported, there's no reason to leave a live rendering session open — close it as a precaution against any background metering.

This guide's companion is How to Use Claude Design to Build a Brand Kit, which covers the brand-system work this guide assumes is already done.