Website brief vs paid Discovery: what should each stage achieve?

Why can an agency prepare a defined proposal for one website but ask another organisation to complete paid Discovery first?

The answer is not simply project size, page count or how polished the initial brief appears. It is the difference between information the organisation already knows and consequential questions that still need investigation, analysis and agreement.

A website brief is a structured starting point. It records the business context, objectives, audiences, known scope, constraints and commercial expectations. It helps an agency assess the likely pathway and identify gaps.

Paid Discovery is an evidence-led engagement. It resolves material unknowns that could change what should be built, how it should work, which systems and data are involved, how risk should be managed, or whether the original solution is appropriate at all.

Treating the two as interchangeable creates problems in both directions. Asking a client to perform its own Discovery shifts specialist work into an unpaid form. Treating a basic brief as an implementation blueprint creates false certainty around untested assumptions.

The correct principle is simpler:

A brief should tell the agency what is known. Discovery should resolve what is important but not yet known.

The short answer

	Website project brief	Paid website Discovery
Primary purpose	Capture known context and help assess the right next step	Investigate and resolve consequential uncertainty
Main owner	Client input, supported by agency clarification	Agency-led research, facilitation, analysis and validation with client stakeholders
Typical content	Objectives, audiences, known scope, content, functionality, systems, timing, governance and investment context	Users and journeys, requirements, content model, systems and data, architecture direction, risk, governance and roadmap
Level of certainty	Facts, preferences, estimates and clearly labelled unknowns	Evidence, recommendations, trade-offs and validated decisions
Commercial status	Pre-project input; not implementation authorisation	Separate paid engagement; not implementation authorisation
Likely next step	Defined proposal, targeted clarification or Discovery recommendation	Separately scoped implementation, phased next step, further validation or a decision not to proceed

What a strong website brief should achieve

A good brief gives the agency enough commercial and operational context to understand the request. It does not need to answer every technical question.

Emote’s current Website Project Brief asks organisations to explain what they know across the following areas.

1. Business context and objectives

Why is the project being considered now? What outcome must change? Is the website expected to improve credibility, qualified enquiries, bookings, sales, self-service, recruitment or operational efficiency?

This matters because the same visible website can carry very different responsibilities. An informative corporate site and an authenticated customer platform should not be scoped through page count alone.

2. Priority audiences and journeys

Who must the website serve, what does each audience need and which actions matter? Multiple audiences are not automatically complex, but competing journeys, permissions, languages or accessibility needs may change the information architecture and delivery approach.

3. The current position

For an existing website, the brief should identify the current platform, support and hosting relationships, analytics access, known strengths, known problems and anything that must be retained. Evidence is more useful than a broad instruction to make the site modern.

4. Structure, quantities and content readiness

Approximate pages, page types, locations, profiles, products, downloads and media help separate content volume from design-template volume. The brief should also identify who will create, approve, populate and maintain the content.

5. Known functionality

List what the website must enable, who uses it and what should happen afterwards. A request such as “online quote” is not yet a requirement. Does it calculate a binding price, collect information for review, apply product rules, create a CRM record or trigger an operational workflow?

The brief does not need to design the solution. It should make the intended outcome and known boundary visible.

6. Systems, data and complex capabilities

If the website may connect to CRM, ERP, inventory, authentication, membership, payments or other platforms, identify the systems, owners and available documentation. Mark unconfirmed integrations as assumptions rather than presenting them as solved.

7. Governance, timing and investment context

Who owns the outcome, budget, content, technology and final decision? Which date is genuinely fixed, and why? What investment range has been allowed for the complete programme, including content, licences, migration and post-launch needs?

A withheld budget does not make an agency more objective. It can lead both parties to explore a pathway that was never commercially possible.

8. Quality and operating expectations

Existing organic visibility, analytics, accessibility, privacy, security, performance, availability, data residency and ongoing support can materially affect the solution. The brief should identify formal standards and responsible advisers without asking a marketing manager to invent a security architecture.

A good brief is allowed to contain unknowns

The purpose of the brief is not to create artificial certainty. “To be confirmed” and “Please recommend” are useful answers when they are honest.

The agency’s first job is to classify the gap:

Known requirement: sufficiently clear to include in a defined scope.
Ordinary detail: can be clarified through a question, assumption or bounded allowance.
Consequential unknown: could change platform, architecture, workflow, programme, investment or risk.
Untested solution assumption: describes what somebody wants to buy before the underlying problem has been validated.

For example, the number of standard enquiry forms may be an ordinary detail. Whether customer-specific prices must synchronise from an undocumented ERP is consequential. A preference for Shopify or WordPress may be helpful context; it is not a validated platform decision when the operating requirements are unresolved.

An incomplete brief alone does not justify paid Discovery. The missing information must matter enough that guessing would be commercially irresponsible.

What a website brief should not be expected to deliver

A pre-project brief should not quietly become a free audit, strategy or implementation blueprint.

Unless separately engaged, completing and reviewing a brief does not provide:

User research or validated personas
A final sitemap or information architecture
Wireframes, prototypes or interface design
Platform recommendation supported by technical investigation
Solution architecture or complete integration specifications
Detailed content, search or data-migration plans
Security, privacy, accessibility or performance audits
A prioritised product backlog and delivery roadmap
Fixed implementation certainty around unresolved requirements

This boundary protects the client as much as the agency. A few speculative diagrams created during sales can look authoritative without the evidence, stakeholders or technical access needed to support them.

What paid Discovery should achieve

Paid Discovery is a decision-making phase. Emote uses the approved pre-project brief as its starting point, gathers source material, facilitates the right stakeholder conversations, investigates the current position, develops recommendations and validates decisions.

The Australian Government’s Discovery-stage guidance is written for public services, but its central principle applies more broadly: understand users and the whole experience before designing and building. Its research guidance also distinguishes generative research about whether the team is designing the right thing from later evaluation of whether it is being designed well.

In commercial website work, the exact Discovery scope must match the project. Depending on the accepted engagement, decisions may cover:

Functional direction

Business outcomes, scope boundaries and priorities
Priority audiences, tasks and user journeys
Sitemap, page types and content relationships
Forms, workflows, administration and capability requirements
Launch scope, later phases and acceptance intent

Technical direction

Platform recommendation and high-level architecture
Integration purpose, data movement and sources of truth
Migration scope and data readiness
Hosting requirements and operational responsibilities
Accessibility, security, privacy, performance, search and measurement boundaries

Emote does not sell or directly provide hosting infrastructure. Discovery can define requirements, assess the existing arrangement and inform coordination with an appropriate hosting partner or the client’s suitable provider.

Governance and delivery direction

Stakeholder roles and decision rights
Dependencies, assumptions and risks
Validation, testing and assurance responsibilities
Phasing, roadmap and implementation-estimate basis
Recommended next-step pathway

The accepted Discovery proposal governs the exact inclusions. Final wireframes, interactive prototypes, visual design, complete API specifications and production implementation are not automatically included. They should only be promised when the approved engagement expressly includes them.

When is the brief enough to prepare a proposal?

A defined implementation proposal may be responsible when:

The website’s business job and priority users are clear
Scope quantities and content responsibilities are reasonably understood
Functionality relies mainly on established, standard patterns
Integrations are absent, standard or sufficiently documented
Migration is limited and its source is understood
Decision-makers are aligned and approvals are workable
Quality and compliance requirements fit a known delivery approach
Assumptions can be stated without hiding material risk

The proposal should still identify inclusions, exclusions, client responsibilities, third-party costs and change control. “Clear enough to quote” does not mean every detail is known; it means remaining detail can be managed inside a dependable boundary.

When is targeted clarification enough?

Sometimes the brief is almost complete. The agency may need page quantities, a content owner, confirmation of a standard form destination or access to an existing sitemap.

These gaps do not automatically warrant a separate paid engagement. A focused qualification conversation or written clarification may resolve them. This is an important discipline: recommend the smallest credible next step, not the largest process available.

When should paid Discovery come first?

Discovery is appropriate when material questions remain across one or more connected areas, such as:

Customer, trade, member, staff or partner portals
Complex ecommerce pricing, account, product, fulfilment or subscription rules
Calculators, selectors, quotation tools or workflow automation
Several integrations or poorly documented legacy systems
Significant content, product, customer or operational-data migration
Multiple brands, sites, regions, languages or location models
Material organic-search migration risk
Formal accessibility, privacy, security or regulatory obligations
Conflicting stakeholders, unclear governance or unvalidated programme assumptions

Emote uses proportionate Discovery pathways. A Focused Discovery can address a bounded set of consequential questions. Full Website Discovery is more appropriate when functional, technical and governance decisions are interconnected across a broader platform or transformation. The final recommendation and inclusions must come from current approved collateral, not the label alone.

Why Discovery is a separate paid engagement

Discovery produces reusable business value. It asks the agency to facilitate stakeholders, review evidence, analyse systems and content, evaluate trade-offs, document decisions and create a dependable basis for the next investment.

That work exists whether or not the same agency later implements the recommendation. Making it free creates pressure to rush, prescribe the agency’s preferred build or recover the cost invisibly inside implementation.

Paid Discovery also preserves a valuable decision point. It can recommend a simpler solution, a phased programme, improvement of the current website, further technical validation or not proceeding with the original proposal.

It does not itself authorise implementation, reserve delivery capacity or create a fixed implementation quotation. It is not credited against implementation unless Emote expressly agrees otherwise in writing.

A practical example: Primary Dental

Primary Dental required a central website for a network of more than 60 practices. The public Emote case study identifies connected considerations across practice and practitioner content, multiple integrations, organic-search migration, transition planning and security advice.

The visible request was a website. The underlying decisions crossed users, locations, content, systems, search, security and launch governance. Emote worked through Discovery, wireframing, UX/UI design, development and implementation.

The lesson is not that every multi-location site needs the same process. It is that a high-level brief can identify the shape of the challenge while Discovery establishes how the connected parts should work.

What should happen after Discovery?

The approved output should create an explicit decision, not merely a presentation.

Possible next steps include:

A separately scoped implementation proposal
A phased programme with dependencies and decision gates
A smaller or different solution than initially expected
Targeted validation of a vendor, integration or migration assumption
Improvement of the current website instead of replacement
Deferral until data, governance, budget or technology is ready
A decision not to proceed

If Emote is engaged for implementation, the Discovery decisions only become the binding delivery baseline when incorporated into the separately approved implementation scope or statement of work.

Questions to ask an agency about its Discovery process

Before approving Discovery, ask:

Which material decisions is the engagement expected to resolve?
What evidence and access will the agency require?
Which stakeholders need to participate or approve decisions?
Which outputs are included, and which are expressly excluded?
Will the output state assumptions, risks, dependencies and deferred items?
How will recommendations be validated?
What commercial decision should be possible at the end?
Does the client retain the approved output if a different implementation partner is selected?

These questions reveal whether Discovery is a genuine decision phase or only an extended sales workshop.

Frequently asked questions

Does every website need paid Discovery?

No. A straightforward website with clear, controlled requirements may move from a useful brief and targeted clarification to a defined implementation proposal.

Is a brief the same as a scope of work?

No. A brief is an input to assessment and scoping. A scope of work is the approved commercial definition of what will be delivered, under which assumptions, responsibilities and terms.

Should the client choose the platform in the brief?

The client should record any preference, existing commitment or internal standard and explain why it matters. The agency should not treat a preference as validated when unresolved requirements could change the platform decision.

Does Discovery include wireframes?

Not automatically. Discovery may define journeys, content structure and requirements that inform later wireframes. The accepted proposal must state whether any wireframes or prototypes are included.

Is Discovery part of the implementation fee?

Not by default. Emote treats Discovery as a separate paid engagement. It is not credited against implementation unless Emote expressly agrees in writing.

Does completing Discovery commit us to use Emote for the build?

Discovery does not itself authorise implementation. The approved output should support a separately considered next investment. Any rights to use or share deliverables remain subject to the accepted agreement and terms.

Can Discovery conclude that we should not rebuild?

Yes. Preventing investment in the wrong solution is a valid outcome when the evidence supports improvement, phasing, deferral or another direction.

Use the brief to expose uncertainty, then resolve it proportionately

A website brief and paid Discovery both create clarity, but they operate at different depths.

The brief should make known facts, objectives, constraints and unknowns visible. The agency should then determine whether the project can be responsibly proposed, needs targeted clarification or contains consequential uncertainty that warrants paid Discovery.

Discovery should turn that uncertainty into evidence, recommendations and validated decisions. It should not be used as an automatic toll gate, disguised implementation or free pre-sales work.

Explore Emote’s Websites and eCommerce and Digital Transformation capabilities for the range of pathways available.

If you have a website project in mind, book an initial qualification meeting with Emote or ask for the appropriate Website Project Brief. Emote will review what is known, identify the material gaps and recommend the smallest credible next step.