Launch price: $49 one-time for all 38 specialists. Get it →
Claude prompts
9 Claude Prompts for Website, App and UI Design
Landing pages, homepage copy, UI critiques, design systems, dashboards and screenshot to code.
Updated October 20269 promptsFree to copy, no signup
These prompts help you plan, write, critique and build websites and app interfaces with Claude. The common thread is specificity: a named design direction, a defined audience and action, and complete states and accessibility requirements, which is what moves the output away from the generic look of most AI-generated pages.
How to use these prompts
Decide the audience and the one action you want visitors to take before you run any of these prompts.
Attach screenshots or paste existing code when improving something, so Claude critiques what you actually have.
Name a design direction or real sites you admire rather than adjectives like modern or clean.
Check the result at phone width and with a keyboard before shipping it.
Use it when: Get a landing page that commits to one specific visual direction instead of the generic AI template look, with real copy and responsive, accessible code.
Prompt 01
Build a landing page for [PRODUCT] aimed at [AUDIENCE]. The one action I want visitors to take: [PRIMARY CTA, E.G. START A FREE TRIAL].
Design direction: commit to one specific style and carry it through every section. Use [PICK ONE, E.G. EDITORIAL MAGAZINE / SWISS GRID / WARM HANDMADE / BRUTALIST / RETRO TERMINAL / QUIET LUXURY], or propose two directions that suit the brand and let me choose. Define a palette, a type pairing with real character, a spacing rhythm and one signature visual element, and use them consistently. Avoid the default centred gradient hero with three identical feature cards, because it makes a page instantly forgettable.
Sections: hero with a specific headline and subhead, the problem, how it works in 3 steps, benefits written as outcomes, social proof [PASTE REAL TESTIMONIALS OR LOGOS, OR SAY "PLACEHOLDERS"], pricing or offer, an FAQ that answers real objections, and a final CTA.
Copy: concrete, specific to this product, plain language. Where I haven't given you a number, quote or logo, use a clearly marked placeholder.
Build: [ONE HTML FILE WITH CSS / REACT AND TAILWIND / YOUR STACK]. Mobile first and solid down to 320px, semantic HTML, WCAG AA contrast, visible focus states, and respect prefers-reduced-motion. End with a few lines explaining the design choices.
Why it works: Committing to one named design direction with a defined palette, type pairing and signature element is what moves the output away from the generic template look. Marked placeholders for proof keep the page honest, and the accessibility and responsive requirements make the code usable rather than a mockup.
Tip: Name one or two real sites whose feel you like; a concrete reference steers the design far better than words like "modern" or "clean".
2. Homepage website copy prompt
Claude chat
Use it when: Write homepage copy from your audience and offer: headline options, every section in order, and CTAs that match what visitors want.
Prompt 02
Write homepage copy for my website.
<business>
What we offer: [PRODUCT OR SERVICE]
Who it's for: [A SPECIFIC AUDIENCE, E.G. INDEPENDENT PHYSIOTHERAPY CLINICS WITH 2 TO 10 STAFF]
Their problem: [IN THEIR OWN WORDS IF POSSIBLE]
Why us over the alternatives: [WHAT'S GENUINELY DIFFERENT]
Proof we have: [RESULTS, CUSTOMERS, REVIEWS, CREDENTIALS]
Main action: [E.G. BOOK A DEMO]
Tone: [E.G. CALM AND EXPERT, PLAYFUL, NO-NONSENSE]
</business>
If anything above is missing or vague, ask me about it first, one question at a time.
Then write:
1. Five headline options, each from a different angle (outcome, problem, audience call-out, contrast with the alternative, specificity), each with a subhead. Recommend one and say why.
2. The full page in order: hero, problem, solution, how it works, benefits as outcomes, proof, objections and FAQ, final CTA. Label each section.
3. Button text for the main action and for a lower-commitment secondary action.
Write for a busy person scanning on a phone: short sentences, concrete nouns, the customer's words rather than industry jargon. Use only the proof I've given you, and mark spots where more proof would help with [PROOF NEEDED].
Why it works: Specific audience, problem and differentiation inputs give Claude material to write concrete copy instead of interchangeable claims. Five headlines from different angles let you compare approaches, and restricting proof to what you supplied keeps the page free of invented numbers.
Tip: Paste a handful of customer reviews or sales call notes; the strongest headlines usually reuse the exact words customers use.
3. Prompt to critique and improve a UI
Claude or Claude Code
Use it when: Get a specific critique of an existing screen (hierarchy, spacing, contrast, states) followed by exact changes and updated code.
Prompt 03
Critique this UI, then tell me exactly how to improve it.
[ATTACH A SCREENSHOT AND/OR PASTE THE HTML, CSS OR COMPONENT CODE]
Context: this screen is for [WHO] to [MAIN TASK]. The most important action is [ACTION]. Constraints: [E.G. KEEP OUR BRAND COLOURS AND COMPONENT LIBRARY].
Part 1, critique. Assess:
- Visual hierarchy: is the most important thing the most prominent? Where does the eye land first, second and third?
- Layout and spacing: alignment, a consistent spacing scale, grouping of related items, density.
- Typography: sizes, weights, line length, consistency of the scale.
- Colour and contrast: WCAG AA for text and controls, and whether meaning relies on colour alone.
- States: hover, focus, disabled, loading, empty, error, and very long content.
- Usability: labels, affordances, touch target size, behaviour on mobile.
For each issue, say what's wrong, why it matters to the user, and how severe it is.
Part 2, changes. Give a prioritised list of concrete changes with exact values (e.g. "heading to 28px at weight 600, card padding from 32px to 20px"), then updated code for the top changes. Work within my existing design system and keep its overall style.
Why it works: Separating critique from changes makes Claude diagnose before prescribing, so each fix ties to a named problem. Asking for exact values such as sizes and padding, within your existing design system, produces changes you can implement directly rather than vague advice like 'improve spacing'.
Tip: Include a screenshot at phone width too; many hierarchy problems only show up on a narrow screen.
4. App development prompt from idea to MVP
Claude or Claude Code
Use it when: Turn an app idea into a scoped MVP with a stack, data model and step-by-step build plan before any code is written.
Prompt 04
I want to build a web app: [YOUR IDEA IN A FEW SENTENCES].
About me: [YOUR EXPERIENCE LEVEL, LANGUAGES YOU KNOW, TIME AVAILABLE, HOSTING BUDGET]
Help me plan it before any code. If anything important is unclear, ask me up to 5 questions first, one at a time.
Then give me:
1. The core user and the one job the MVP must do well. List the v1 features and, separately, what we're leaving for later, with a reason for each cut.
2. User flows: the 2 or 3 key journeys, step by step.
3. A stack suited to my experience, with a one-line reason for each choice and the simplest hosting option.
4. Data model: entities, fields with types, relationships, and which fields need indexes or unique constraints.
5. Pages and API endpoints.
6. A build plan in small steps, each ending in something I can run and see working, starting with a bare walking skeleton deployed early.
7. Risks: auth, payments, privacy, and anything that's harder than it looks.
Keep the MVP as small as it can be while still being useful to a real person. Once I approve the plan, we'll build it one step at a time.
Why it works: Planning before code, with explicit cuts for later, keeps the first version small enough to finish. A data model and build steps that each end in something runnable expose design problems early, while they are still cheap to fix.
Tip: When you're ready to build, paste the approved plan into Claude Code as the starting brief so the code follows it step by step.
5. Portfolio website prompt
Claude or Claude Code
Use it when: Plan, write and build a personal portfolio site that leads with your best work and gets you hired or booked.
Prompt 05
Help me build a portfolio website.
<me>
What I do: [ROLE, E.G. PRODUCT DESIGNER, FRONTEND DEVELOPER, PHOTOGRAPHER]
Who I want to impress: [E.G. HIRING MANAGERS AT FINTECH STARTUPS, WEDDING CLIENTS]
What I want them to do: [E.G. EMAIL ME, BOOK A CALL, DOWNLOAD MY CV]
My best 3 to 6 projects: [FOR EACH: NAME, MY ROLE, THE PROBLEM, WHAT I DID, THE RESULT, LINKS OR IMAGES]
Style: [E.G. CALM AND PRECISE, OR BOLD AND PLAYFUL; SITES I ADMIRE]
Hosting: [E.G. GITHUB PAGES, NETLIFY, VERCEL, NOT SURE]
</me>
1. Suggest a site structure and a visual direction that fits my work and audience, in a few lines, and check it with me.
2. Write the copy: a hero line under 12 words saying what I do and for whom, a short about section in my voice, and each project as a mini case study (problem, approach, my contribution, outcome). Use only facts I've given, and put [ADD DETAIL] where something is missing.
3. Build it in [PLAIN HTML AND CSS / ASTRO / NEXT.JS / YOUR CHOICE]: responsive, fast, with optimised images, accessible, and with proper meta tags and social preview images.
4. Give step-by-step deployment instructions for my host.
Lead with the work: a visitor should see my strongest project within one scroll.
Why it works: Defining the audience and the action you want them to take lets Claude shape the structure around getting you hired or booked. Writing projects as mini case studies from facts you supplied shows how you think, and leading with the strongest work matches how reviewers skim.
Tip: Three projects with real context beat twelve thumbnails; cut anything you wouldn't want to be asked about in an interview.
6. Website UX and conversion audit prompt
Claude or Claude Code
Use it when: Audit a page from a URL or screenshots for what stops visitors converting, with fixes ranked by impact and effort.
Prompt 06
Audit this page for UX and conversion problems.
Page: [URL, OR ATTACH FULL-PAGE SCREENSHOTS AT DESKTOP AND PHONE WIDTH]
Goal: [THE ONE ACTION THAT COUNTS AS A CONVERSION]
Visitors: [WHO THEY ARE AND WHERE THEY COME FROM, E.G. GOOGLE ADS FOR "EMERGENCY PLUMBER"]
What we know: [CONVERSION RATE, ANALYTICS OR HEATMAP OBSERVATIONS, CUSTOMER COMPLAINTS]
If you can't open the URL, tell me and ask for screenshots rather than auditing from assumptions.
Follow a visitor's journey:
1. First 5 seconds: is it immediately clear what this is, who it's for and what to do next? Does it match the ad or search that brought them here?
2. Message and proof: specific value, credible evidence, objections answered.
3. Call to action: visibility, wording, competing actions, and form friction.
4. Trust and risk: pricing clarity, guarantees, contact details, reviews.
5. Usability: mobile layout, readability, signs of slowness, accessibility problems, anything broken or confusing.
Output a table of issues: what you observed (quote or locate it), why it likely hurts conversion, the fix, expected impact (high, medium, low) and effort. Sort by impact relative to effort. Then give the top 3 changes to make this week and how to measure whether each worked. Label anything that's a hypothesis rather than an observed problem.
Why it works: Following the visitor's journey from the first five seconds to the call to action ties every issue to a moment where people actually leave. Ranking by impact against effort and labelling hypotheses separately turns the audit into a prioritised to-do list instead of a list of opinions.
Tip: Add real visitor data, such as the drop-off step in analytics or a few session recordings, to turn best-practice guesses into a diagnosis.
7. Design system starter prompt with tokens
Claude or Claude Code
Use it when: Create a starter design system (colour, type and spacing tokens plus core component specs) that you can paste straight into your stack.
Prompt 07
Create a starter design system for [PRODUCT, E.G. A B2B SCHEDULING APP].
Inputs: brand colours [HEX VALUES, OR "SUGGEST"], personality [E.G. TRUSTWORTHY, FRIENDLY, DENSE AND TECHNICAL], platform [WEB / WEB AND MOBILE], stack [E.G. CSS VARIABLES, TAILWIND, STYLED COMPONENTS], dark mode [YES / NO].
Deliver:
1. Colour tokens in two layers: a primitive palette (each hue in steps from 50 to 900) and semantic tokens that reference it (background, surface, text primary, text muted, border, primary, success, warning, danger, focus). Check every text and background pairing against WCAG AA and list the contrast ratios. Include dark mode values if requested.
2. Typography: a font pairing, a type scale on a consistent ratio, line heights and weights, with a token for each role (display, headings, body, small, code).
3. A spacing scale on a 4px or 8px base, plus radius and shadow tokens.
4. Core component specs: button, input, select, checkbox, card, modal, toast. For each: anatomy, the tokens it uses, every state (default, hover, focus, active, disabled, loading, error) and accessibility notes.
5. The tokens as code for my stack, ready to paste.
Name tokens by purpose rather than appearance (text-muted, not grey-500), so themes can change without renaming anything. Keep it small: only what a first version of the product needs.
Why it works: Two layers of tokens, with semantic names that reference a primitive palette, let you change themes without touching components. Requiring contrast ratios for every text pairing and every component state builds accessibility in rather than auditing it later.
Tip: Build one real screen with the tokens straight away; gaps in the system show up within an hour of actual use.
8. Dashboard UI design prompt
Claude or Claude Code
Use it when: Design a dashboard that supports real decisions, with the right chart for each metric, a clear reading order and every data state covered.
Prompt 08
Design a dashboard UI for [WHO, E.G. A CLINIC OWNER REVIEWING PERFORMANCE ON MONDAY MORNINGS].
<metrics>
[EACH METRIC, ITS SOURCE, HOW OFTEN IT UPDATES, AND WHAT A GOOD VALUE LOOKS LIKE]
</metrics>
<decisions>
[WHAT THE USER DECIDES OR DOES AFTER LOOKING, E.G. WHETHER TO RAISE AD SPEND, HOW MANY STAFF TO SCHEDULE]
</decisions>
Stack: [E.G. REACT WITH RECHARTS, PLAIN HTML WITH CHART.JS, OR DESIGN SPEC ONLY]
1. Before designing, map each metric to the decision it supports, and tell me about any metric that supports no decision so we can drop it.
2. Layout: 3 to 5 headline numbers at the top, each compared with a previous period or target, then supporting detail. Explain the intended reading order.
3. For each chart, pick the type that fits the question (trend, comparison, composition, distribution) and say why. Start bar axes at zero, label units, use colour only to highlight what matters, and choose colourblind-safe colours.
4. Filters: date range and any segments, with sensible defaults.
5. States: loading, no data yet, partial data, error, and stale data with a last-updated time.
6. Layout on a laptop and on a phone, plus accessibility: text alternatives for charts and keyboard access.
Then build it with realistic sample data, clearly labelled as sample.
Why it works: Mapping each metric to a decision first strips out vanity numbers before any layout work begins. Choosing chart types by the question they answer, with honest axes and every data state covered, gives you a dashboard people can act on.
Tip: Start from the decisions rather than the data you happen to have; a dashboard of every available metric gets opened once and ignored.
9. Screenshot to HTML and CSS prompt
Claude or Claude Code
Use it when: Turn a screenshot, mockup or wireframe into clean, responsive, accessible front-end code that matches the design.
Prompt 09
Turn the attached [SCREENSHOT / MOCKUP / HAND-DRAWN WIREFRAME] into working front-end code.
Output: [ONE HTML FILE WITH CSS / REACT AND TAILWIND / VUE / YOUR STACK]
Fidelity: [MATCH IT AS CLOSELY AS POSSIBLE / MATCH LAYOUT AND STYLE BUT TIDY INCONSISTENCIES / IT'S A WIREFRAME, SO DESIGN THE VISUAL STYLE TOO]
1. Describe what you see first: the layout grid, sections, components, colours (estimated hex values), fonts (closest common or Google Font) and spacing. List anything ambiguous, such as hidden states or content cut off at the edge, and the assumption you'll make.
2. Build it with semantic HTML (header, nav, main, section, real buttons and links), CSS custom properties for colours and spacing, and Flexbox or Grid for layout instead of absolute positioning.
3. Make it responsive: it should look intentional at 360px, 768px and 1280px. Describe how the layout adapts at each width.
4. Accessibility: alt text, labelled form fields, visible focus, AA contrast. If a colour in the design fails contrast, keep the look, adjust it as little as needed, and tell me.
5. Use placeholder images at the correct aspect ratios and realistic text in place of lorem ipsum.
After the code, list where your build differs from the image and why.
Why it works: Having Claude describe the layout, colours and ambiguities before coding surfaces misreadings while they are easy to correct. Semantic HTML, CSS variables and named breakpoints produce maintainable code instead of brittle absolute positioning, and the closing list of differences tells you what to check.
Tip: For long or detailed pages, send a high-resolution image and convert one section at a time; detail lost in the image is lost in the code.
Getting more out of every prompt
Copy first, layout second
The message determines how much space each section needs, so writing the headline and sections before designing gives better pages. The homepage copy prompt is a good first step before the landing page prompt.
Commit to a direction
Generic results usually come from generic instructions. Choosing a specific style, a type pairing and one signature element, then asking Claude to apply them consistently, produces a page with a recognisable character.
Cover every state
Real interfaces spend time loading, empty, in error or full of awkward data. Asking for those states explicitly prevents designs that only work in the screenshot.
Use real proof only
Ask Claude to mark placeholders where you lack testimonials, numbers or logos. Invented proof damages trust when visitors notice it, and it can create legal problems.
Frequently asked questions
Can Claude build a website?
Claude can write the copy, plan the structure and generate the HTML, CSS and JavaScript or framework code for a website, and it can preview simple pages in the Claude apps. You still need to host and deploy the site. For larger sites, Claude Code can work directly in the project folder and run the build.
Is Claude good at UI design?
Claude can produce solid layouts, component code and design critiques, especially when you give it a clear visual direction, constraints and the states each screen needs. Without specifics it tends toward safe, generic designs, so name a style, reference sites and your existing design system.
Can Claude turn a screenshot into code?
Yes. Claude can read images, so you can attach a screenshot, mockup or wireframe and ask for HTML and CSS or components in your framework. Results are best with a clear, high-resolution image, a stated fidelity level and a request to list any differences from the original.
How do I get Claude to write landing page copy?
Give it your specific audience, their problem in their own words, what makes your offer different, the proof you have and the one action you want. Ask for several headline options from different angles and a recommendation, and tell it to use placeholders wherever you lack real proof.