Prompts for Website Design: From Brief to Page Review

Prompts for website design work best when they carry the context the assistant needs: the target audience, the goal of the page, and any decisions the client has already made. A vague prompt produces a generic answer. A specific one gives you a draft or critique you can actually use. Tools like fenbs store the approved client decisions outside any single chat, so every new prompt you run starts from the same foundation.

The templates below cover the main stages of a website project: clarifying a project brief, planning page structure, writing content requirements, and reviewing finished pages. Each prompt includes the fields to fill in and a note on what to watch for in the response.

What a good website design prompt includes

An AI assistant works from what you give it. A prompt that says "write copy for our homepage" can only produce a generic result. One that includes the goal of the page, the audience reading it, and any client decisions already made is a different kind of starting point. Before you send a design prompt, check that it answers these questions.

• Purpose: what the page should make the visitor do or decide.
• Audience: who they are, what they already know, and what they need to find.
• Constraints: brand voice, word limits, accessibility rules, or design system requirements.
• Decisions already made: approved directions, rejected alternatives, and standing client preferences.
• Output format: a draft, a table of options, a numbered structure, or a list of open questions.

Prompts for the project brief

Use this prompt at the start of a project to turn rough client notes into a working brief. Give it your notes from the discovery call and ask it to surface what is missing before design work begins. The questions it raises are often ones the client has not considered yet.

I am starting a website project for [client or business type].
Here are my notes from our first meeting:

[paste notes]

Turn these into a short project brief with:
- A one-sentence goal for the site
- The primary audience and what they need to do or find
- The three most important pages and the purpose of each
- Three open questions I should ask the client before we start designing

Flag any contradiction in the notes. Keep it to one page.

Once you have the client's answers, add them to your working document and treat it as the shared starting document for the project. Any later change to the goal or audience should update this document, not live only in a chat.

Prompts for page structure

Once the project brief is confirmed, use a structure prompt to plan the order of sections on a key page. Asking the assistant to give a reason for each section's position makes its logic visible. You can accept the order, move sections, or replace ones that do not fit the goal.

Plan the section structure for a [page type: homepage / product page / about page / contact page]
on a website for [brief description of the site and its audience].

Goal of the page: [what the visitor should do or decide]
Constraints: [any brand, word count, or layout rules]
Approved brief: [paste the relevant parts of the project brief]

For each section give:
- A short heading or description of its purpose
- One or two sentences on what it should contain
- Why it belongs in this position

Flag any section where you are guessing rather than drawing on the context I gave you.

Prompts for content requirements

A content requirements document tells a copywriter what to write, a developer what to plan for, and a client what to review. Use this prompt once the page structure is agreed. It produces a spec you can hand off without a follow-up call.

Write a content requirements spec for the [page name] page of [site description].

Approved structure: [list the sections]
Audience: [who is reading this page]
Tone: [brand voice or style notes]

For each section list:
- Word count range
- Required elements (headline, subheading, CTA text, image alt text, etc.)
- Any facts or figures the copywriter must check with the client before writing

Flag anything that depends on a decision we have not made yet.

Prompts for a design review

A design review prompt works best when it tests the design against the original brief rather than asking for general feedback. Include the goal of the page and any constraints the design must meet. Generic review prompts produce generic responses.

Review this design for the [page name] page.

Original goal: [what the page should make the visitor do]
Audience: [who is using this page]
Approved constraints: [any rules the design must respect]

For each section of the design:
- Does it serve the page goal?
- Is anything likely to confuse the audience?
- Is there a decision embedded in the design that someone has not explicitly approved?

Give concrete suggestions. Start with the highest-priority change.

For prompts that cover user flows and interface critique in more depth, see prompts for UI and UX design. If your project moves into development, prompts for building a website carries the same approach through to testing.

Keeping client decisions between sessions

Client website projects run for weeks, and a decision confirmed in one session does not automatically reach the next. The most common failure is a designer or developer redoing a direction that was already approved or rejected. Writing each confirmed decision into a shared record means every prompt you run starts from the same known position, regardless of which assistant or team member is working that day.

Record the decisions that shaped the project, those that changed direction mid-project, and any rules that apply to all work for this client. When you reuse a prompt template, pull the relevant decisions into the context before you send it. Prompt engineering covers the principles behind writing instructions that hold up when you reuse them.

A useful decision record for a website project includes the approved audience description, the accepted page structure for each key page, and the feedback rounds with their outcomes. When a direction changes mid-project, the reason for the change is as important as the change itself. A designer or developer reading the record three weeks later needs to understand not just what is current but why a different direction was tried and abandoned. That context prevents the same conversation from happening twice and keeps the next AI session from making a confident suggestion that was already considered and rejected.

How to do this with fenbs

1. Create a free account and add your website project.
2. Write the client's approved brief decisions into Decisions and rules: tone, audience, goals, and any rejected directions.
3. Save your most-used prompt templates in Skills and prompts with a short note on when each one fits.
4. Connect your assistant over MCP from Integrations, so it reads the project decisions and saved prompts before it starts.
5. After each client review, update the decisions and save any prompt variations that produced useful results.

fenbs does not generate designs or connect directly to design tools like Figma. For AI that works with design files, look at the integrations those tools offer.