Describe the business problem and target audience
Explain why the website is being changed and what is not working today. Use evidence where available: customer questions, support tickets, form drop-off, outdated information or technical limitations. Identify the audiences the site serves and the tasks each audience should complete.
Set a small number of measurable objectives and separate them from preferences. “The site should feel modern” is not an acceptance test by itself. Add observable requirements such as a visitor can find a service area, request a consultation on mobile and receive a confirmation.
Inventory pages, content and integrations
List current URLs, forms, downloads, tracking, third-party services and content owners. Mark what should stay, be improved, redirected or removed. Identify which content needs legal, product or subject-matter approval and who will provide final copy, images and translation.
State what systems the new site must connect to, how data should move and what happens when an integration fails. Do not assume a vendor can infer technical requirements from a screenshot. Provide access to a staging environment or documentation through a secure, approved process.
Define quality, ownership and accessibility expectations
Include mobile behaviour, performance, security, accessibility, browser support, backups and analytics in the brief. Specify that important tasks will be tested with keyboard and screen-reader checks where appropriate. Ask for a data and account handoff plan before the project begins.
Clarify who owns the domain, design files, source code, copy and image licenses. List support arrangements, maintenance responsibilities, recurring costs and how changes will be requested after launch. A project should not end with the client unable to access its own website.
Set milestones and acceptance tests
Break work into discovery, structure, design, implementation, review, testing and launch. Identify who approves each stage and how many review cycles are included. Agree on how new requests affect schedule and budget so teams can make informed trade-offs.
Before launch, test the critical pages, forms, redirects, analytics, accessibility, mobile layouts and account ownership. Save a rollback plan. A clear brief helps providers produce comparable proposals and reduces the chance of a disagreement over what “complete” means.
Practical checklist
- State the business problem, audience and measurable website tasks.
- Inventory pages, integrations, content owners and redirects.
- Define accessibility, security, ownership and support expectations.
- Agree on milestones, acceptance tests and a launch rollback plan.
In short
A clear brief describes what customers need to do, what the business can provide and how both sides will verify the finished website.
This article is general educational information, not legal, privacy, cybersecurity or financial advice. Confirm requirements for your situation with a qualified professional.