A good brief makes uncertainty visible

You do not need to arrive with a finished sitemap or a folder of perfect copy. A useful website brief explains what you know, identifies what you do not know, and gives the studio enough context to propose the right work. Its purpose is shared understanding, not making every design decision in advance.

Begin with a short description of the business and the problem the website must solve. ‘We need a modern website’ leaves room for very different interpretations. ‘Prospects cannot tell which of our three services fits their project’ gives the team a concrete communication problem to work on.

Describe your audience and desired action

Name the people who will use the site and what they already know. A returning customer looking for support has a different task from a first-time buyer comparing providers. If you serve more than one audience, explain which journey matters most at launch.

Then describe the next action. For an architecture practice, the path might be: see relevant projects, understand the approach, and enquire about a residential commission. That sequence gives content and design a direction. It also helps distinguish a necessary feature from something that simply looks interesting.

  • Who is the primary visitor, and why are they looking now?
  • What should they understand before contacting you?
  • What action should they take?
  • What questions or objections usually appear before a sale?

Inventory the content and functionality

List what exists: approved copy, brand files, product information, photographs, case studies and current analytics access. Mark each item as ready, needing work, or missing. Someone should own every missing item; otherwise content becomes an invisible dependency that delays the build.

Separate required functionality from future ideas. Booking, payments, a CMS, customer accounts and third-party integrations all affect scope. Name any system you already use, but do not include passwords in the brief. Access can be arranged later through an appropriate secure method.

  • Required pages and languages.
  • Content to reuse, rewrite or create.
  • Forms, booking tools, payments or integrations.
  • Editing needs after launch and who will maintain the site.
  • Existing URLs that need to remain available or redirect correctly.

Explain references rather than collecting screenshots

Three references with clear notes are often more useful than twenty links. Explain whether you like the spacing, image treatment, navigation, typography or interaction. A reference can be visually appealing while solving an entirely different business problem.

Also name what you want to avoid. If you dislike tiny text, constant movement or a corporate tone, say so. Keep the distinction between a preference and a requirement: preserving an existing logo is a constraint; liking a particular animation is a direction to explore.

Agree the boundaries before production

Share your intended launch window and any immovable event. Explain whether the budget is fixed or whether you need options. Ask the studio to state what its proposal includes: page count, content support, revisions, testing, handover and any ongoing costs.

Finish with a simple example of success, such as ‘A new visitor can choose the right service and send a relevant enquiry on mobile.’ Avoid assigning an arbitrary sales target to design alone. Traffic quality, the offer and the sales process also affect commercial outcomes. A clear brief keeps those responsibilities visible and makes the eventual proposal easier to evaluate.