AI works best with decisions, not just adjectives.
“Make me a modern website” can produce an attractive draft, but it leaves crucial choices open: who the visitor is, what the site must accomplish, what pages are needed, and what must not change. A useful instruction gives an AI system enough context to make a first pass while keeping you in control of the important decisions.
Start small: ask for the information architecture and one homepage first. Review it on desktop and mobile, then expand the approved pattern to the next page. This makes corrections cheaper and prevents a polished-looking site from drifting away from its purpose.
The brief every project needs
Before naming colors or fonts, write down the job of the site. These details help a non-programmer communicate clearly and give experienced developers a useful specification to validate.
- Audience: Who is visiting, what do they already know, and what question are they trying to answer?
- Primary action: Pick one main action per page, such as request an estimate, view services, compare plans, or book a call.
- Scope: Name the required pages, required sections, and any content you already have. Say what is out of scope too.
- Evidence and rules: Supply approved facts, contact details, legal wording, brand assets, and links. Tell the AI not to invent prices, testimonials, certifications, staff names, or policies.
- Success check: Define how you will judge the draft: readable on a phone, no horizontal scrolling, working navigation, visible form feedback, and accurate copy.
Copy-and-adapt project instruction
Replace the bracketed text before giving this to an AI website builder. It is intentionally plain: clear priorities are more helpful than impressive-sounding language.
Build a [number]-page website for [organization / project].
Audience: [who it serves and their main need]
Primary goal: [one action you want visitors to take]
Required pages: [Home, Services, About, Contact, etc.]
Must include: [approved facts, sections, assets, links, form fields]
Do not include: [claims, features, copy, images, or topics to avoid]
Create the homepage first. Show the navigation and page outline before
adding every section. Use placeholder text only where I have not supplied
approved copy, and label it clearly. Make the layout responsive and use
semantic headings, descriptive links, visible keyboard focus, and no
unnecessary motion.
Give the AI a usable style guide
A style guide does not need to be a brand book. It is a short set of design decisions that keeps pages consistent. Be specific about the choices that matter and leave room for the system to make low-risk layout decisions.
Style direction
Brand feeling: [reliable / editorial / technical / warm / minimal]
Colors: primary [#hex], accent [#hex], light background [#hex], body text [#hex]
Typography: headings [font family or style], body [font family or style]
Type scale: H1 [48–60px desktop, 34–42px mobile]; body [16–18px]
Layout: max content width [e.g., 1180px]; generous section spacing; cards [radius/shadow]
Buttons: primary [fill/color]; secondary [outline/color]; clear hover and focus states
Images: [photographic / illustrated / no people / black and white / aspect ratio]
Accessibility: meet readable contrast, label every form control, respect reduced motion
Do not use gradients / rounded cards / stock photos / other: [your constraints]
Colors, image direction, spacing, and interaction states matter more than asking for a site to feel “premium.” If you already have a working site, point to exact pages or sections you want to preserve instead of asking the AI to guess.
Example: a focused three-page service site
This brief keeps the first build manageable. It gives the AI a sequence, not a request to solve the whole business at once.
- Plan: “Create a navigation outline for Home, Services, and Contact. The main conversion is a contact request. Do not build yet; list the proposed sections and required content first.”
- Home: “Build the approved homepage outline. Use one H1, a short value statement, three service summaries, proof points I supplied, and one contact CTA. Do not invent reviews or client logos.”
- Services: “Reuse the approved header, typography, button style, and footer. Give each service a problem, approach, expected outcome, and a link to Contact.”
- Contact: “Add the approved email, phone number, service area, and a simple contact form. Explain what happens after submission. Include accessible labels and a clear success state.”
- Review: “Check all three pages at mobile and desktop sizes. List broken links, repeated headings, unclear buttons, insufficient contrast, and content you had to assume.”
Example: a five-page business website
For a larger site, request the shared system first, then build in batches. This is more reliable than asking for five unrelated pages that happen to use similar colors.
Build in this order:
1. Shared navigation, footer, buttons, typography, and mobile menu.
2. Home: purpose, credibility, featured offer, primary CTA.
3. About: organization story, team information I provide, values, CTA.
4. Services: clear service cards and individual service detail links.
5. Resources: searchable or categorized links only if the content exists.
6. Contact: approved channels, form, privacy note, success state.
After each page, stop and ask me to approve the layout before continuing.
Use the same design tokens and interaction patterns across every page.
Flag anything that requires a login, database, payment processor, third-party
form service, or legal review before presenting it as functional.
What to include—and what to avoid
Include
- Real audience, objective, and page priority.
- Approved facts, images, terminology, and reference links.
- Screen-size requirements and accessibility expectations.
- Clear acceptance criteria: “no dead links,” “mobile menu closes,” or “form has a success message.”
- Constraints around ownership, export, domains, analytics, and data collection.
Avoid
- “Make it like [brand]” without describing the parts you mean.
- Conflicting directions such as “minimal” plus “include everything.”
- Unverified prices, health claims, testimonials, or legal promises.
- Requests that imply a feature works without naming the service or integration behind it.
- One giant change request when you can review a smaller, testable pass.
How programmers can be more precise
Experienced developers can add technical constraints, but should still keep the request testable. Specify the target stack or hosting limits, existing routes that must remain stable, data shape, authentication boundary, error states, performance budget, and a validation plan. Ask the AI to explain assumptions before changing a database schema, payment workflow, production configuration, or security-sensitive code. Read more about source-code ownership, no-code and AI builder limits, and safe hosting migration before committing to a platform-specific approach.
Use AI as a reviewer, not only a generator
Once the first build exists, ask for an honest review in a separate pass. Provide the live or preview URL, the intended visitor, and the acceptance criteria. Ask for a prioritized list of observable issues rather than a vague redesign.
Useful review prompt: “Review this website as a [first-time customer / mobile visitor / accessibility tester]. Do not change anything yet. List the five highest-impact problems you can verify, explain why each matters, and recommend the smallest safe fix. Check mobile navigation, heading hierarchy, form labels, contrast, page speed, broken links, and whether the primary action is clear.”
This approach works with ChatGPT, Claude, and other AI assistants: use the model to surface possibilities, then keep a human responsible for facts, design approval, security, and publishing. When you are ready to go live, follow the AI website publishing guide, review hosting fundamentals, and compare AI website builders by the capabilities you actually need.
Related guides