Website Requirements Workbook Before Building with AI

Describe-to-build tools can now produce a working page in minutes. But fast building exposes an old problem more sharply: if you do not know what you want, you will quickly get something you do not want. In describe-to-build work you do not write the code, but you do define what is needed and you test it. This workbook is how you define it. Fill it in before your first prompt to the tool, or before your first meeting with a developer, and you will save many rounds of revisions.

The first-version rule: one page that works beats six pages that do not. Start with the smallest site that achieves the first goal, then add.

How to use the workbook

Fill the ten sections in order. Each depends on the one before: do not write page content before you know the audience and goal.
Write in plain language. No jargon needed; "I want an email when someone fills in the form" is an excellent requirement.
Separate "needed now" from "later". Every item gets a tag: now or later.
Review the workbook with someone else from your team or your audience, and ask: what is missing?
Turn the workbook into a build prompt using the template at the end of this resource, and build in stages.
Test against the acceptance criteria (section 10) before you call it done.

Security note: do not put passwords, API keys or real customer data in the workbook or in the prompts you send to the tool. No-code tools suit pages and forms, not systems holding sensitive data; those need a developer and a security review.

The blank workbook

1. Audience

Who will visit the site? Describe two or three groups at most, and for each: what they are looking for, on which device, and what worries them before they contact you.

Group one: who they are, what they look for, what worries them:

Group two (if any):

Languages needed and text direction (Arabic right-to-left, English, French…):

2. Goals

One main goal (what must the visitor do?), at most two secondary goals, and how you will know the goal is met.

Main goal (one action):

Secondary goals:

How we will measure success (orders, messages, sign-ups…):

What this site is not for (out of scope):

3. Sitemap

The list of pages and how they relate. Next to each page write: now or later.

Pages (name, purpose in one sentence, now or later):

Main menu and footer items:

4. User journeys

A user journey is the path from arrival to achieving the goal. Write two core journeys step by step, and mark where a visitor might stall.

Journey 1: where the visitor comes from → what they see first → what they tap → what happens next:

Journey 2:

Likely points of hesitation and how we address them:

5. Page content

For each page: title, sections in order, available copy, available images, and call to action. Mark what is not ready and who will prepare it.

Home page: headline and promise, sections in order, call to action:

Another page: sections and content:

Missing content, who prepares it, by when:

6. Features

What the site must do, not how it looks. Write each feature as "When… then…".

Features needed now (contact form, WhatsApp button, booking, search…):

Later features:

7. Data

What data does the site collect or show? Collect only the minimum. For each field: why we need it, where it is stored, who sees it, and when it is deleted.

Fields we collect and why:

Where they are stored, who can access them, how long they are kept:

Do we collect sensitive data (health, financial, about minors)? If so, what is the alternative or protection?

8. Integrations

External services the site connects to: email, spreadsheet, WhatsApp, maps, analytics, booking tool, payments.

Service, what it does, who owns the account:

Domain and hosting: what exists and who owns it?

9. Accessibility and performance

Text is readable on a phone without zooming, with enough contrast against the background.
Every image has alt text describing its content.
Buttons and links are large enough to tap and clearly named ("Book an appointment", not "Click here").
Forms can be used with a keyboard, and every field has a visible label.
Right-to-left direction is correct on Arabic pages, including forms, menus and directional icons.
The page loads quickly on an average mobile connection, and images are compressed.

Special needs of our audience (older users, low vision, weak connections…):

10. Acceptance criteria

An acceptance criterion is a sentence you can test with yes or no. "The site looks nice" is not one; "when the form is submitted, an email reaches the clinic inbox within minutes" is.

Criteria (one testable sentence per core feature):

Who tests, on which devices, and when:

From workbook to build prompt

Once filled, turn the sections into one clear prompt for the first version only, then refine with short follow-up prompts rather than rewriting everything.

First-version build prompt

Build a website [in Arabic, right-to-left] for [organisation] in [city].
Audience: [groups from section 1].
Main goal: [from section 2]. Every page leads to it.
Pages in this version only: [from section 3, "now" only].
Home page content in order: [from section 5].
Features: [from section 6, "now" only, written as: When… then…].
Form fields: [from section 7, minimum only].
Identity: colours [..], font [a clear Arabic font], logo [attached].
Accessibility: alt text on images, sufficient contrast, large buttons,
visible field labels.
Do not add pages or features not listed. No invented marketing copy: use
[attached copy], and where copy is missing insert a clearly visible [placeholder].

Then test every acceptance criterion, record what failed, and send short fix prompts, one per problem.

Completed example

Illustrative example

Nabd Physiotherapy Clinic is a fictional clinic in Tripoli that wants a simple website instead of relying only on a social media page.

1. Audience: (a) People aged 30 to 65 with back or knee pain or recovering from an injury, searching on their phones, worried about: is treatment right for my case? How many sessions? Where is the clinic, and is there parking? (b) Doctors who refer patients and want to know the specialities and how to refer. Languages: Arabic first; a short English page later.

2. Goals: Main: request an appointment through the form or WhatsApp. Secondary: help visitors understand which conditions the clinic treats. Measurement: monthly appointment requests from the site compared with direct messages. Out of scope: automated online booking with live slots, online payment, and patient records.

3. Sitemap:

Page	Purpose	Stage
Home	Promise, conditions, how we work, request an appointment	Now
Conditions we treat	Plain explanation of five common conditions	Now
Team	Therapists and their specialities (photos with their consent)	Now
Location and contact	Map, hours, parking, form	Now
For referring doctors	How to refer and what information we need	Later
Tips and exercises	Short articles	Later

4. User journeys: Journey 1: arrives from a search for "physiotherapy Tripoli" on a phone → sees the headline "We help you move without pain" and a "Request an appointment" button → taps "Conditions we treat" and finds "Lower back pain" → returns to the appointment button → fills in the form → sees a confirmation that the clinic will call within one working day. Journey 2: arrives from a link on the social page → taps the WhatsApp button directly → a chat opens with a ready message, "Hello, I'd like to book an appointment". Hesitation point: "Is my case suitable?", addressed with a visible line: "Not sure? Describe your case briefly and we will reply."

5. Home page content: Headline "We help you move without pain"; three benefits (individual assessment in the first session, a home exercise plan, written follow-up); "How we work" in three steps (contact, assessment, plan); the five conditions as cards; location and hours; the appointment form. Missing content: team photos (receptionist, within two weeks, with written consent) and condition texts (the lead therapist reviews anything the model drafts before publishing, because it is health information).

6. Features: When the form is submitted, a row is added to the clinic sheet and a notification email goes to reception. When the visitor taps WhatsApp, a chat opens with a ready message. When they tap "Directions", the map opens. Later: an automated reminder message before the appointment.

7. Data: Name, phone number, preferred call time, and an optional "brief description of your case" field with a visible note: "Please do not send medical reports or images here." Stored in a sheet that only reception and the manager can access; requests that did not become appointments are deleted after six months. No detailed medical information through the site.

8. Integrations: A spreadsheet for requests, the clinic mailbox for notifications, a WhatsApp link, a map. All accounts are in the clinic's name, not an individual's. The domain is registered to the clinic owner; hosting is not chosen yet.

9. Accessibility: Many patients are older: large base font, wide buttons, a tap-to-call phone number, and no text inside images.

10. Acceptance criteria:

When the form is submitted from a phone, a new row appears in the sheet and an email reaches the reception inbox.
The form cannot be sent without a name and phone number, and a clear Arabic error appears next to the field.
The WhatsApp button opens a chat with the correct clinic number and the ready message.
Every page reads on a narrow phone screen without horizontal scrolling.
Every image has alt text, and right-to-left direction is correct in the form.
No placeholder text appears in the published version.

Two people test the criteria: the receptionist on her phone, and a relative of a staff member who has never seen the site.

Common mistakes

Mistake: asking for a full six-page site in the first prompt. Fix: start with the pages marked "now" only, then add one page at a time.
Mistake: describing the look but not the function ("make it modern"). Fix: write what must happen: "when a visitor submits the form, I get an email".
Mistake: collecting more data than needed "just in case". Fix: every field needs a written reason, or it goes.
Mistake: letting the tool write copy and promises about the service. Fix: give it your copy, and have it insert a visible [placeholder] where copy is missing.
Mistake: service accounts in an employee's or developer's name. Fix: every account and the domain belong to the owning organisation, with staff as users.
Mistake: calling it done without testing on a real phone. Fix: acceptance criteria are tested on a real device by someone who did not build the site.

Completion checklist

The audience is described in two or three groups, with what worries each.
One main goal and how it is measured; out-of-scope items are written down.
The sitemap is tagged now or later.
Two core journeys are written step by step.
Content for every "now" page is known; missing items have an owner and a date.
Features are written as "When… then…".
Data is minimal, with storage location, access and retention defined.
Every account and the domain are in the owning organisation's name.
Accessibility items are reviewed.
Acceptance criteria are testable, with who tests them and when.
No passwords or real data in the workbook or the prompts.