Learning how to write a website brief starts with three questions. Who is the site for? What should they be able to do? How will you check that it works? Your answers give a builder a clear target.
A brief does not need fancy design words. It needs accurate facts and useful limits. You can use the same document with a designer, developer or AI website builder.
The short answer
- Start with the customer task, then list the pages and functions it needs.
- Separate launch needs from later ideas and name who approves each fact.
- Agree a check for each required task, plus who will test and maintain it.
How this guide was made
The planning advice draws on GOV.UK user research, MDN website planning and W3C form guidance. The dog grooming brief and acceptance tables are invented planning examples. They are not a supplier quote, legal agreement or promise of a build time.
Sources checked .
Start with the customer and their task
Describe the customer and choose the main task. Local dog owners asking about a first grooming visit is more useful than everyone who loves pets. GOV.UK recommends learning needs from real people and evidence, rather than treating a stakeholder guess as a proven need.
Source for this section: [1] GOV.UK guidance on learning user needs
Known customer facts
Collect common questions from calls, emails or conversations. For a groomer, people may ask which dog sizes you handle or whether a first visit needs a call. Note where each question came from without adding private customer details.
Open questions
Keep unknowns in a separate list. Give each an owner and a date to answer. If you do not know whether visitors need instant booking, do not silently add a booking system to the scope. Ask the people who handle appointments.
List pages and approved facts
List each page and the question it answers. Then gather the service details, hours, contact information and images it needs. MDN recommends planning the content and design before building.
Name the person who can approve each item. If photos are not ready, set a date and a suitable alternative the owner may approve. A missing asset should not become an invented project photo.
You can share a style reference. Say what you like, such as a readable menu or clear service cards. A reference does not give permission to use another company logo, words or photos.
Source for this section: [2] MDN guide to planning a website
Describe what each function must do
A Book now button is not a complete booking system. Describe what should happen after a click. Does the visitor choose a confirmed slot, open another tool or send a request for someone to review?
For a form, name the fields, where requests are stored and who receives them. Use a role such as the approved business inbox in a shared brief. Do not put passwords in it.
W3C recommends clear labels linked to their form fields. Ask for that check as part of the build. Separately, agree how the team will prove that a test request is saved and reaches the right place.
Source for this section: [3] W3C guidance on form labels
Separate launch work from later ideas
Use three groups to make tradeoffs clear. These sample choices belong to the fictional groomer, not every business. The owner must approve the real budget and dates.
| Group | Fictional scope | Approval rule |
|---|---|---|
| Must have at launch | Four pages, current service facts and an inquiry form | These must pass review before launch |
| Later improvement | A guide to preparing a dog for its first visit | Add when the owner has approved useful material |
| Outside this brief | Online payments and instant appointment booking | Needs a new scope, price and test plan |
Required launch tasks
Put anything needed to complete the main customer task in the launch group. Record dependencies too. Domain access, approved copy and the receiving inbox must be ready for the relevant checks.
Later improvements
Keep later ideas in a separate list with a reason for each. Before moving one into the build, agree its effect on cost, timing and testing. This protects the launch scope without losing useful ideas.
Copy this eight part website brief
Fill in each row with short, direct answers. If a decision is still open, say who will make it and when. This template is a planning aid, not a legal contract.
| Field | What to write |
|---|---|
| Customer | Who needs the site and what brings them here |
| Main task | The action a visitor should finish |
| Services and area | What you offer, where and with what limits |
| Pages | Each page and the question it answers |
| Approved material | Facts, words and images you can use |
| Functions | What forms, buttons and tools must do |
| Scope and budget | What is included now and what can wait |
| Review owner and checks | Who approves the work and what proves it is ready |
A filled example for a dog groomer
This dog grooming business is fictional. The sample scope, timing and approval roles show how to write a brief. Replace them with your facts and agreement.
The owner provides facts and photos before design starts. Copy review follows the first draft. Function tests happen after the form is connected, and launch follows the agreed checks. Put real dates beside those stages once the people doing the work agree.
In this example, the team reviews the grooming request and contacts the dog owner. Sending the form does not book an appointment. The wording must match that process.
| Field | Example answer |
|---|---|
| Customer | Local dog owners who want to ask about a first grooming visit |
| Main task | Send a grooming enquiry |
| Services and area | Wash, brush and nail care within the owner's approved service area |
| Pages | Home, Services, About and Contact |
| Approved material | Owner approved service list, hours, logo and permitted photos |
| Functions | Form asks for name, contact details and dog size; no instant booking promise |
| Scope and budget | Four pages in phase one; owner confirms a written budget before work starts |
| Review owner and checks | Owner checks facts; builder and owner verify a marked form test reaches the approved business inbox |
Checks for the fictional groomer
Use observable pass rules. A checkbox marked done is less useful than a note showing what was compared or tested.
| Requirement | Responsible person | Evidence and pass rule |
|---|---|---|
| Correct services and hours | Business owner | Draft matches the dated approved fact sheet |
| Grooming request form | Builder with business owner | Agreed fields saved and test reaches approved inbox |
| Honest booking wording | Business owner | Page says request and does not promise a confirmed slot |
| Phone access | Builder | Owner can read service details and complete the form |
| Content editing | Staff member who will update it | Staff changes a draft opening time and reviews it before publication |
Turn vague wishes into clear checks
Replace make it modern with checks people can review. For example, service details are readable on a phone and the quote button reaches the right form. Assign the checks before the build begins.
Who approves content
The person who knows the service approves its facts. Name a backup and a reply date. A designer can improve the writing, but should not decide your opening hours or make up prices.
Who tests functions
The builder checks the setup. The business owner follows the customer task and checks the result where staff work. Record the test date, outcome and any open issue.
Who maintains the site
Name the person who updates facts and the person who fixes faults after launch. Ask them to show the editing process and agree what support includes. New scope requests need approval with their cost and timing recorded.
Use the brief before and after the build
Send the same brief to each provider when asking for quotes. Compare how they cover the tasks, not just the total price. Ask about anything they leave unclear.
Use it again when you review the draft. Check each required page, fact and function against what you agreed. When the work is done, keep the brief with the handover notes. It explains the purpose of the site to whoever cares for it next.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview