Requirements · Web and design agencies
What a website project brief must contain before you approach agencies
Last updated 25 October 2026 · 3 sources listed · Reading time about 3 minutes
Short answer
A useful brief states business goals, audience, core features, content responsibilities, existing systems, constraints, timeline and how decisions will be made. It does not need to prescribe design. The aim is to let agencies see the real problem so they quote against the same scope and ask intelligent questions.
Who this is for: Someone preparing to request proposals for a website project who wants proposals that can be compared fairly.
What to evaluate
Business goals and measures
Agencies design differently for lead generation, sales, bookings or information. Without goals, they optimise for appearance.
How to check: State one to three outcomes and how you will tell whether the site achieved them.
Audience and journeys
Knowing who visits and what they try to do shapes structure and content. Assumptions here drive navigation errors later.
How to check: Describe main visitor groups, their typical tasks and any research you already hold.
Functional requirements
Features such as search, accounts, payments or multi-language support cause most of the effort and cost variance.
How to check: List must-have and nice-to-have features separately, with the systems they connect to.
Content plan
Who writes and supplies copy, images, product data and translations determines the schedule.
How to check: Specify content owners, volume estimates and whether the agency should help with writing.
Constraints and compliance
Accessibility, privacy, data residency and brand rules shape technology choices.
How to check: Record legal obligations, brand guidelines, hosting restrictions and approval processes.
Timeline and governance
A fixed event date or complex sign-off changes the plan. Unstated deadlines cause rushed compromises.
How to check: Give milestones, the named decision maker and the review cadence you can sustain.
Comparison
| Section | Why agencies need it | Common gap |
|---|---|---|
| Goals and success measures | To design for outcomes, not only looks | Goals listed as improve the website |
| Features and integrations | To estimate effort and risk | Third-party systems not mentioned |
| Content responsibilities | To plan schedule and resources | Assumed the agency will write everything |
| Governance and timeline | To plan reviews and delivery | Multiple unnamed approvers |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Business goals and measures | |||
| Audience and journeys | |||
| Functional requirements | |||
| Content plan | |||
| Constraints and compliance | |||
| Timeline and governance | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Have we documented what the current site does well and badly?
- Which analytics and customer insight can we share?
- Which systems must the site connect to and who administers them?
- Who writes, approves and uploads content?
- Which legal or accessibility obligations apply to us?
- What is the decision process and who signs off?
- What is the fixed date, if any, and why?
- How will we judge proposals against each other?
Typical trade-offs
Prescriptive brief
- Upside
- Comparable quotes and fewer misunderstandings
- Downside
- May limit creative solutions that you did not anticipate
Problem-focused brief
- Upside
- Invites alternative approaches and fresh thinking
- Downside
- Quotes vary widely and are harder to compare
Short brief with a workshop
- Upside
- Quick start and discovery together
- Downside
- Scope remains open until the workshop ends
Common mistakes
- Writing a brief that describes the look you want but not the problem the site has to solve.
- Leaving out existing systems, so integrations appear as surprise costs.
- Not saying who will provide content, then expecting it to be included.
- Sending the brief to too many agencies and lacking time to evaluate responses properly.
- Withholding the budget range, which makes proposals either unrealistic or inflated.
Related questions
Should I share my budget in the brief?
Sharing a range usually improves proposals. Agencies can then recommend what is feasible rather than guess. Withholding it can lead to quotes at wildly different scales that are not comparable. If you worry about inflated quotes, request itemised proposals and ask what would change if the budget were lower. A transparent agency will propose phasing or reduced scope instead of simply matching your number.
How long should a brief be?
Long enough to cover goals, audience, features, systems, content, constraints, timeline and process, which is often several pages. Length is less important than specificity. Attach supporting documents such as analytics summaries or brand guidelines instead of embedding them. If you cannot answer some sections, say so, and ask agencies to propose how they would discover the answer during an initial phase.
Do I need to know which platform to use?
Not necessarily. State your needs and constraints, then ask agencies to recommend a platform with reasons. Be cautious if every proposal recommends a single proprietary system. Ask about hosting, licence arrangements, portability, available developers and long-term costs. If your team already uses a platform and has skills for it, include that as a constraint so proposals reflect it.
What should I include about accessibility?
State the guideline level you expect, commonly a recognised conformance level from the international web content accessibility guidelines, and ask how the agency tests. Mention any legal obligations that apply in your jurisdiction. Accessibility is cheaper when built from the start than retrofitted. Ask for audit results or a plan for testing with assistive technologies before launch.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Planning and managing web accessibility — W3C Web Accessibility Initiative, retrieved 27 October 2026
- Web Content Accessibility Guidelines overview — W3C Web Accessibility Initiative, retrieved 27 October 2026
- Google Search documentation — Google, retrieved 27 October 2026
Related guides
How to choose · Web and design agencies
How to choose a web design agency for a business website
Pick an agency by matching its process and evidence to your actual goals, not by the look of its showcase. Ask to see projects with a similar business model, find out who will do the work, and check how it handles content, accessibility, search visibility and handover. A clear discovery phase, written scope and ownership of your files matter more than visual flair.
Alternatives · Web and design agencies
Web agency, freelancer or website builder: which route fits
The right route depends on complexity, internal capacity and how often the site will change. Website builders suit simple sites run by the owner. Freelancers suit well-defined, bounded work with a few specialisms. Agencies suit multi-discipline projects with integrations, stakeholders and ongoing development. Compare total effort, continuity risk and flexibility, not only the build cost.
Problems & fixes · Web and design agencies
Why website projects run over budget and behind schedule
Most overruns come from unclear scope, late content, too many decision makers and untested assumptions about integrations, not from slow developers. Prevent them by fixing scope in writing, assigning content owners, naming one approver, testing hard technical risks early and agreeing how changes are handled. Expect some change, and plan a contingency rather than treating it as failure.
Requirements · Translation and localisation
What a localisation project needs before translators start
Localisation adapts a product, not only its words, to a market's language, formats, culture and rules. Before translators begin, source content should be final and free of embedded text, code should support multiple languages and text expansion, and teams should agree glossaries, style guides, review roles and a process for continuous updates.
Requirements · Business operations
Requirements to qualify for a business loan
Lenders typically look for evidence of repayment capacity: financial statements, cash flow projections, tax filings, bank statements, business registration, details of owners and the loan purpose. More recent-generation businesses may need personal guarantees or security. Requirements vary by lender, product and jurisdiction, so ask each lender for its checklist. This is general information, not advice.
Comparison · Translation and localisation
Machine translation versus human translation for business content
Machine translation is fast and cheap enough for gisting, internal reading and high-volume low-risk text. Human translation, or human review of machine output, is needed where accuracy, tone, legal effect or reputation matter. A common hybrid is machine output followed by professional post-editing, with the level of review matched to the risk of the content.
How to choose · Outsourcing
How to choose a business process outsourcing partner
Select a partner by testing process maturity, relevant references, security and continuity controls, the stability and training of the delivery team, and how well governance will work day to day. Start from a clear process definition and measurable service goals. A pilot with real volumes tells you more than any presentation.
All Web and design agencies guides · All Professional services