Define a website project through user journeys, content, integrations and acceptance criteria. Includes a practical scope table for your agency brief.
“We need a modern website” opens a design conversation, but it does not define a project. What should visitors accomplish? Who will prepare the content? Where will form submissions go? What should your team be able to update after launch? Without those answers, proposals based on page counts can price very different things. A useful scope connects appearance, functionality, content and operating responsibilities. It gives creative decisions a purpose and gives everyone a shared way to recognise when the work is ready.
1. Connect the business objective to a user journey
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.
2. Describe content types as well as page counts
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.
3. Define each feature through its inputs, outcomes and exceptions
“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. |
4. Explain design preferences as specific choices
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.
5. Write acceptance criteria before approval becomes subjective
An acceptance criterion describes how a requirement will be checked. Instead of “the form must work”, specify that the visitor receives an understandable result, the relevant team can retrieve the submission and a failed attempt produces useful feedback. Apply the same approach to search, product selection, content editing and language switching.
Consider a hypothetical training provider whose visitors apply for a selected programme. The visual design may be approved, but the journey is incomplete if the programme information never reaches the admissions team. This example illustrates why visual and functional checks belong together; it is not a claim about a client result. Verify the entire critical journey rather than approving only the homepage.
6. Include approvals, changes and life after launch
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?