Website brief template for complex website projects

A thin website brief does not save time. It moves unanswered questions into proposals, design workshops and development, where each agency fills the gaps with different assumptions. The resulting prices may look comparable, but the scopes behind them are not.

A useful complex website brief creates a common starting point. It explains why the project exists, who it must serve, what the organisation already knows, where uncertainty remains and which constraints could change the delivery pathway. That makes early conversations more productive and helps a responsible agency decide whether it can define a proposal or needs Discovery first.

The short answer

A strong website brief should document outcomes, audiences, scope indicators, quantities, content responsibilities, known systems, governance, timing and investment context. It should identify technical, privacy, accessibility, security and migration requirements at a high level. It should not invent architecture, a final sitemap, integration specifications or a platform recommendation where the evidence does not yet exist.

Most importantly, a better brief does not guarantee a fixed quote. It tells an agency what is known, what must be clarified and whether the work is sufficiently defined to scope responsibly.

What makes a website project complex?

Complexity is not simply a page count. A relatively small website can carry material risk if it contains sensitive data, account access or unfamiliar integrations. A large content site may be more predictable if the content model, governance and migration rules are already understood.

Treat a project as complex when one or more of the following materially affects the customer experience, operating model, data or delivery risk:

• Ecommerce, subscriptions, memberships, payments or fulfilment rules.
• Portals, logins, permissions, account management or personalised content.
• Connections to customer relationship management, enterprise resource planning, warehouse, product information, booking, learning or marketing systems.
• Structured data migration, large product or content inventories, or unclear ownership of source records.
• Multiple sites, brands, regions, languages, currencies or local approval models.
• Custom workflows involving forms, approvals, service delivery, quoting or internal teams.
• Formal accessibility, privacy, security, data-residency or regulatory requirements.
• Significant search migration risk, analytics change or performance and availability expectations.
• Many stakeholders, constrained dates, staged launches or complex procurement and governance.

These are the same kinds of decisions that cause website projects to blow out when they are left implicit. Naming them in the brief gives everyone a fairer view of the work.

What a good complex website brief should achieve

A brief should make the current understanding visible. It should help stakeholders agree on the business reason for the project, the audiences that matter most, the initial boundary and the decisions that remain open. It should also show an agency where evidence exists and where it must ask better questions.

A brief should not become a disguised solution specification. If the organisation has already selected a platform, defined an integration or committed to a deadline, explain whether that is a firm constraint, an informed decision or a current preference. Those categories are not interchangeable.

The most useful language is often simple: “known”, “estimated”, “preferred”, “required”, “future phase” and “please recommend”. Those labels separate facts from assumptions and allow a delivery partner to challenge the right things.

What the free website brief template covers

Emote’s editable template uses eight core sections for every substantial project and three conditional sections for work with additional technical or commercial complexity.

Complete the eight core sections, then use the conditional supplement where the project needs it.

The eight core sections

• Business context and objectives: why the project exists, how success will be judged and what is in or out of the initial engagement.
• Audiences and user journeys: priority groups, their practical needs and the tasks the website must support.
• Current website and project direction: the existing estate, known problems, constraints and the intended type of change.
• Site structure and quantities: indicative pages, templates, products, records, locations, forms and other scope drivers.
• Brand, design and content: identity inputs, content ownership, production needs, approvals and available assets.
• Functionality and forms: launch-critical features, workflows, notifications, administration and later-phase ideas.
• Delivery, governance and investment: stakeholders, decision rights, dependencies, genuine dates, selection criteria and budget context.
• After launch and supporting information: third-party hosting needs, maintenance, support, optimisation, warranty boundaries and available documentation.

Emote does not provide hosting infrastructure. Emote can advise on requirements and recommend or coordinate a suitable third-party hosting partner; the client normally contracts with and pays the provider directly.

The three conditional sections

• Systems, integrations and structured data: source systems, owners, data movement, documentation and migration context.
• Complex requirements: ecommerce, portals, permissions, payments, subscriptions, custom workflows, multisite and multilingual needs.
• Search, analytics and technical requirements: organic visibility, measurement, accessibility, privacy, security, performance, hosting and disaster recovery.

You do not need to complete every field. Use the sections that apply, route specialised questions to the right internal owners and write “Please recommend” where an answer is not yet known.

The information agencies need most

1. Outcomes, not only outputs

“Build a new website” describes an output. The brief should explain the business change behind it: improve qualified enquiries, make products easier to find, support a new service model, reduce manual administration, protect organic visibility, enable customer self-service or consolidate a fragmented estate.

Add any existing baseline, target or decision criterion that matters. Avoid invented precision. A clear commercial outcome with an honest baseline is more useful than an unsupported percentage.

2. Priority audiences and priority tasks

A list of audience labels is not enough. Explain what each group is trying to do, what prevents them doing it today and which journey matters most. A dealer finding technical product data, a patient choosing a location and a procurement lead comparing service capability require very different structures and evidence.

3. Quantities and repeatable content types

Scope is affected by quantities: pages, products, articles, locations, forms, languages, accounts, document libraries, data records and templates. Use indicative ranges if the inventory is incomplete. Separate unique page design from content entry and migration volume.

4. Launch scope versus later phases

Mark what is essential for launch, desirable if budget permits and better suited to a later phase. A feature list without priorities forces every proposer to guess. Phasing also helps protect the core customer journey when timing or investment is constrained.

5. Systems, data and ownership at a high level

Name the systems that may connect to the website, the business owner, the vendor contact and the information expected to move in each direction. You do not need to design the integration. Emote’s guide to website integration decisions before development explains why source-of-truth, failure and support questions matter early.

6. Content ownership and migration reality

State who will audit, write, approve, enter and maintain content. Identify what must be retained, rewritten, retired or created. If the site has meaningful search equity, migration is not a late launch task. Google’s site-move guidance covers URL mapping, redirects, internal-link updates and monitoring; your brief should flag whether that work is required, even before the detailed plan exists. Google Search Central migration guidance

For a more practical planning sequence, use Emote’s SEO migration checklist alongside the brief.

7. Governance, genuine dates and investment context

Identify the project sponsor, working team, subject-matter experts, decision-maker and approval path. Explain whether a date is immovable, preferred or linked to another event. Share an approved or indicative investment range and say what it includes. Budget context lets agencies recommend a credible boundary; hiding it does not remove the constraint.

How to complete the template without inventing technical answers

The goal is not to research every platform, standard or integration before speaking with an agency. Use this sequence instead:

1. Complete the facts your organisation can verify.
2. Label estimates, preferences, firm constraints and unknowns clearly.
3. Ask the stakeholder who owns each area to contribute directly.
4. Use “Please recommend” where advice or validation is genuinely required.
5. Attach useful, non-sensitive material such as a sitemap, content inventory, brand guidelines or architecture diagram.
6. Keep credentials, access codes, source code, live personal records and production exports out of the document.

If protected information must be reviewed, agree a secure transfer method and any required confidentiality arrangements first.

Who should contribute to the website brief?

The author can coordinate the document, but a complex brief is rarely a one-person task. Bring in the smallest group that can answer the questions accurately:

• Executive sponsor for business outcomes, investment and decision rights.
• Marketing, brand and content owners for audiences, positioning, content and search.
• Operations or service teams for workflows, locations, fulfilment and administration.
• Technology and system owners for integrations, data, hosting constraints and support.
• Privacy, security, legal or risk stakeholders where formal requirements apply.
• Finance and procurement for commercial boundaries, vendor process and approval timing.
• Frontline staff or customer research owners who understand real user friction.

Do not wait for complete consensus on every solution. Record disagreements and open decisions. They are valuable inputs because they show where facilitation or evidence is required.

Common website briefing mistakes

Prescribing a platform without evidence

A platform may be a legitimate constraint, an internal preference or simply the first name someone recognised. State which one it is. Platform fit depends on content, commerce, integration, governance, security, editor and operating requirements.

Listing features without users or workflows

“Portal”, “calculator” and “personalisation” can each describe many different systems. Explain who uses the feature, what starts the journey, what information is needed, what outcome occurs and who administers it.

Leaving quantities blank

Migration effort, content production, templates, testing and administration all depend on volume. Give a range and explain confidence if exact figures are unavailable.

Hiding budget and asking for a fixed quote

Without investment context, agencies must either design an arbitrary solution or spend the proposal explaining many possible ones. An indicative range is enough to test whether the ambition, timing and operating model can meet.

Treating launch as the finish line

A website needs a third-party hosting arrangement, maintenance, measurement, support, content ownership and an improvement plan. Separate hosting, ongoing support and marketing from the 30-day functional warranty so responsibilities are understood.

Attaching sensitive information

A brief should confirm that data, systems or access exist. It should not contain secrets or live records. This is particularly important when the document will circulate through procurement or multiple agencies.

Assuming an unanswered decision disappears

Asking for a fixed price does not make an unresolved workflow, integration or migration predictable. It moves the decision into a later phase and usually makes proposal comparisons less reliable.

Website brief versus Full Website Discovery

A website brief is client-led. It records what the organisation currently knows: objectives, audiences, scope indicators, quantities, constraints, stakeholders and known systems. It exposes gaps and supports initial qualification and pathway selection. It is not validated architecture or delivery documentation.

Full Website Discovery is facilitated and led by Emote. It brings the right business, customer, content, technical and governance stakeholders together; tests priorities and assumptions; validates requirements, journeys, integrations, data, hosting needs, risks and dependencies; and produces the Functional, Technical and Governance blueprint, roadmap and estimates used for the next investment decision.

The brief records the current understanding. Full Website Discovery validates the delivery baseline.

Dimension	Website brief	Full Website Discovery
Led by	Your organisation	Emote, with the right stakeholders
Purpose	Record current knowledge and expose gaps	Test assumptions and resolve material decisions
Output	Input for qualification and pathway selection	Functional, Technical and Governance blueprint

The template helps you arrive better prepared. It does not replace Full Website Discovery. A brief records the current understanding; Discovery tests that understanding, resolves material decisions and creates the approved delivery baseline. Skipping Discovery does not remove those decisions. It postpones them until design or development, when changing direction is slower, more disruptive and more expensive.

Focused and Full Website Discovery are separate paid engagements and are not credited against implementation unless Emote expressly agrees otherwise in writing. Approved Full Website Discovery outputs become the delivery baseline when referenced in the signed or accepted implementation proposal.

Read Emote’s detailed explanation of the difference between a website brief and paid Discovery if your team is deciding which level of definition is required.

Why this level of definition matters in practice

Complexity becomes real in the relationships between content, journeys, systems and governance. Emote’s Sutton Tools website work involved more than 21,000 products, ERP integration, a specialist selector and multiple regional sites. A feature-only brief would not expose the operating and data questions behind that experience.

For Primary Dental, the programme connected a multi-location experience with integrations and search migration. The relevant brief is not “design a dental website”; it is the business, content, location, integration and transition context needed to plan it responsibly.

The lesson is not that a brief must contain the final solution. It must reveal the categories of decision that shape the solution.

Accessibility, privacy and security belong in the brief

If the organisation has a formal accessibility target, record the applicable standard, conformance level, procurement requirement and validation expectations. The W3C’s Web Content Accessibility Guidelines use testable A, AA and AAA conformance levels. The delivery team still needs to confirm the exact applicable version and acceptance process. W3C WCAG overview

Privacy and security also affect data collection, authentication, integrations, hosting, logs, retention, administration and incident responsibilities. Australian guidance promotes privacy by design and secure-by-design thinking, which is another reason to raise these needs before design and development rather than treating them as launch checks. OAIC privacy by design · ASD secure by design

The brief should identify the requirement and owner. Detailed threat modelling, privacy impact assessment, solution controls and acceptance evidence belong in the appropriate specialist and Discovery work.

What happens after you return the brief?

Emote reviews the information and supporting material, identifies material assumptions and gaps, and recommends the smallest credible next step. A clear, contained scope may support a defined proposal. A straightforward public-facing site with contained unknowns may fit Focused Website Discovery. Ecommerce, portals, logins, custom workflows, complex data or integrations, significant migration, multisite or multilingual programmes, regulated requirements or other material unknowns require Full Website Discovery before implementation scope, programme and investment can be fixed.

The completed brief is an input to pathway selection, not a promise that every project is ready for a fixed implementation proposal.

Frequently asked questions

How detailed should a website brief be?

Detailed enough to explain outcomes, audiences, quantities, constraints, responsibilities, known systems and open questions. It does not need to contain the final architecture, sitemap or integration specification.

Do I need technical answers before contacting an agency?

No. Record what your organisation knows, identify the system or requirement owner and write “Please recommend” where validation is needed. Invented technical answers create more risk than honest unknowns.

Should I include a budget?

Yes. State whether the range is approved, indicative or still to be confirmed, what it includes and which third-party costs sit outside it. This helps test whether scope, timing and investment can align.

Is a completed brief enough for a fixed quote?

Sometimes, when the scope is clear and contained. Complex integrations, ecommerce, portals, custom workflows, substantial migration, multisite or regulated requirements normally require Full Website Discovery before implementation can be fixed responsibly.

What is the difference between a brief and Discovery?

A brief records the client’s current understanding. Discovery tests that understanding, resolves material decisions and produces the approved Functional, Technical and Governance delivery baseline.

Should I choose a platform in the brief?

Only present a platform as fixed if it is a genuine, informed constraint. Otherwise record it as a preference and explain why. Platform suitability should be tested against the operating, content, commerce, integration and governance requirements.

What supporting material should I attach?

Useful examples include current or proposed sitemaps, content inventories, analytics summaries, brand guidelines, approved research and high-level architecture or integration documentation. Share only material you are authorised to provide.

What information should not be attached?

Do not include passwords, access codes, credentials, source code, live customer or staff records, production exports or other sensitive material. Agree a secure transfer method first if protected information needs review.

Can I use the template for a simple brochure website?

You can, but many fields will not apply. Emote also uses a shorter brief for one straightforward, public-facing marketing website. This template is intended for substantial websites and digital platforms where more context is needed.

How Emote can help

Emote combines website strategy, user experience and interface design, development, search migration and digital transformation capability. That matters when the website sits across customer experience, content operations and business systems rather than operating as a standalone marketing asset. See Emote’s digital transformation capability and examples of website and ecommerce work.

Emote will review the completed brief and recommend the smallest credible pathway. A clear, lower-complexity scope may support a defined proposal or Focused Website Discovery. Ecommerce, portals, logins, custom workflows, complex data or integrations, multisite or multilingual programmes, significant migration, regulated requirements or other material unknowns require Full Website Discovery before implementation scope, programme and investment can be fixed.

Download the editable template, align the right stakeholders and return it with non-sensitive supporting material. If you would like to talk through the project first, book a website scoping conversation with Emote.