How to write a useful website project brief

Start with one primary goal

Write a sentence about the people you want to reach and the action that matters most. For example: “Help local customers understand our repair services and request an estimate.”

Then describe what visitors need to know before they can take that action. A useful website may need to explain service boundaries, show actual work, answer common questions or make the next step easier to find. Prioritize those needs before choosing layouts.

• Who is the main audience?
• What question brings them to the site?
• What should they do next?
• How will you decide whether the finished site meets the brief?

List the pages and the content you have

Make a short page list and give each page a job. A service overview helps visitors choose; a service detail page explains fit and scope; a contact page makes an inquiry possible. Separate pages are useful when they answer different questions.

Alongside the list, note which words, photos, logos and examples are ready, which need work and who can approve them. Include only material you have permission to use. Missing content is a planning dependency, so flag it before a launch date is set.

• Page name and the question it answers
• Existing copy and photos that can be reused
• New material or editing needed
• Person responsible for feedback and approval

Describe features as real tasks

“We need a form” leaves a lot unanswered. Explain who completes it, what they submit, who receives the information and what should happen if delivery fails. Do the same for booking, payments, account areas and connections to other services.

Separate essential launch features from useful later improvements. Mention the systems you already use, but do not assume every account or subscription supports an integration. Compatibility and permissions need to be checked during scoping.

Record what must stay intact

If you already have a website, include its public URL and list the pages, downloads, forms and customer workflows that must survive the change. Explain how you currently edit content and what you want to manage yourself after handover.

Also identify the domain, hosting and business email providers by name if you know them. This is an inventory, not a request for access. Do not put passwords, API keys, customer records or payment details in the brief or inquiry form.

Make the quote and handover easier to define

Share the target date and explain whether it is tied to a real event or simply a preference. Include a budget range if you have one, the decision-maker and any periods when feedback will be difficult. These details help identify a workable scope.

Ask the proposal to distinguish the initial build from later hosting, maintenance, content changes and support. Agree what will be handed over and how acceptance will be checked. Sending a brief starts the conversation; it does not accept a quote or book work.

• Goals, audience and the primary visitor action
• Page list, content status and essential features
• Existing website, systems and items to preserve
• Target timing, available budget and approval contact