# A practical prompt engineering guide for AI website builders

Canonical: https://uvilno.com/guides/ai-website-builder-prompt-engineering-guide
Updated: 2026-10-27

Write briefs that describe purpose, pages, state, behavior, and design. Use examples and acceptance checks to make revisions easier to verify.

Written by the Uvilno team. Examples illustrate workflows; confirm service availability before launch.

## Treat the prompt as a product brief

When several people contribute requirements, resolve their priorities before combining the text. Mark the primary task and separate required behavior from optional ideas. A designer's preference for an immersive opening and an operator's need for a fast inquiry form can coexist, but the brief must explain their relative importance. An unresolved collection of stakeholder comments gives the builder conflicting instructions without a decision rule.

Prompt engineering for a website is mostly the work of making your intention explicit. The builder needs to know who the site serves, what those people should accomplish, what facts are available, and what behavior makes the result useful. Elaborate role-playing instructions rarely compensate for missing requirements. A brief that a designer and developer could understand is also a stronger input for an AI builder. Start with the outcome, then supply the information needed to make it concrete.

Separate required facts from creative decisions. You may want the builder to invent a layout, but not a street address, a professional qualification, or a customer review. Say what is verified and what should be omitted. When the project is fictional, label it as a demonstration so invented records do not look like real business evidence. This distinction gives the model room to design while keeping public claims grounded in material you can review.

## Use six parts to remove the important ambiguity

A reliable brief covers purpose, audience, content, structure, behavior, and visual direction. Purpose names the job; audience explains the visitor; content supplies facts and assets; structure lists actual pages or sections; behavior describes actions and state; visual direction sets the character of the result. These parts need not become a rigid form. A few connected paragraphs can cover them naturally, provided none is left for the builder to guess at a critical point.

The most frequently missing part is behavior. ‘Include a search bar’ could mean filtering a local list, searching public content, querying a hosted database, or doing nothing until a later release. Describe the input, action, and result. Likewise, ‘save preferences’ needs a persistence boundary: the current tab, the same browser, or an authenticated account. Put these choices in the brief before polishing adjectives about the interface.

Turn a vague requirement into an observable one

| Vague phrase | Clarification | Check |
| --- | --- | --- |
| Modern and premium | Large project photography, restrained palette, compact navigation | The chosen hierarchy fits the studio. |
| Add search | Filter the visible project list by title as the visitor types | A matching item remains; a missing term shows an empty state. |
| Save my work | Persist private records after sign-in and reload | The same user can read them again. |
| Add contact | Send a message through the enabled collector | A test submission reaches the owner. |

## Describe pages by the decisions they support

List each page with its job, primary content, and main action. A homepage introduces the offer; a project page supplies detail; a contact page provides the next step. A page map prevents the builder from turning every requested destination into an anchor on one long page. If separate routes are important, say so and include direct navigation in your acceptance checks. Keep page names aligned with visitor language rather than internal team terminology.

For an application, describe a complete user journey across routes. A reading-list page, an add-book form, and a profile page share identity and data even when their layouts differ. State which pages require sign-in and what happens when a visitor opens one directly while signed out. When the structure is complex, ask for a plan first and revise it before building. A plan is useful when it resolves choices, not when it merely repeats your feature list.

Example brief:

Use separate Home, Work, Project detail, About, and Contact routes. Home introduces the studio and links to Work. Each project opens a detail page with its supplied images and facts. Contact offers a real email link. Keep navigation consistent and make every route work when opened directly.

## Give visual references a specific role

A reference is most useful when you explain what you want from it. One image might demonstrate a wide editorial composition; another might show the density of a navigation bar. Name those qualities so the builder does not treat every detail as a requirement. Distinguish a reference from an asset you own and want placed on the site. A screenshot of another business should not become a source of copied claims, brand identity, or unlicensed imagery.

Describe a coherent direction rather than stacking conflicting style labels. For example, ask for an architecture portfolio with generous white space, large landscape photographs, quiet captions, and a clear inquiry link. Include the constraints that matter, such as an existing logo color or a requirement to avoid motion. Let the builder make lower-level choices unless you have a reason to pin them. A prompt that specifies every pixel can be both lengthy and internally contradictory.

## Include a short set of acceptance checks

Acceptance checks translate intent into a review you can perform. They are especially useful for generated interactions because a control can look complete while having no meaningful result. Write a few checks in plain language: a visitor can reach all pages; an invalid email produces a helpful message; a filter with no matches explains the empty state; a saved record remains after reload. Focus on outcomes that matter rather than implementation trivia.

Include failure and recovery, not only success. What should happen if a visitor cancels authorization, a hosted request fails, or local storage is unavailable? The interface should preserve useful input, explain the problem, and offer a real next step. Do not ask for fabricated success messages to make the demonstration appear finished. These checks guide the first build and remain valuable when a later edit changes a shared component or service connection.

- Every requested route opens directly and through navigation.
- Main actions have real, visible outcomes.
- Data persistence matches the requested boundary.
- Empty, loading, validation, and failure states are understandable.
- Phone layout and keyboard navigation support the same core task.

## Write revisions as target, problem, result, and preservation

After a build, a revision should identify the target and explain the difference you want. ‘Make it better’ makes evaluation subjective; ‘the phone headline wraps to five lines, shorten it to two or three without changing the offer’ is actionable. Add what should stay: the palette, photographs, navigation, or working form. Element selection can attach a target in Uvilno, but the written instruction still needs to explain the intended outcome.

For a bug, describe the starting state, the action, the actual result, and the expected result. Mention the device or route when relevant. Group changes that share a purpose, then inspect the outcome before asking for another broad change. A sequence of small coherent revisions creates clearer evidence than a single request mixing typography, routes, auth, payments, and a new brand. It also makes recovering a previous direction easier.

Example brief:

On the Work page at phone width, opening the menu hides the close control below the viewport. Keep the current colors and links. Make the menu fit the visible screen, keep the close action reachable, and return focus to the opener when it closes. Preserve the project filter behavior.

## Use Enhance and Plan for different questions

Enhance can help turn a rough idea into a clearer editable prompt. Review what it adds: it may make useful assumptions, but those assumptions still need your approval. In Uvilno, enhancement does not submit the build. You can undo or revise the text before sending it. Planning is a different step: it asks the system to propose a readable approach to pages, interactions, and service needs so you can approve that project direction.

Use enhancement when the wording is incomplete and planning when the product decisions are unresolved. Neither replaces checking business facts or understanding service boundaries. Both involve processing that can count toward usage. Opening a starter brief, naming a project, attaching a source, or editing text is separate from explicitly submitting model work. Keep that sequence clear so you understand when an action prepares a request and when it actually asks the builder to perform it.

## Fix conflicting requirements before adding more text

If the result repeatedly misses the goal, examine the brief for contradictions. A request for a minimal one-screen site conflicts with six long sections and a large catalog. A request for no external services conflicts with cross-device private accounts. A request for copied competitor content conflicts with original brand positioning. Resolve the underlying choice rather than appending increasingly emphatic instructions. The shortest accurate brief often works better than a long stack of unresolved compromises.

Keep a small project note containing the audience, primary task, approved page map, important facts, and accepted boundaries. Reuse it when starting a related project, but remove old requirements that no longer apply. Do not include credentials, private customer records, or irrelevant source dumps. A good prompt makes the problem understandable; it does not need to expose sensitive implementation details. The final test is still the working site and the visitor's ability to complete the intended task.

## Common questions

### Does a longer prompt always produce a better website?

No. A clear prompt with purpose, facts, pages, behavior, and a coherent visual direction is more useful than a long prompt containing contradictions or repeated adjectives.

### Should I tell the builder how to implement every detail?

Specify implementation details when they are real constraints. Otherwise describe observable behavior and acceptance checks, leaving room for the builder to choose an appropriate implementation.