Start with the decision the website needs to support
A website project brief is a shared reference for the people commissioning, writing, designing and maintaining a site. Its job is not to describe every page in advance. It should explain why the work is happening and give the team a way to resolve questions as they arise. For a small organization, a concise brief that people actually use is more valuable than a detailed document that becomes outdated before the site launches.
Begin with a short description of the project and the change you want it to make. “Redesign the website” names an activity, but not a purpose. “Help prospective clients understand our services and make an enquiry” gives the team a clearer test for choices about navigation, content and calls to action. If the site has several goals, put them in priority order. That way, a secondary wish, such as displaying every past project, does not overwhelm the main task.
Add a few signs that the project is working, phrased in terms the team can reasonably observe. These might include fewer questions about basic services, easier updates for staff, or visitors reaching a contact page from relevant service pages. Treat these as ways to review the work, not promises about results.
Name the audience and the tasks they bring
Describe the main groups of people who will use the site and what they need to do there. Keep the descriptions specific enough to guide decisions without inventing elaborate personas. A community group, for example, might identify first-time visitors looking for meeting details, potential volunteers checking what participation involves, and existing members seeking resources. Each group brings different questions, but the brief should identify which needs matter most at launch.
List the most important visitor tasks in ordinary language: find opening hours, compare services, register interest, download a form or contact the right person. Then note anything that might make those tasks difficult. Visitors may be using phones, have limited time, or rely on keyboard navigation or assistive technology. These considerations belong in the brief from the start; they should not be left for someone to discover after the pages have been designed.
If the team disagrees about what users want, record the uncertainty rather than disguising it as a fact. A brief can say, “We need to confirm which questions new volunteers ask most often.” That turns an assumption into a task for the team.
Define what is in scope, and what is not
Scope is where a short brief prevents a great deal of confusion. Write down the expected deliverables, such as a revised page structure, five core pages, a reusable news template and a contact form. Identify existing content that will be kept, rewritten, combined or removed. If the team has not reviewed it yet, say who will do that work and when the decision is needed.
Give equal attention to exclusions. A new logo, translation into additional languages, an events system or a member portal may be good ideas without being part of this project. Recording them as “not included at launch” keeps them visible without silently adding work. You can also maintain a short list of possible later improvements, separate from the commitments needed to finish the current site.
Include practical constraints that shape the work: the available budget or time, the content management system if one is already chosen, and any required integrations. Distinguish firm requirements from preferences. “Staff must be able to update opening hours without a developer” is a requirement; “we prefer a certain page layout” may be open to change if testing the content suggests a better approach.
Assign ownership before work gets stuck
Small teams often share responsibilities informally, which can leave important tasks without an owner. The brief should name who supplies content, who checks it for accuracy, who makes design decisions, who tests the site and who gives final approval. One person may hold several roles. What matters is that everyone knows where a question goes and who can make a decision when opinions differ.
Set out a manageable sequence of checkpoints rather than trying to predict every day of the project. Useful checkpoints might be agreement on the page list, approval of draft content, review of working pages and a pre-launch check. For each one, state what the team will review and who needs to respond. If a deadline depends on receiving photographs or service descriptions, make that dependency visible.
Ownership should continue after launch. Note who can update the site, who will monitor incoming enquiries or form problems, and who will periodically review pages for outdated information. A project brief is most useful when it treats the website as something the team will maintain, not merely publish.
Keep the brief short, visible and revisable
A brief works best as a living agreement. Keep it in a place the whole team can access, use clear headings, and add a simple record of significant decisions. When the scope changes, note what changed, why and who approved it. This makes it easier to understand trade-offs later without relying on memories of a meeting.
Before work begins, ask each contributor to read the brief and point out anything they cannot act on. Are the priorities clear? Is anyone waiting for content they do not know how to obtain? Does “finished” mean the site is live, or does it also include editor training and a maintenance handover? Resolving those questions early is the brief’s real value: it gives a small team a practical basis for moving forward together.
