Start with three observable outcomes
Describe what visitors should be able to do: understand an offer, compare services, request a quote, book or find an answer. For each outcome, name the audience and the next action. “Refresh our image” may be a valid ambition, but it does not define the pages or show whether the finished site works.
Record the starting point as well: existing pages, enquiries, frequently asked questions, content available and problems reported by users. A feature list without this context can duplicate what already works while leaving the real obstacle untouched.
- One primary outcome and two secondary outcomes.
- Priority audiences and their real questions.
- Available evidence such as approved examples, documents and verified figures.
Specify pages before visual effects
List the necessary pages. For each one, state its purpose, the question it answers, the content owner and the next step offered to the reader. A service page should explain who it serves, what is included, important limits and how to begin. A contact page should say what information to provide and set a response expectation the team can meet.
Inventory existing copy, photographs, logos, documents and translations. Confirm permission to use them and mark what still needs creating. For a multilingual site, assign a reviewer for every published language; unreviewed machine translation is not a substitute for local editing.
- Page map and a clear role for each page.
- Content available, missing and awaiting approval.
- Images to produce or replace, with intended formats and uses.
Separate essentials from later options
Describe real journeys: submitting a form, searching a catalogue, filtering results, paying or accessing an account. Give an input, expected output and error case for each function. “Add search” is too vague if no one has defined what it searches, how it handles zero results or whether it works by keyboard.
Classify each request as necessary for the first release, desirable after observing usage, or outside scope. This protects the budget and helps the team release a coherent site. Choosing a CMS or hosting provider becomes easier after the needs are clear.
- User journeys with starting point, action and confirmation.
- Required integrations and the owner of each account.
- Deferred functions and the evidence that would justify them.
Name decision makers and acceptance checks
Say who supplies content, resolves disagreements, reviews each page and accepts the final site. Plan short stages for structure, copy, design, implementation, testing and launch. A schedule without content delivery dates and named reviewers is unreliable.
Write a practical check for each deliverable. For example, the form shows a clear confirmation, delivers to the correct inbox and explains errors; key pages work on a phone; important old URLs redirect to relevant replacements. The prelaunch checklist covers those checks in detail.
- Deliverables and acceptance criteria.
- Dates and owners for content and approvals.
- Access, backups, training and maintenance after launch.
A short example you can send to a supplier
“We need a French and English website presenting four services and generating qualified enquiries. Our primary audience is managers of small businesses. We can provide company copy and twelve photographs with confirmed rights; service copy still needs drafting. The form must let visitors select a service, work on mobile and show a confirmation. Existing search-visible URLs should remain or redirect to equivalent pages. One reviewer will approve both languages, and the project will be accepted after testing the main journeys.”
This summary does not impose a design. It makes proposals comparable and exposes missing information early. Add unusual constraints as checkable facts and examples rather than slogans.