A useful web design brief explains the business problem, audiences, current site, required content, integrations, constraints, decision process and launch expectations without prescribing every solution.

Give providers enough context to diagnose the work and compare approaches. State the problem and constraints clearly, while leaving room for a better structure or implementation recommendation.

A brief describes a problem, not a solution

The most common briefing mistake is arriving with a specification: page count, features, a list of sites to imitate. That format hides the information a supplier actually needs and prevents anyone proposing something better than what you already imagined. The useful brief describes the situation and lets the proposal argue for a structure.

  • Weak brief: eight pages, a blog, a slider, something like this competitor.
  • Useful brief: enquiries arrive unqualified and the team cannot publish.
  • Prescribing the solution guarantees you only get what you already thought of.

Explain why the project exists now

Describe the business change, visitor problem or operational constraint that triggered the work. Separate measurable goals from visual preferences. The word "now" matters: something changed to make this worth budget and attention, and that something is usually the real brief.

  • What changed in the business or the market?
  • What does the current site prevent you from doing?
  • What would be different if the project succeeded?

Describe audiences and page responsibilities

List the people the site serves, the questions they bring and the action each important page should support. Include an existing route inventory when the project is a redesign. Suppliers can design for a described visitor; they cannot design for an unstated assumption.

  • Who are they, and what prompts them to look?
  • What must they understand before making contact?
  • What objection stops them, and where is it answered?

Document content, proof and integrations

State what copy and media exist, which claims are approved, who owns content and which forms, CRM, analytics, booking or data tools must work. Content readiness is the single largest variable in any estimate, so leaving it unstated guarantees the estimate is wrong.

  • Identify missing evidence.
  • Share representative real content.
  • Name integration access owners.
  • Say plainly who will write anything that does not yet exist.

What a good supplier will ask if you leave it out

Anticipating these questions shortens the process considerably. If a supplier does not ask them, that is itself informative: a quote produced without this information is a guess.

  • Who has final approval, and how many people review?
  • Does the copy exist, and who writes what is missing?
  • Which integrations must survive, and who controls access?
  • Is there a fixed date, and what is driving it?
  • What budget range makes this project realistic?

Clarify process and constraints

Provide target timing, budget context, stakeholders, review expectations, technical requirements and known risks. Avoid a hard date that ignores unresolved dependencies. A deadline set without regard to content readiness is a wish rather than a constraint, and everyone involved will discover that at the same late moment.

  • One named decision owner with final say.
  • A realistic date for content, not only for launch.
  • Known risks stated rather than discovered.

Practical decision checklist

  • State the business problem, not the page count.
  • Explain what changed to make this urgent now.
  • Identify audiences and the actions they take.
  • Share current routes and representative content.
  • List CMS, integrations and access owners.
  • Name one decision-maker and the real constraints.

Frequently asked questions

Should a web design brief specify the platform?

Only when the platform is a genuine requirement. Otherwise explain the operating needs and let the proposal justify the recommendation.

Do I need final copy before requesting proposals?

No, but providers need to understand content responsibility, readiness and representative length to estimate responsibly.

Should I disclose a budget?

Budget context can help providers recommend a realistic intervention and avoid proposing a system that cannot be funded.

How long should a brief be?

Two pages of specifics beat twenty of generalities. If it does not contain the problem, the audience, the content position and the decision process, length will not compensate.

Should I send the same brief to several suppliers?

Yes, otherwise the responses are not comparable. Differences between proposals then reflect approach rather than differing information.