How to write a website brief that leads to a useful proposal

A website brief does not need to predict every page, feature, or design decision. Its job is to give potential partners enough context to understand the business problem, identify uncertainty, and propose a sensible route forward. A useful brief creates alignment. A weak brief asks for “a modern website” and leaves every important word open to interpretation.

The best briefs are short enough to read and specific enough to guide a conversation. They explain what must change, who the website is for, what visitors should do, and which practical constraints shape the project. The supplier can then challenge assumptions, recommend an appropriate scope, and price comparable work.

Begin with the business situation

Describe the organization in plain language. Explain what you sell, where you operate, who buys from you, and how customers currently find or contact you. Then state why the project is happening now.

Perhaps the existing website looks unreliable on mobile. Maybe the business has changed its services, opened a second location, or relies too heavily on social media. A new organization may need a credible first presence before a launch. These are more useful starting points than a list of visual preferences because they reveal the decision the website must support.

Include the current website, if one exists, and any channels that matter: Google Business Profile, Instagram, booking platforms, directories, or offline referrals. Mention what already works. A redesign should not remove a useful contact path or a page that consistently attracts qualified visitors merely because it looks old.

Define one primary outcome

Most business websites can support several actions, but one should lead the hierarchy. It might be a phone call, reservation, appointment request, visit, donation, quotation request, or project enquiry.

Write the outcome as an observable action: “help restaurant guests reserve a table” is clearer than “increase engagement.” Add secondary actions only when they genuinely matter, such as viewing a menu, checking opening hours, or downloading a document.

Avoid promising a numerical result without evidence. A website influences demand, trust, and conversion, but pricing, reputation, capacity, sales follow-up, and traffic quality also affect the final result. The brief should define what the website can reasonably improve and how the team will recognize progress.

Describe the priority audiences

“Everyone” is not an audience. List the two or three groups whose needs most affect structure and content. For each group, explain what they need, what they already know, what may make them hesitate, and which action they should take.

A clinic may serve patients, parents, and referring professionals. A restaurant may need to help local guests, tourists, and event organizers. A professional service may speak to owner-led businesses and larger organizations with different procurement expectations.

Useful audience detail is behavioral, not decorative. Device use, language, urgency, accessibility needs, geographic area, and decision criteria can all change the design. Invented personas with arbitrary hobbies rarely help.

Inventory content before choosing page count

List the information that must be published: services, team, locations, prices, menus, case studies, FAQs, accreditations, policies, contact details, or resources. Mark what already exists, what needs updating, and what must be created.

Do not assume the supplier can discover accurate facts from scattered messages. Name an internal person who can confirm claims and approve final text. If photography, translation, legal review, or specialist writing is required, state whether it is available or should be included in the proposal.

This inventory helps determine page structure. Five focused pages may be enough for a small service business. Another organization may need fewer public pages but complex resources or multiple location templates. Page count should follow content and user tasks, not an arbitrary package alone.

Separate essential functionality from ideas

Describe what visitors must be able to do. Examples include sending an enquiry, calling with one tap, requesting an appointment, filtering locations, reading in two languages, or accessing a downloadable guide.

Then separate essential launch requirements from possible later additions. A standard contact form is different from a booking system that checks staff availability, takes payment, sends reminders, and synchronizes calendars. A managed article section is different from a full editorial platform with roles, previews, and approval workflows.

Mention integrations by name when known, including CRM, newsletter, analytics, maps, payment, or scheduling providers. Note whether accounts already exist. This prevents a simple-sounding feature from hiding subscription costs, data migration, or operational work.

State practical constraints openly

Give a realistic budget range or ceiling. Budget is not merely a negotiation signal; it helps a partner recommend the right level of custom work and avoid proposing a system the organization cannot sustain.

Include a target date and the reason behind it. A fixed event, opening, or campaign is different from a preference to finish quickly. Identify who makes decisions, how many stakeholders will review work, and how quickly feedback can usually be returned.

Also mention technical or organizational constraints: an existing domain, required hosting region, internal IT policies, legacy content, accessibility expectations, or a platform that must remain. Surprises discovered during development cause more delay than honest constraints listed at the beginning.

Clarify ownership and responsibilities

The brief should ask who will own the domain, hosting, source code, design files, analytics, and third-party accounts after launch. Business-critical accounts should normally be registered to an address controlled by the organization, with the supplier receiving appropriate access.

Define who supplies text, images, translations, privacy information, and approvals. Ask what maintenance includes, how issues are reported, which updates are covered, and how new functionality is estimated. “Support included” is too vague without a duration and boundary.

These questions are not signs of distrust. They create a cleaner working relationship because both sides understand what handover and ongoing operation mean.

Invite recommendations alongside estimates

End with the decisions you want the proposal to answer. Ask for the recommended scope, assumptions, exclusions, timeline, payment stages, project process, and examples of relevant work. Ask suppliers to identify risks or alternatives rather than silently pricing every request.

Compare proposals by outcome and responsibility, not only by the total. One may include content structure, responsive quality assurance, analytics, search foundations, launch support, and maintenance. Another may cover only a visual template and leave essential work to the client.

A good brief does not lock the project before discovery. It gives the conversation a solid floor. When the business context, audience, content, actions, constraints, and ownership are visible, a web partner can spend less time guessing and more time designing the right solution.