How to write better AI website prompts

Start with audience and action

A bakery site, a freelance portfolio, and a private client portal have different priorities. State the visitor and the primary action before describing colours. For example: “Parents should understand our music lessons and request a trial session.” That sentence helps determine content order, navigation, and the information a form should collect.

Supply content and mark gaps

Include real names, services, contact details, and approved images. Ask for missing facts to remain labelled placeholders. This matters particularly for prices, testimonials, qualifications, and business locations. A polished sentence can still be inaccurate if the builder had to invent the underlying fact.

Describe the initial scope

List the pages and features needed for the first version. State which existing tools should be linked or connected. If a basic enquiry form is sufficient, say that instead of asking for a complete CRM. Explain what should be excluded for now. Smaller, well-defined work is easier to inspect.

Use observable design instructions

“Readable on a phone,” “one main action,” and “keep the project photographs uncropped” can be checked. “Make it the best website ever” cannot. Give a reference only for the aspect you want to borrow, such as spacing or navigation, and keep your own content and identity.

Revise with context

When something goes wrong, identify the exact component and expected behaviour. Keep successful parts stable. For a form problem, describe what you entered and what happened after submission. For a layout problem, include the screen size and the element that overlaps. This gives the next change a clear target.

Start with the decision the visitor needs to make

A strong prompt begins with a visitor and a job. “Build a modern website” leaves the builder to invent both. “Help a parent compare our beginner piano lessons and request a trial session” gives the page a purpose. From that sentence, you can derive the content, the main action, and the information needed before someone clicks.

Write one sentence for the audience, one for the desired action, and one for the first version’s limits. Then supply the facts. A prompt should not ask the system to create the business itself unless that is explicitly an ideation exercise. Prices, credentials, testimonials, service areas, and operating hours need real inputs.

Compare a weak brief with a useful one

The useful versions are not necessarily longer. They remove ambiguity. A long prompt full of repeated adjectives can be less effective than a short brief containing the right facts and checks.

Use a six-part project brief

First, identify the audience and their context. A restaurant visitor looking for today’s menu needs different information from a founder evaluating an internal dashboard. Second, name the main action. Third, list the supplied content and mark gaps. Fourth, define the initial pages and features. Fifth, state design and operational constraints. Sixth, describe how the result will be checked.

Keep the brief outside the conversation as well. It becomes a reference when the project changes or when you compare another builder. Updating a written brief is more reliable than expecting a long conversation to resolve contradictory instructions automatically.

Prompt in stages when the task has dependencies

Start with information structure and content. Review that before adding detailed visual direction. Then connect required behaviour, such as a form or data source. Finally, test and refine responsive layouts. This sequence is not mandatory for every tool, but it helps separate decisions that are otherwise mixed together.

For a booking page, deciding whether appointments are requests or instant confirmations comes before designing a calendar. For a store, choosing the authoritative checkout system comes before making a payment button look attractive. The prompt should reflect those dependencies.

Use revision prompts that preserve working behaviour

For a visual revision, include the screen size and the element that causes trouble. For a functional revision, include the input and the result. “The form is broken” is not enough to distinguish validation, delivery, and display problems. A useful report says that a valid address was entered, the button was pressed, an error appeared, and no record was stored.

Write design instructions without copying another brand

Use a reference to identify a specific quality: spacing, navigation, typography hierarchy, or image treatment. Keep your own copy, identity, and assets. “Use a quiet editorial layout with a narrow reading column” is more transferable than asking for an exact clone of another company’s homepage.

Create a small design brief: one primary colour, one accent, type hierarchy, spacing rhythm, image style, and button rules. Ask the builder to apply it consistently. Repeatedly requesting a different style on individual sections can produce an inconsistent site even when each section looks reasonable alone.

Ask for missing states explicitly

A form needs invalid, submitting, successful, and failed states. A dashboard needs loading, empty, stale, and error states. A private application needs signed-out, expired-session, and denied-access states. These are part of the user experience and should appear in the prompt before launch.

Evaluate the output instead of trusting the completion message

Ask the builder to explain what changed, then verify the relevant behaviour yourself. Open the page, submit the form, inspect the destination, and test the mobile view. A statement that something is fixed is a claim about the work, not the evidence that it behaves as intended.

Keep a small checklist tied to the brief. If a revision resolves one issue but breaks another, record that clearly and return to the last known working point if needed. Avoid adding several unrelated changes before checking, because it becomes harder to identify which one caused the regression.

Build a reusable prompt library from successful work

Save prompts with their purpose, assumptions, and observed result. A prompt that worked for a static portfolio may not be appropriate for a private portal. Label the context so you do not reuse instructions that silently omit important access or data requirements.

The most useful library contains complete briefs, focused revision patterns, and verification checklists. It should make future work easier to explain and evaluate. A collection of exaggerated phrases promising instant perfect applications is less useful than a few clear examples that help you identify the next concrete step.

Your starting prompt

Use this as an editable brief. Replace the brackets with your own details and review the result before connecting real services.

The six parts of a useful brief

• Audience: who is this for?
• Purpose: what should visitors do?
• Content: what facts and assets are supplied?
• Scope: which pages and features are essential?
• Constraints: what must be preserved or excluded?
• Checks: how will you know it works?