“We need a more modern website” describes a preference, but leaves most of the project undecided. An agency still needs to know who the site serves, what visitors should be able to do, which content exists, and what must work on launch day. Different answers produce different proposals, even when every agency receives the same sentence.
A useful website project brief makes those decisions visible. It explains the business problem, separates requirements from possible solutions, names the people responsible for content and approvals, and defines how the finished work will be accepted. It can also contain unanswered questions. The important distinction is whether a question is open deliberately or has simply been overlooked.
You do not need to design the website before briefing an agency. You need enough shared context for the agency to recommend an approach and explain its assumptions.
Start with the business problem and the people using the site
Describe the problem in terms someone outside your company can understand. “Our website feels dated” may be true, but it does not explain what a redesign needs to improve. “Prospective customers cannot tell which of our services fits their project, so sales calls begin with basic clarification” gives the team something more useful to investigate.
List the main audiences and the decisions each needs to make. A prospective client evaluating a specialist service has different questions from a returning customer looking for support. Candidates considering a job need another journey. Prioritizing these audiences helps determine navigation, page content and calls to action without pretending that every visitor has the same goal.
Describe tasks, not just audience labels
Replace a label such as “business decision-makers” with a short task: “A marketing lead needs to understand whether we can migrate an existing website while preserving its useful content.” That statement suggests information the page must provide, evidence the visitor might need, and a relevant next step.
Include what you know about the current problem and how you know it. Sales questions, support requests, existing analytics and customer interviews can all help. If you lack reliable measurement, write that down. Do not turn a hopeful improvement into a factual baseline or ask the agency to guarantee an arbitrary conversion increase.
Choose a small set of measures that the project can reasonably influence. For example, the team might track completed enquiries alongside whether those enquiries contain enough project context for sales to respond. Define who will review the results and what tracking access is available. This is a measurement plan, not a promise that a new design alone will deliver revenue.
Specify pages, content and ownership
A page count is useful only when the agency knows what those pages contain. Twenty pages built from three reusable layouts are a different assignment from twenty individually designed experiences with new copy, complex data and custom interactions.
Start with an inventory of the current site. For each important page, record its URL, purpose, likely audience and proposed treatment: retain, revise, combine, investigate or remove. A proposed removal still needs review. A page that looks old may contain useful information or receive visits from links you have not measured.
Then outline the new content requirements. Identify the services, product groups, proof, company information and conversion journeys visitors need. A provisional sitemap is enough at this stage if you clearly label it as provisional. Ask the agency to challenge unnecessary pages and explain any missing ones.
Make responsibility more specific than “content supplied by client”
For each content group, name who drafts it, who provides subject expertise, who approves it and when it will be available. Copywriting, editing, uploading and checking published content are separate activities. A proposal should say which are included.
The same applies to images and other assets. Identify existing brand files, photography, product images, diagrams, videos and documents. Note whether you have the rights and original files needed to reuse them. If new visuals are required, specify their purpose before deciding how many to commission.
Content readiness affects the schedule. A service page cannot be fully evaluated with generic placeholder copy when the actual service explanation may be much longer or require a comparison table. Agree which representative content must be ready before design approval and which material can follow later using established patterns.
Describe functionality without prescribing every technical solution
Write down what a feature must do, the information it handles and the systems it depends on. “Connect the website to our CRM” is too broad. Explain what creates a record, which fields must transfer, who receives it, what happens to duplicates, and how a failed transfer should be noticed.
For a project enquiry form, describe the questions, required fields, routing rules, confirmation message and retention expectations. State whether uploads are necessary and what kinds of files should be accepted. Do not place real customer records or credentials in the brief. Use anonymized examples and arrange secure access separately when the project requires it.
For integrations, list the product name, account owner, available technical documentation and any known limitations. If you do not know whether the current subscription supports the required interface, make verification an explicit discovery task. A feature should not enter the fixed launch scope on the strength of a vendor logo alone.
Separate fixed constraints from preferences
Some decisions genuinely are fixed: an existing contract, an internal security requirement or a business system that cannot be replaced. Others are preferences that can be reconsidered if the agency presents a better fit.
Label the difference. “WordPress is required because our editorial team already supports it” is a constraint with a reason. “We assume WordPress, but want the agency to assess our publishing workflow” invites a recommendation. Neither statement requires you to write a technical architecture yourself.
Include hosting, domain ownership, languages, browser support, accessibility expectations and the systems that will remain unchanged. Record migration boundaries too. Moving pages does not automatically include migrating email, rebuilding customer accounts, transferring application data or replacing every connected service.
Turn requirements into observable acceptance criteria
An acceptance criterion describes evidence that a requirement has been met. It gives both sides a way to review the work without relying entirely on whether a stakeholder likes what they see.
“The site must be fast” needs a testing context. Which pages and journeys matter? Which device and network conditions will be used? Will the team examine repeated lab tests, available real-user data, or both? A single perfect score should not replace checking whether important visitors can actually complete their tasks.
Accessibility also needs an agreed scope and review process. Specify the intended standard, the interactions to test and who will evaluate them. Automated checks are useful, but should not stand in for keyboard testing or evaluating the experience with assistive technology. The W3C guidance on planning accessibility provides a starting point for assigning responsibilities throughout a project.
An illustrative requirement-to-evidence matrix
The following example describes a fictional service business replacing a brochure website with a clearer enquiry journey. It is a planning example, not a client case study or a claim about measured results.
| Requirement | Business owner | Evidence required before acceptance |
|---|---|---|
| Visitors can identify the appropriate service | Marketing lead | Reviewed service pages explain their audience, scope and next step using approved copy |
| Enquiries reach the correct team | Sales operations | Test submissions arrive in the agreed system with the expected fields and routing |
| Failed submissions do not mislead visitors | Technical lead | A controlled failure shows a helpful message and does not display a false success state |
| Editors can maintain service content | Content owner | An editor updates a page in their own role, previews it and publishes without changing the layout accidentally |
| Existing useful URLs remain reachable | Migration owner | The agreed URL register is checked against final responses and relevant replacement destinations |
| The business can operate the site after handover | Project sponsor | Accounts, ownership, documentation, training and support responsibilities are confirmed |
Add a reviewer and a due date to each requirement in your working document. If a check fails, record the issue and the retest evidence. Avoid treating a general “approved” email as proof that every integration, permission and content requirement has been checked.
Acceptance criteria should be proportionate. A simple information page does not need the same test plan as a customer portal handling private records. The brief should reveal the difference so the agency can scope the review appropriately.
Package the brief so proposals are comparable
Give agencies one current brief rather than a collection of contradictory emails. Include the business context, audience tasks, content inventory, provisional structure, functional requirements, constraints, acceptance approach and decision process. Attach supporting material only when its relevance is clear.
State what must be available at launch, what would be useful, and what can wait. A later phase should be genuinely separable. If a future requirement could change the content model or integration architecture, mention it now even when its implementation is deferred.
Include the budget range you can discuss and explain the deadline. A fixed event date creates a different planning problem from an internal preference. Ask agencies to identify assumptions, exclusions, client dependencies, revision allowances and the consequences of missing information. Do not ask for a firm fixed-price commitment while leaving major functionality undefined.
Use a short decision record
Keep a simple record of confirmed choices and open questions. Each open question should have an owner and a point by which it must be resolved. For example: “Sales operations will confirm whether enquiry routing can use the existing CRM subscription before integration scope is approved.”
Assign one person to consolidate stakeholder feedback. Specialists should still review their areas, but the agency should not have to resolve conflicting instructions from several internal teams. Explain how discovery and project review work when agreeing who will make decisions and what each approval means.
Before sending the brief, ask someone outside the project to read it and describe the intended result. If they cannot explain who the website serves, what is changing and what counts as finished, revise those parts. The objective is a usable shared understanding, not a document that sounds technical.
Website brief questions
Do we need a finished sitemap before approaching an agency?
No. Bring an inventory of existing pages and a provisional outline of the content visitors need. Mark uncertain groupings or proposed new pages as questions for discovery. A finished-looking sitemap can create false certainty if nobody has checked page purpose, content ownership or overlap. The agency should explain how it will validate and refine the structure.
Should we prescribe the CMS in the brief?
Prescribe it when there is a genuine operational or contractual reason, and explain that reason. Otherwise, describe the publishing tasks, integrations, ownership and support your team needs. You can name a preferred platform while asking the agency to test that preference against those requirements. A familiar product name is not a substitute for an editing workflow.
How much technical detail is enough?
Provide the systems, data flows, permissions and restrictions that affect the work. You do not need to choose every library or database before discovery. For uncertain integrations, include a named contact and request a feasibility check. This gives the agency enough information to investigate without making an unsupported implementation assumption part of the contract.
Who should approve the brief internally?
Choose a project sponsor who can resolve scope and budget decisions, supported by the people responsible for marketing, content, sales operations and relevant technical systems. Each specialist should review the sections they will depend on. One person should issue the consolidated approved version so the agency knows which decisions are authoritative.
Can a brief change during discovery?
Yes. Discovery often uncovers missing content, integration constraints or a simpler solution. Record the change, its reason and its effect on cost, timing and acceptance. Keep the previous version so everyone can understand what changed. Once delivery scope is approved, use the agreed change process rather than silently adding requirements to the document.
Should we share competitor websites?
Share them when you can explain what is useful: a clear service comparison, effective navigation or a helpful product explanation. Include examples you dislike for equally specific reasons. References help communicate expectations, but do not authorize copying another company's text, identity or interface. Your content and structure still need to fit your own customers and services.
Prepare the decisions before requesting the design
A useful brief leaves room for professional recommendations while making business needs and responsibilities clear. Start with the visitor's task, connect it to the necessary content and functionality, and decide how the result will be reviewed. If you are planning a website redesign, bring the unresolved questions as well as the confirmed requirements. Both belong in an honest project discussion.
