Claude Prompts for Web Designers

You are a senior UX designer. <context> A homepage wireframe needs to be specified section by section before visual design starts. </context> <inputs> - Business name: [BUSINESS_NAME] - Primary goal of the homepage: [PRIMARY_GOAL] - Key sections requested (hero, social proof, features, pricing teaser, etc.): [KEY_SECTIONS] - Brand tone (playful, enterprise, minimal, etc.): [BRAND_TONE] </inputs> <task> Lay out every section of the homepage top to bottom, describing the content blocks, hierarchy, and CTA in each. Then render a low-fidelity grayscale wireframe of the full page. </task> <constraints> - Use realistic sample copy in every block (headlines, button labels, stat callouts), never generic filler text - Wireframe must use only grayscale boxes, placeholder labels, and simple borders, no color, no real imagery - Include one primary CTA above the fold </constraints> <format> A live HTML artifact showing the full-page grayscale wireframe, plus a section-by-section written spec below it (Section, Content Blocks, Hierarchy Notes, CTA) </format>

You are a senior UX designer. <context> A SaaS product needs a pricing page wireframed before it goes to visual design. </context> <inputs> - Product name: [PRODUCT_NAME] - Pricing tiers and rough price points: [PRICING_TIERS] - Key features to compare across tiers: [FEATURES] - Billing toggle needed, monthly vs annual: [BILLING_TOGGLE] </inputs> <task> Wireframe a full pricing page: tier cards, feature comparison table, FAQ section, and final CTA band. Recommend which tier should be visually emphasized as the most popular. </task> <constraints> - Show all tiers side by side, never stacked as the only layout - Comparison table must list every feature from [FEATURES] as a row with a check or cross per tier - If [BILLING_TOGGLE] is yes, wireframe the toggle control itself </constraints> <format> A live HTML artifact of the full grayscale wireframe (cards, table, FAQ, CTA band), followed by a one-paragraph rationale for the emphasized tier </format>

You are a senior front-end aware UX designer. <context> A desktop wireframe or design already exists and needs documented behavior for tablet and mobile breakpoints before development. </context> <inputs> - Page name: [PAGE_NAME] - Desktop layout description, sections top to bottom: [DESKTOP_LAYOUT] - Breakpoints to support: [BREAKPOINTS] (e.g. 1280, 768, 375) - Elements that must never be hidden on mobile: [MUST_KEEP_ELEMENTS] </inputs> <task> For each breakpoint, specify what stacks, what hides, what collapses into a menu or accordion, and what resizes. Note any element that changes from a grid to a single column. </task> <constraints> - Cover every breakpoint listed, in descending width order - Never mark a [MUST_KEEP_ELEMENTS] item as hidden at any breakpoint - Flag any section likely to need a different content strategy on mobile, such as a data table </constraints> <format> A table: Section, Desktop Behavior, Tablet Behavior (per breakpoint), Mobile Behavior, Dev Notes </format>

You are a senior design systems designer. <context> A project needs a base set of wireframed UI components before screens are assembled, so every screen reuses the same building blocks. </context> <inputs> - Project name: [PROJECT_NAME] - Component list needed (buttons, cards, form fields, modals, nav bar, etc.): [COMPONENT_LIST] - States required per component (default, hover, active, disabled, error): [STATES_NEEDED] </inputs> <task> Wireframe every component in [COMPONENT_LIST] at every required state, grouped in a single sheet. Label each variant clearly. </task> <constraints> - Group components in rows by type, states in columns, so the sheet reads like a matrix - Every interactive component must include an error or disabled state if it logically has one - Use grayscale only, no brand color </constraints> <format> A live HTML artifact rendering the component matrix (component rows by state columns) with a text label under every cell </format>

You are a senior UX designer preparing a dev handoff. <context> A wireframe is approved and needs precise spacing, sizing, and interaction annotations before a developer builds it. </context> <inputs> - Page or section name: [SECTION_NAME] - Layout description, elements top to bottom and left to right: [LAYOUT_DESCRIPTION] - Base spacing unit used by the design system (e.g. 8px grid): [SPACING_UNIT] - Interactive elements requiring hover/click behavior notes: [INTERACTIVE_ELEMENTS] </inputs> <task> Annotate the layout with spacing values (margins, padding, gaps) in multiples of [SPACING_UNIT], element sizing, and a note on the interaction behavior for every item in [INTERACTIVE_ELEMENTS]. </task> <constraints> - Every spacing value must be a multiple of [SPACING_UNIT] - Number each annotation and reference the number in both the layout description and the notes table - Do not leave any interactive element without a stated hover and click behavior </constraints> <format> A numbered annotation list matched to a table (Annotation #, Element, Spacing/Size, Interaction Behavior) </format>

You are a senior design strategist running client discovery. <context> A new client project needs a formal design brief compiled from a discovery call before any design work begins. </context> <inputs> - Client name and industry: [CLIENT_INFO] - Project type (new site, redesign, landing page, etc.): [PROJECT_TYPE] - Notes from the discovery call: [CALL_NOTES] - Budget range and timeline: [BUDGET_TIMELINE] </inputs> <task> Turn the raw call notes into a structured design brief covering project goals, audience, scope, competitor references, tone/style direction, technical constraints, and success metrics. </task> <constraints> - Every section must be filled even if notes are thin; flag any gap explicitly as "Needs client input" rather than inventing client-specific facts - Keep the whole brief to roughly 500 to 700 words - Scope section must list what is explicitly out of scope </constraints> <format> A structured document with headers: Project Overview, Goals & Success Metrics, Audience, Scope (In/Out), Style & Tone Direction, Competitor References, Constraints, Timeline & Budget </format>

You are a senior brand and web design strategist. <context> Before designing a new site, the team wants a structured teardown of 3 to 5 competitor sites to inform positioning and design direction. </context> <inputs> - Client/business name: [CLIENT_NAME] - Competitor site names or URLs: [COMPETITOR_LIST] - Aspects to evaluate (visual style, messaging, navigation, conversion paths, etc.): [EVALUATION_CRITERIA] </inputs> <task> Audit each competitor against every criterion in [EVALUATION_CRITERIA], score them, and identify a visual or UX gap the client's new site can own. </task> <constraints> - Score every competitor on the same criteria, using a consistent 1 to 5 scale - End with a clear "whitespace" recommendation: one specific design or positioning angle competitors are not using - Do not fabricate specific analytics numbers you cannot know; describe visual and UX observations instead </constraints> <format> A comparison table (Competitor by Criteria, scored 1 to 5) followed by a Whitespace Opportunity paragraph </format>

You are a senior design strategist. <context> A studio needs a client-facing intake questionnaire to run before the kickoff call, so the brief writes itself from the answers. </context> <inputs> - Project type (new site, rebrand, app design, etc.): [PROJECT_TYPE] - Client company size/type (startup, agency, retailer, etc.): [CLIENT_TYPE] - Anything already known about the client's goals: [KNOWN_GOALS] </inputs> <task> Write a discovery questionnaire the client fills out before kickoff, covering business goals, audience, competitors, style preferences (with example prompts like "3 sites you like and why"), content readiness, and technical constraints. </task> <constraints> - Group questions into clear sections with 3 to 6 questions each - Include at least 2 questions that surface style preference concretely (reference sites, color reactions) rather than abstractly - Keep total question count between 18 and 25 so it's completable in 20 minutes </constraints> <format> A numbered questionnaire grouped by section (Business & Goals, Audience, Competitors & References, Style Preferences, Content & Technical), ready to paste into a form tool </format>

You are a senior art director. <context> Before visual design starts, the team needs a creative direction brief that sets mood, color, type, and imagery direction without doing full design work yet. </context> <inputs> - Brand name: [BRAND_NAME] - Target audience: [TARGET_AUDIENCE] - Brand adjectives, 3 to 5 words the client wants to feel: [BRAND_ADJECTIVES] - Reference sites or brands the client likes: [REFERENCE_BRANDS] - Things to explicitly avoid: [AVOID_LIST] </inputs> <task> Translate the brand adjectives and references into concrete direction: a color direction with reasoning, a typography pairing direction, an imagery/photography style, and a layout density preference (dense/airy, grid-based/asymmetric). </task> <constraints> - Every direction choice must tie back to at least one word in [BRAND_ADJECTIVES] - Explicitly state how the direction differs from anything in [AVOID_LIST] - Do not recommend a specific hex palette yet, that belongs in the style tile; describe direction only </constraints> <format> A short brief with sections: Mood Summary, Color Direction, Typography Direction, Imagery Style, Layout Density, and a one-line note on how this reads differently from [AVOID_LIST] </format>

You are a senior design studio lead writing a client proposal. <context> A prospective client needs a proposal document outlining exactly what design deliverables they'll receive, in what phases, before signing. </context> <inputs> - Client name: [CLIENT_NAME] - Project type: [PROJECT_TYPE] - Number of unique page templates needed: [PAGE_COUNT] - Rounds of revisions included: [REVISION_ROUNDS] - Timeline in weeks: [TIMELINE_WEEKS] </inputs> <task> Break the project into phases (discovery, wireframes, visual design, handoff), list the exact deliverable in each phase, and state what is and isn't included, such as copywriting, photography, or development. </task> <constraints> - Every phase must list a concrete deliverable, not just an activity, e.g. "wireframes for all [PAGE_COUNT] templates" not "wireframing phase" - State revision rounds per phase, not just a total - Include one line on what happens if scope changes mid-project </constraints> <format> A phased proposal document: Phase, Duration, Deliverables (bulleted), Revisions Included, Client Responsibilities </format>

You are a senior front-end web designer. <context> A landing page needs a fully coded hero section, ready to preview and hand off, not just a description. </context> <inputs> - Product/business name: [PRODUCT_NAME] - One-sentence value proposition: [VALUE_PROP] - Primary CTA text and action: [CTA] - Visual style (bold gradient, minimal light, dark mode, etc.): [VISUAL_STYLE] </inputs> <task> Build a complete, responsive hero section: headline, subheadline, primary CTA button, and a placeholder visual area built as a styled div, not a broken image link. Include realistic sample copy. </task> <constraints> - Must be fully self-contained HTML and CSS, inline or in a style tag, no external dependencies - Must be responsive down to 375px width - CTA button must have a visible hover state </constraints> <format> A live HTML artifact of the finished hero section, renderable and previewable as-is </format>

You are a senior front-end web designer. <context> A pricing section needs to be coded and previewable for a client review, using their real tiers and pricing. </context> <inputs> - Product name: [PRODUCT_NAME] - Tiers with price and top 3 features each: [TIER_DETAILS] - Tier to visually highlight: [HIGHLIGHTED_TIER] </inputs> <task> Build a responsive pricing section with a card per tier, the highlighted tier visually emphasized with a badge, border, or elevation, and a CTA button per card. </task> <constraints> - Must be fully self-contained HTML and CSS, no external dependencies - Cards must stack to a single column below 640px - Highlighted tier's emphasis must be visible without color alone, also size, border, or badge, for accessibility </constraints> <format> A live HTML artifact of the finished pricing section, renderable and previewable as-is </format>

You are a senior front-end web designer. <context> A landing page needs a social proof section built to help a client visualize how real testimonials and logos will look on the live page. </context> <inputs> - Product/business name: [PRODUCT_NAME] - Sample testimonials (name, role, quote), or leave blank for realistic seeded examples: [TESTIMONIALS] - Client logos or company names to feature, or leave blank: [LOGOS] - Layout preference (carousel, grid, single-quote spotlight): [LAYOUT_PREFERENCE] </inputs> <task> Build the social proof section in the requested layout. If [TESTIMONIALS] or [LOGOS] are blank, generate realistic, industry-appropriate sample content, not generic filler text, clearly labeled as placeholder. </task> <constraints> - Must be fully self-contained HTML and CSS, no external dependencies - Any generated placeholder testimonial must be labeled "(sample, replace before launch)" in a code comment - Logos may be represented as styled text badges if no image assets exist yet </constraints> <format> A live HTML artifact of the finished social proof section, renderable and previewable as-is </format>

You are a senior front-end web designer. <context> A landing page needs an FAQ section with working accordion behavior, coded and previewable, not just a content list. </context> <inputs> - Product/business name: [PRODUCT_NAME] - FAQ questions and answers, or leave blank for typical questions for this product type: [FAQ_LIST] - Default state, all collapsed or first one open: [DEFAULT_STATE] </inputs> <task> Build a working accordion FAQ section: clicking a question expands its answer and collapses the previously open one, unless multi-open is requested. Use vanilla JavaScript only. </task> <constraints> - Must be fully self-contained HTML, CSS, and vanilla JS, no external libraries - Must be keyboard accessible, focusable and togglable with Enter or Space - If [FAQ_LIST] is blank, write 5 realistic FAQs appropriate to [PRODUCT_NAME]'s category </constraints> <format> A live HTML artifact of the finished, functioning FAQ accordion, renderable and clickable as-is </format>

You are a senior front-end web designer. <context> A landing page needs a final conversion-focused CTA band built and previewable, the section right before the footer. </context> <inputs> - Product/business name: [PRODUCT_NAME] - CTA goal (start free trial, book a call, join waitlist, etc.): [CTA_GOAL] - Supporting reassurance line (e.g. "no credit card required"): [REASSURANCE_LINE] - Visual style to match the rest of the page: [VISUAL_STYLE] </inputs> <task> Build a full-width CTA band: headline, one supporting line, one reassurance line, and a prominent button. Include an optional email capture input if [CTA_GOAL] implies a waitlist or newsletter signup. </task> <constraints> - Must be fully self-contained HTML and CSS, no external dependencies - Button must have a visible hover and focus state - If an email input is included, it must have a labeled, accessible form field, not a placeholder-only input </constraints> <format> A live HTML artifact of the finished CTA band, renderable and previewable as-is </format>

You are a senior visual designer. <context> A style tile is needed to align a client on color, type, and texture direction before full page designs are built. </context> <inputs> - Brand name: [BRAND_NAME] - Brand adjectives: [BRAND_ADJECTIVES] - Existing brand colors or logo colors, if any: [EXISTING_COLORS] - Reference sites/brands liked: [REFERENCE_BRANDS] </inputs> <task> Build a style tile: a primary and secondary color palette with hex codes, a heading and body typography pairing with sample text rendered in each, a button style sample, and a short texture/imagery mood description. </task> <constraints> - Provide exact hex codes for every color, minimum 3 and maximum 6 colors total - Render actual sample headline and body text in the chosen fonts, using widely available web-safe or Google Fonts names - Every choice must map back to at least one word in [BRAND_ADJECTIVES] </constraints> <format> A live HTML artifact showing the style tile: color swatches with hex labels, live-rendered type samples, and a sample button, laid out on one page </format>

You are a senior visual designer. <context> A design system needs a defined type scale and font pairing locked in before it's applied across page templates. </context> <inputs> - Brand name: [BRAND_NAME] - Heading font preference, if any: [HEADING_FONT] - Body font preference, if any: [BODY_FONT] - Platforms to support, including any specific breakpoints: [PLATFORMS] </inputs> <task> Define a full type scale, H1 through H6 plus body and small/caption, with pixel sizes, line heights, and weights for desktop and mobile. Recommend a heading/body font pairing if none is given. </task> <constraints> - Use a consistent modular scale and state the ratio used, e.g. 1.25 - Every size must include both desktop and mobile pixel values - Recommended fonts must be available on Google Fonts or a standard system font stack </constraints> <format> A live HTML artifact rendering each type level with real sample text at its actual size, followed by a table (Level, Desktop Size/Line-height/Weight, Mobile Size/Line-height/Weight) </format>

You are a senior visual designer with accessibility expertise. <context> A color palette exists or is being proposed and needs to be checked for WCAG contrast compliance before it's locked into the design system. </context> <inputs> - Brand name: [BRAND_NAME] - Proposed colors (hex codes) and their intended use, text, background, accent, etc.: [PROPOSED_COLORS] - Minimum WCAG level required, AA or AAA: [WCAG_LEVEL] </inputs> <task> Check every foreground/background color pairing likely to be used together, such as body text on background or button text on button color, against the [WCAG_LEVEL] contrast ratio requirement. Flag failing pairs and suggest a corrected shade that keeps the same hue family. </task> <constraints> - State the actual computed contrast ratio for every pair checked, not just pass/fail - Any suggested fix must stay visually close to the original color, adjust lightness rather than hue unless impossible - Check both normal text (4.5:1 for AA) and large text (3:1 for AA) thresholds where relevant </constraints> <format> A table: Foreground, Background, Use Case, Contrast Ratio, Passes [WCAG_LEVEL]? (Y/N), Suggested Fix (if N) </format>

You are a senior design systems designer. <context> A design system needs every interactive component's visual states documented and rendered so development matches design exactly. </context> <inputs> - Brand name: [BRAND_NAME] - Components to cover, primary button, input field, checkbox, link, etc.: [COMPONENTS] - Primary and accent colors (hex): [BRAND_COLORS] </inputs> <task> Render every component in [COMPONENTS] across its default, hover, active/pressed, focus, disabled, and error state where applicable, using [BRAND_COLORS]. </task> <constraints> - Every component must show all 6 states even if some look nearly identical; label them regardless - Focus states must be visibly distinct, not just a color change, to satisfy keyboard accessibility - Use only [BRAND_COLORS] plus grayscale, no colors outside the given palette </constraints> <format> A live HTML artifact rendering a state matrix (component rows by state columns), each cell labeled with the state name </format>

You are a senior design systems designer preparing a developer handoff. <context> A finished visual design needs its values extracted into a design token sheet so the front-end developer builds accurate CSS variables instead of eyeballing the design. </context> <inputs> - Brand name: [BRAND_NAME] - Colors used, name and hex: [COLORS] - Type scale used, level and size: [TYPE_SCALE] - Spacing unit and scale, e.g. 4px base, 4/8/16/24/32/48/64: [SPACING_SCALE] - Border radius values used: [RADIUS_VALUES] </inputs> <task> Produce a design token sheet naming every value as a reusable variable, such as --color-primary, --space-md, --radius-sm, grouped by category. </task> <constraints> - Every token name must follow a single consistent naming convention; state which one is used, e.g. kebab-case with a category prefix - No raw hex, pixel, or px value should appear anywhere without a token name attached - Include both the CSS custom-property format and a plain reference table </constraints> <format> A CSS code block defining all custom properties in a :root selector, followed by a table (Token Name, Value, Category, Usage Note) </format>

You are a senior web designer preparing a developer handoff. <context> A finished design needs to be packaged into a single handoff document so a developer can build it without back-and-forth questions. </context> <inputs> - Project name: [PROJECT_NAME] - Pages/sections included: [PAGES_INCLUDED] - Design tool used and where assets live, Figma link, exported files, etc.: [ASSET_LOCATION] - Known technical constraints, CMS, framework, performance targets: [TECH_CONSTRAINTS] </inputs> <task> Compile a handoff document: page-by-page breakdown of sections, spacing/breakpoint notes, asset locations and naming convention, interaction/animation notes, and a technical constraints summary. </task> <constraints> - Every page listed in [PAGES_INCLUDED] must have its own subsection, no combining pages - Asset naming convention must be stated explicitly, e.g. kebab-case, section-element.png - Flag any section likely to need developer judgment calls, such as unclear responsive behavior, as an open question, not silently </constraints> <format> A structured handoff document with a table of contents, one section per page, and a final "Open Questions for Dev" list </format>

You are a senior brand designer. <context> A client needs a simple one-page reference for how to use their new brand assets correctly on their own, without a full brand guidelines book. </context> <inputs> - Brand name: [BRAND_NAME] - Logo variants delivered, full color, white, icon-only, etc.: [LOGO_VARIANTS] - Primary colors (hex): [COLORS] - Primary and secondary fonts: [FONTS] - Common misuse to prevent, e.g. stretching the logo, wrong color on dark backgrounds: [COMMON_MISUSE] </inputs> <task> Create a one-page brand usage reference: which logo variant to use where, minimum clear space and size, approved color usage, font usage, and a section addressing [COMMON_MISUSE]. </task> <constraints> - Keep it to content that fits one printable page; prioritize the rules a non-designer is most likely to break - The misuse section must show at least 3 specific examples, not generic warnings - State exact minimum logo size in pixels and inches </constraints> <format> A structured one-pager with sections: Logo Usage, Clear Space & Minimum Size, Color Palette, Typography, Common Mistakes to Avoid </format>

You are a senior web designer running final QA before launch. <context> A site build is complete and needs a final design QA pass before it goes live, comparing the live build against the approved design. </context> <inputs> - Site name: [SITE_NAME] - Pages to check: [PAGES_TO_CHECK] - Breakpoints to test: [BREAKPOINTS] - Browsers/devices to test on: [BROWSERS_DEVICES] </inputs> <task> Build a QA checklist covering visual fidelity to design, responsive behavior at each breakpoint, interactive states, broken or missing assets, font loading, and cross-browser rendering. </task> <constraints> - Organize checklist items by page, then by check type within each page - Every checklist item must be a pass/fail statement, not an open-ended question - Include a severity rating, blocker, major, or minor, for each checklist item category </constraints> <format> A checklist table: Page, Check Item, Breakpoint/Browser, Severity if Failed, Pass/Fail (blank for the team to fill in) </format>

You are a senior web designer presenting design work to a client. <context> A design needs to be presented to a client or stakeholder group with a clear rationale for the key decisions, not just visuals. </context> <inputs> - Project name: [PROJECT_NAME] - Key design decisions to defend, layout choice, color direction, navigation approach, etc.: [KEY_DECISIONS] - Business goals the design supports: [BUSINESS_GOALS] - Anticipated client pushback or concerns: [ANTICIPATED_PUSHBACK] </inputs> <task> Build a presentation outline: opening context, then one slide-equivalent section per decision in [KEY_DECISIONS] tying it to a specific goal in [BUSINESS_GOALS], and a prepared response for each item in [ANTICIPATED_PUSHBACK]. </task> <constraints> - Every design decision must be tied to a stated business goal, not aesthetic preference alone - Prepared responses to pushback must acknowledge the concern before countering it, not dismiss it - Keep each slide-equivalent section to 3 to 4 talking points maximum </constraints> <format> A slide-by-slide outline (Slide Title, Talking Points, Supporting Rationale), followed by an Anticipated Questions & Responses section </format>

You are a senior web designer writing end-user documentation. <context> A client will be maintaining their own site content after launch and needs a plain-language guide to editing it safely in their CMS. </context> <inputs> - Site name: [SITE_NAME] - CMS platform, WordPress, Webflow, Framer, etc.: [CMS_PLATFORM] - Editable sections/content types the client will manage: [EDITABLE_SECTIONS] - Things the client should never touch, code embeds, global settings, etc.: [DO_NOT_TOUCH] </inputs> <task> Write a plain-language guide covering how to edit each item in [EDITABLE_SECTIONS] step by step, how to add a new page or post if applicable, and a clearly marked warning section for everything in [DO_NOT_TOUCH]. </task> <constraints> - Write for a non-technical reader, no jargon without a one-line definition - Steps must be numbered and specific to [CMS_PLATFORM]'s actual interface, real menu names and button labels - The do-not-touch section must explain the consequence of touching it, not just say "don't" </constraints> <format> A structured guide: Getting Started (login/dashboard orientation), one subsection per item in [EDITABLE_SECTIONS] with numbered steps, and a highlighted Do Not Touch warning box </format>