Create a build-ready website design brief for [BUSINESS OR PRODUCT]. Primary visitor and job to be done: [PRIMARY USER] Offer, proof, and conversion goal: [OFFER AND GOAL] Pages and required content: [PAGES AND CONTENT] Brand direction and existing assets: [BRAND AND ASSETS] Technical constraints: [TECHNICAL CONSTRAINTS]
Return a design specification with: 1. A page-by-page information architecture, naming the primary action, secondary action, and content that belongs above the fold. Explain the order by visitor decision-making, not decoration. 2. A desktop and mobile wireframe outline for the primary page. Describe each section’s purpose, heading, content type, CTA, and whether it is optional on smaller screens. 3. A component inventory: header, navigation, hero, forms, cards, testimonial or proof modules, pricing if relevant, footer, empty states, error states, and loading states. Define reuse rules and content limits for each. 4. A visual direction with type scale, spacing rhythm, color roles, image guidance, and motion rules. Do not prescribe a visual trend unless it supports the stated brand. 5. Accessibility and responsive requirements: keyboard navigation, focus states, semantic headings, form labels and error messages, contrast, reduced motion, touch target size, and behavior at 320px, 768px, and large desktop. 6. Acceptance criteria a developer can test, including performance-sensitive asset choices and no-JavaScript fallback for essential content or form submission where feasible. Do not invent customer proof, logos, legal claims, imagery rights, or product capabilities. Before answering, verify every primary page section supports either understanding, trust, or the conversion decision, and flag any required content that the brief does not yet supply. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [BUSINESS OR PRODUCT] | What the business or product is, what it sells, and its current stage. | A bookkeeping service for independent marketing consultants, offering monthly reconciliations and quarterly reporting. |
| [PRIMARY USER] | The main visitor, their context, and the task they need to accomplish. | A U.S.-based consultant earning $150k-$400k who needs reliable books before tax season but does not want to learn accounting software. |
| [OFFER AND GOAL] | The offer, supporting proof you can substantiate, and the main conversion action. | A fixed-price monthly bookkeeping plan; primary goal is a 20-minute discovery call; verified proof includes CPA oversight and response-time policy. |
| [PAGES AND CONTENT] | The pages, required copy, policies, media, and integrations the site needs. | Home, services, process, about, FAQ, contact, privacy policy, and a call-booking integration. |
| [BRAND AND ASSETS] | Existing brand rules, reference sites, logo, photography, illustrations, and content assets. | Wordmark, navy and cream palette, two founder headshots, and professional client quotes with permission. |
| [TECHNICAL CONSTRAINTS] | Your framework, CMS, analytics, form provider, performance targets, and implementation limits. | Next.js, a lightweight CMS, Calendly embed, WCAG 2.2 AA target, and no autoplay video. |
How to use
- Paste the real offer, available proof, and implementation constraints before asking for visual choices.
- Compare the primary-page outline to your visitor’s actual decision sequence and remove sections that repeat the same claim.
- Hand the acceptance criteria to the developer alongside the wireframe rather than treating the output as finished code.
- Follow up with: “Turn the home-page wireframe into a mobile-first content outline with final placeholder copy limits for each section.”
Variations
Landing page
Use this for one campaign or product page.
Design a conversion-focused landing page for [OFFER] aimed at [AUDIENCE] coming from [TRAFFIC SOURCE]. The desired action is [CTA], and these are the only substantiated claims and proof points: [VERIFIED PROOF]. Produce a section-by-section wireframe, proposed heading hierarchy, form fields, objection handling, mobile behavior, and accessibility requirements. Keep one primary CTA and explain any secondary CTA. Do not invent testimonials, scarcity, results, or logos. Check that every section answers a distinct decision question and that the form asks only for information needed to follow up.
Design system
Use this before designing several related pages.
Define a small design system for [PRODUCT OR BRAND] across [PAGE TYPES]. The users are [USERS], brand constraints are [BRAND RULES], and implementation is [TECH STACK]. Specify foundations, typography tokens, color roles with contrast requirements, spacing, grid, interactive states, and reusable components with variants. Include rules for long labels, missing images, validation errors, and keyboard focus. Do not create a component merely for a one-off decoration. Check that tokens support light and dark requirements only if both are actually in scope.
Accessibility review
Use this to inspect an existing design before build.
Review this website design or page description for accessibility and inclusive-use issues: [DESIGN DETAILS]. The primary tasks are [USER TASKS], and the supported environments are [BROWSERS AND DEVICES]. Produce a prioritized table with issue, affected users, relevant requirement or principle, recommended design change, and test method. Cover heading structure, focus order, contrast, text resizing, forms, errors, target sizes, motion, and non-text content. Do not claim compliance from a description alone. Flag items requiring a coded prototype or assistive-technology test.
Tips
- Make the primary action visible before the visitor scrolls, but place the proof needed to trust it nearby rather than in an isolated testimonial section.
- Write component rules for long content and missing media early; these states expose weak layouts before launch.
- Treat mobile as a different reading order, not a smaller desktop canvas; navigation, comparison tables, and multi-column proof need explicit behavior.
- Use real form errors and empty states in design review because they are part of the task flow, not edge-case polish.
FAQ
Can Claude design a website that developers can build?
It can create a useful brief, wireframe, and component specification. A developer still needs to make framework, performance, security, and testing decisions in the actual implementation.
Should I ask AI for colors and fonts first?
Start with users, content, and the conversion decision. Visual choices are stronger when they support an established hierarchy and available brand assets.
Can an AI design review prove accessibility compliance?
No. It can identify likely issues and test criteria, but compliance requires checking the built site with keyboard use, automated tools, and appropriate manual testing.