A website project scope should describe what users need to do, the content required, system integrations and tests before launch. Replace “add a contact form” with the fields it needs, where the submission goes and what happens if it fails. That makes supplier proposals easier to compare.
Define the website’s job
Start with the site's role in the business. A corporate website explaining services, a product catalogue collecting quote requests, an online store and a customer portal require different work. A project can combine them, but identify which outcomes matter for the first release. That choice helps the team make decisions when time, content or budget becomes constrained.
Describe what a visitor needs to complete. A procurement manager might find a suitable product, check its specifications and request a quote with the product details attached. That journey may involve search, filtering, a product page, a form and a handover to sales.
Showing those connections turns the scope into a description of a usable service rather than a collection of attractive screens.
List page types and content
Twenty pages do not necessarily require twenty different layouts. Service pages may share a template, while a catalogue using one template can still contain many data fields. Specify page types, their main fields and the amount of content to be prepared or migrated. Do not assume copywriting, translation, photography or data cleanup is included unless the proposal says so.
For an existing site, identify content that will be retained, revised or consolidated. Include how old links will be handled during the move. For multilingual projects, list the page pairs required at launch and who will maintain each language afterwards. The number of languages alone does not explain the editorial workload or identify the pages that might otherwise launch unfinished.
Describe how features must behave
“CRM integration” does not explain what information moves where. Specify the record created after a form submission, the fields transferred, matching rules and what should happen if delivery fails. A useful requirement covers more than the successful path. Missing information, invalid entries and temporary connection failures also need understandable behaviour and an owner.
Describe the user and operating requirements before insisting on a platform. An established product may meet them, or the project may need a custom module. Ask the team to explain the trade-off in relation to the changes you expect to make later.
This leaves room for the right technical approach without making the brief dependent on a tool chosen too early.
| Scope area | Vague request | A more useful requirement |
|---|---|---|
| Quote form | Add a contact form. | Include the selected product, confirm the result to the visitor and deliver a usable sales record. |
| Content management | Make it easy to update. | Allow an authorised editor to change service copy and images without breaking the layout. |
| Integration | Connect the CRM. | Define field mapping, duplicate-record behaviour and responsibility for failed transfers. |
| Languages | Build two versions. | List equivalent pages, translation ownership and the update workflow. |
Show what you mean by the design
Break down what you like in reference sites: typography, visual density, colour, motion, story sequence or product presentation. Discuss how those choices support your own message instead of asking for a whole reference to be copied. If the opening section moves automatically, include reading time, mobile composition and reduced-motion behaviour in the design discussion.
Plan accessibility throughout the work. W3C's planning resources provide a basis for discussing responsibilities across design, content and development. State the accessibility target, journeys to assess and verification approach in the scope. Make “mobile friendly” equally concrete by identifying menus, forms, long headings and representative content that need to work on smaller screens.
Write launch acceptance tests
Example acceptance test: opening the quote form from a product page should carry the product name into the request. A missing required field should prevent submission and explain the error beside the field. A successful submission should show confirmation and create one record for the sales team with the product name.
Run the same test on mobile and desktop. Check connection failures, repeated clicks on Submit and corrections after an error. Record the outcome of these scenarios in the delivery checklist instead of marking “form design” as complete.
- Success: the user confirmation matches the team’s record.
- Missing field: the error is clear and previous entries remain.
- Repeated submission: the status is visible and duplicate handling is checked.
- Mobile: the keyboard, fixed menu and chat widget do not obscure the form.
Include approvals and post-launch work
Name the people responsible for content, design and functional approval. If several stakeholders provide conflicting feedback, someone must turn it into one decision. New requirements are normal during a project. Define how their effect on existing work, cost and priorities will be assessed before they become an invisible addition to the schedule.
Clarify the handover of hosting arrangements, domain access, administrator accounts, source assets and training. Bug fixes, maintenance and new feature development are different services; their scope and duration should be explicit. Finally, agree which user feedback and usage information will guide improvements after launch.
The website needs to operate within the business, so handover should prepare the team to use and maintain it.
- Are the primary journey and first-release priorities clear?
- Are content, migration and translation owners assigned?
- Do integrations have defined data flows and failure behaviour?
- Can design and functionality be checked against acceptance criteria?
- Are approvals, change requests and post-launch responsibilities documented?