A useful website brief should explain why the project exists, who the site must help, what success looks like, what is in scope, who will decide, the budget range and the key dates.
It does not need to map every page or choose the final design. That work should come after research.
A good brief gives the project clear edges without closing the door on better ideas.
Keep the first brief short
A website brief is a starting point. It is not the full plan.
A short brief is often more useful than a large file full of guesses. Aim for clear facts, open questions and firm limits. Your agency can then test the brief during discovery.
If you are still choosing a partner, our guide to choosing the right web design agency shows what else to look for in a proposal and team.
1. State the problem
Start with why the work is needed now.
Do not lead with “We need a new website.” That is a solution. Name the problem behind it.
For example:
- People cannot find key services.
- The site no longer fits the brand.
- Staff find updates slow or hard.
- The site does not support a new plan.
- Old tools create risk or extra work.
Add any proof you have. This may include common questions, search terms, form issues, staff feedback or site data. Mark what is known and what still needs to be checked.
2. Name the people and their main tasks
List the main groups the website must help. Keep the list focused.
For each group, write the main task they need to complete. A school may need to help a future family book a tour, while a not-for-profit may need to help a person find support or make a gift.
Avoid broad lines such as “The site is for everyone.” They do not help the team make choices.
3. Set clear goals
Write three to five goals for the project. Tie each goal to a real change.
- Make key paths easier to find.
- Give the team more control over content.
- Build trust with clear proof.
- Improve access for people with different needs.
- Make forms and tools easier to use.
You do not need a number for every goal on day one. You do need to agree on what better means.
4. Draw the scope
Say what the project should cover and what it should not cover.
Include known needs such as:
- Website strategy and user research.
- Site structure and content planning.
- Copy, design and development.
- Forms, search, maps or other tools.
- Links to a CRM, payment tool or staff system.
- Content entry, redirects, testing and training.
- Support after launch.
Also list work that sits outside the project, such as a brand change, new photography or a separate staff portal. This makes quotes easier to compare.
IGNITE’s website design and development capabilities can help you see the kinds of work that may sit inside a full website project.
5. Be honest about content
Content is a common cause of delay.
Say who will write, review and approve it. Note how much old content exists. List any files that must move. Flag content that needs legal, policy or expert review.
Do not assume old copy can move as it is. A rebuild is a good time to keep what helps, fix what is weak and remove what no longer has a job.
6. Share the rules and needs
List the things the project must respect.
This may include brand rules, access needs, privacy, security, hosting, browser support, data storage or links to other tools. Name any fixed platform only when it is truly fixed.
It also helps to share what your team must be able to update after launch. The editor experience is part of the website, even though visitors do not see it.
7. Name the team and decision path
List the project lead, key reviewers and final decision maker.
Say how feedback will be gathered. If a large group must review the work, explain when they join and what they can decide.
One clear decision path saves time. It also stops late feedback from changing work that was already approved.
8. Give a real budget range and timing
A budget range helps an agency shape the right plan. It can show what should happen now, what can wait and where trade-offs may sit.
If you need an early guide, read about custom website costs in Australia. The final fee will still depend on scope, content, tools and risk.
Share any fixed date and why it matters. Also list dates that are a goal, not a hard limit. Our guide to website redesign timelines explains what can make a project shorter or longer.
Do not solve the whole project in the brief
Leave room for the team to learn.
A brief can include ideas, examples and must-have needs. But it should not lock in a full site map, exact page count or design before users, content and tools have been reviewed.
Mark each point as one of these:
- Fixed: It cannot change.
- Preferred: It is your current choice.
- Open: You want the agency to advise.
This simple step makes hidden assumptions easier to spot.
A simple website brief checklist
Before you send the brief, check that it covers:
- The problem and why the work matters now.
- The main users and tasks.
- Three to five project goals.
- Work that is in and out of scope.
- Known content, tool and access needs.
- The project team and decision path.
- The budget range and key dates.
- Fixed points, preferred ideas and open questions.
Then share useful source material. This may include brand files, site data, research, staff notes and examples of work you like. IGNITE’s website case studies may help your team talk about the kind of outcome and experience you want.
Use the brief to start a better talk
The best brief does not remove every question. It helps the right questions come up early.
That gives your team and agency a shared base for discovery, scope and planning. It also makes it easier to explain the project inside your organisation.
If you are planning a website rebuild and want help shaping the brief, talk to IGNITE.