How to Write a Website Brief That Gets You Accurate Quotes and Better Results

Most web design projects run into problems that were entirely avoidable. Scope disagreements, missed requirements, unexpected costs, and redesigns mid-build almost always trace back to the same root cause: no one wrote down what the website actually needed to do before the work started. A website brief is not a bureaucratic formality. It is the document that forces the business to make the key decisions early, when changing them is cheap, rather than late, when it costs time, money, and goodwill on both sides.

A business owner and a web designer reviewing a printed website brief and wireframe sketches beside a laptop.

What a website brief is actually for

A brief serves two people simultaneously. For the business owner, writing it forces clarity about the purpose of the website, the audience it serves, the content it needs, and the outcome it should produce. Many businesses discover during this process that they have not yet agreed internally on what the website is supposed to do. That is a useful discovery to make before paying a designer to interpret the ambiguity.

For the web designer or agency receiving it, a well-written brief is the difference between quoting accurately and guessing. A designer who understands the commercial goal, the required pages, the content situation, the integrations needed, and who will maintain the site after launch can produce a realistic quotation. One working from a vague request for a professional website with five pages and a contact form cannot, and the gap between the two tends to appear as a surprise invoice rather than an upfront conversation.

Start with commercial purpose, not visual preferences

The most useful section of any website brief is a clear statement of what the website is expected to do commercially. Not what it should look like, but what problem it solves and for whom. A service business might write: the website needs to help prospective clients understand our accounting services, assess whether we are credible, and make an enquiry. That single sentence contains the audience, the content job, and the conversion goal, which is more useful than three paragraphs describing a preference for clean, modern design.

Visual references and style preferences have their place, but they belong after the commercial framing, not before it. A designer who understands the purpose can evaluate whether a visual direction supports or contradicts it. One given only a mood board and a page count has no anchor for those decisions.

If the website needs to serve more than one audience, note each one separately and describe what that audience needs to find and do. A corporate training company might serve both HR managers evaluating course options and individual employees looking for specific certifications. Those two visitors have different questions and may need different navigation paths. Identifying them in the brief allows the designer to plan the information architecture around real journeys rather than assumptions.

The content section most briefs skip entirely

Content readiness has a larger effect on project timeline and cost than most businesses expect. A brief that specifies the number of pages without addressing where the content will come from is incomplete in a way that will cause problems. If the business has approved copy, photography, case studies, and team profiles ready to hand over, the project can move quickly. If none of that exists, the brief should say so, because writing, editing, sourcing, and approving content is a significant part of the project's total work.

List each page the website needs and, next to each one, note the content status honestly: ready, needs updating, needs to be written from scratch, or unclear. This single exercise often reveals that a planned five-page website is actually a ten-page content production project, or that the main service page has not been clearly defined yet. Better to surface that now than to discover it when the design is waiting for copy that does not exist.

If the business expects the web designer or agency to write or edit copy, say so explicitly. Some agencies include copywriting as part of their service. Others quote only for design and development and assume the client supplies finished text. Neither approach is wrong, but the assumption should be stated rather than discovered when a half-finished page is sitting in a staging environment.

Technical requirements and integrations to specify clearly

A website that needs a booking system, a payment gateway, a CRM connection, a multilingual toggle, a custom product configurator, or a members-only section is a materially different project from one that needs a contact form and a blog. Each integration adds scope, testing, third-party dependencies, and ongoing maintenance responsibility. These should be listed in the brief even if the technical details are not fully known, because their presence changes the feasibility, timeline, and cost of the project.

Also note the platform preference if one exists, and whether the business has strong reasons for that preference. A business that has invested in learning WordPress and wants to continue using it is making a reasonable operational choice. A business that simply heard WordPress is common may benefit from the designer recommending the most appropriate tool for the specific requirements rather than defaulting to a familiar name. The brief should distinguish between a firm requirement and an open question.

Specify who will maintain the website after launch and at what level of technical comfort. A team member who needs to update service descriptions and publish blog posts has different needs from a business owner who wants the site to run without any ongoing intervention. Maintenance expectations shape platform choice, CMS configuration, and the level of documentation the designer should provide at handoff.

Budget and timeline: why including them helps rather than harms

Many businesses withhold budget information from a brief in the belief that it will result in a higher quote. The opposite is more often true. A designer who knows the available budget can scope a project that fits it rather than proposing a full-service engagement to a client who needed something simpler, or underquoting for a client who would have paid for a more thorough approach.

Providing a budget range, even a broad one, allows the designer to be honest about what is achievable within it. If the requirements exceed what the budget allows, that conversation is more productive when it happens before work starts. It might result in phasing the project, simplifying certain features, or clarifying which elements are essential versus desirable. All of those are useful outcomes that a brief without budget information tends to delay until an uncomfortable moment in the project.

Timeline is worth including for similar reasons. A business that needs a website live before a conference in six weeks is working under different constraints from one that can take four months. Unrealistic timelines affect quality and cost. If the deadline is fixed, state it and let the designer assess feasibility. If it is flexible, say so, because a more relaxed timeline often allows for more thorough work at the same cost.

A practical brief outline worth following

A brief does not need to be long to be useful. For most small business websites, a document covering the following six areas is sufficient to produce an accurate quotation and a shared understanding of the project. First, the business context: what the company does, who the customers are, and what the website is expected to achieve commercially. Second, the audience: who will use the website and what they are trying to find or do. Third, the pages and content: a list of required pages and the current content status for each. Fourth, technical requirements: integrations, platform preferences, and who manages the site after launch. Fifth, references: two or three websites whose structure, tone, or specific features the business finds useful, with a brief note on what they do well. Sixth, budget and timeline: a realistic range and any fixed deadlines.

One section worth adding if it applies is what the current website is doing wrong. If there is an existing site, describing specifically what it fails to do, such as not clearly explaining the main service, loading slowly on mobile, or producing no enquiries despite reasonable traffic, gives the designer a concrete problem to solve rather than a blank canvas. The brief becomes a problem statement as much as a specification, which tends to produce better work.

After the brief is written, read it back as if you were the designer receiving it for the first time. Ask whether you could produce a realistic quotation from it. If there are obvious gaps, fill them before sending. The time invested in a thorough brief is returned many times over in fewer misunderstandings, fewer mid-project surprises, and a website that was designed to solve the right problem from the start.