A small-business website brief is a short record of what the site needs to help people do, what information exists, and who will keep it accurate. It gives a designer, developer or internal team something concrete to discuss. You can write a useful first version in one or two pages. It does not need to prescribe every component or settle every visual decision.
The most useful brief is specific about a visitor's task and candid about what remains unknown. “We need a modern website” gives little direction. “A visitor must be able to understand our three services, compare the relevant details and find the correct next step on a phone” provides a basis for pages, content and review. This guide works through those decisions and ends with a compact outline you can copy.
Start with the decision the website must support
Write one sentence describing the main decision a visitor should be able to make. For a local service organisation, it might be deciding whether a service fits their situation. For a community group, it might be finding the correct event and understanding how to attend. For a business with a complex offer, it might be narrowing several options before a conversation.
Then describe what currently makes that decision difficult. Perhaps the existing site uses internal terminology that newcomers do not recognise. Perhaps key details are scattered across a homepage, a PDF and a social profile. Perhaps an enquiry path exists, but the person receiving it cannot tell what the visitor needs. Each diagnosis suggests a different scope. A new colour palette alone will not fix missing information.
Avoid promising a metric you cannot yet measure. “Increase conversions by 40%” is not a useful requirement without a baseline, a defined conversion and an owner for measurement. State the action and how you will check that it is possible. If you already have reliable analytics, you can add a measured goal in a separate section.
Name the visitor and the task
You do not need a fictional persona with an invented age and occupation. Describe a real situation: “A first-time visitor who has heard of our organisation but does not know which service applies.” Add the question they arrive with, the information they need and the action that follows. If several groups use the site, rank their tasks so the first screen does not try to serve all of them equally.
Consider context. Someone checking opening details while travelling may be on a narrow screen with limited time. Someone comparing a complex service may want to save a page and return later. These are planning hypotheses, not proof of user behaviour; they should be checked with actual feedback when possible. The brief should make the assumptions visible so they can be revised.
Google Search guidance on people-first content reinforces a useful editorial test: write material for the people who need it, rather than building pages simply to target a phrase. In the brief, name the questions the site can answer well. Do not order extra pages only because a keyword tool suggests them.
Inventory what you already have
List the existing pages, documents, images and brand files. Mark each item as current, needs checking, needs rewriting or unavailable. Add the person who can confirm it. This inventory is especially valuable during a rebuild because an attractive new layout cannot establish whether an old service description is still true.
Include important existing URLs. People may have bookmarked a page, linked to it from another site or used it in printed materials. If the address changes, the project needs a redirect decision. Record the old address and the intended new destination; do not assume that a new sitemap alone will preserve the journey. The website content maintenance checklist explains how to keep that inventory useful after launch.
Check rights and quality as well as availability. Is a photograph genuinely yours to publish? Is the logo available as a usable source file? Does a testimonial have permission and a current relationship behind it? Unknown material can be listed as a dependency without appearing on the live page. This prevents a design from relying on proof that cannot be published.
Give each page a job
Sketch a small page map. A homepage may introduce the subject and direct visitors to the right detail. A service page can explain suitability, scope, process and a practical next step. An About page can supply background and point of view. A contact page should describe a real way to continue. Every page needs a distinct reason to exist.
For each proposed page, write three notes: the question it answers, the material it requires and where the visitor should go next. If two pages answer the same question, consider combining them. If one page carries several unrelated decisions, split it or clarify its order. Google's SEO starter guide describes logical site organisation and descriptive URLs as ways to make page relationships clearer. Treat that as a structure principle, not a promise of search ranking.
Keep names understandable outside the business. Internal department labels may be accurate but unhelpful to a new visitor. A page called “Services” should make it possible to identify the relevant service; a page called “Resources” should make clear what kind of resources are there. The website-development guide goes deeper into page responsibilities and navigation.
Separate content from functionality
Write separate lists for information and actions. A paragraph explaining appointments is content. Online booking is a system with availability rules, account access, notifications and an owner. A contact page is content; a working form also needs a destination, spam handling, privacy decisions and a way to test delivery. A portal requires even more decisions about identity and data access.
This separation keeps the brief honest. Mark each proposed feature as essential for the first release, possible later, or dependent on another service. Name the existing service if one is already used, but keep passwords and recovery codes out of the brief. A designer can plan the interface with a clear dependency list; they should not have to guess whether an integration is ready.
Apply the same distinction to editing. Correcting a sentence is different from adding a service type that changes navigation and page templates. List the everyday changes you expect: hours, staff roles, service descriptions, images or articles. Then identify structural changes that deserve a separate review. The editing model should match the work people will actually do.
Assign owners and access
Give each kind of information a current owner or at least a role that can confirm it. Someone should know whether a service description is accurate; someone should know who may publish an update; someone should own the domain and hosting accounts. One person can fill several roles, but leaving them unnamed makes the handover fragile.
Accessibility belongs in the plan as well. The W3C Web Accessibility Initiative's planning guidance includes setting goals, assigning responsibilities, evaluating early and monitoring over time. A brief can record the accessibility tasks the team will review without claiming that a design already conforms to a standard. Include real content and realistic page tasks in that review, not only a tool score.
Record where the source text and images will live, who can edit them and who checks a change before it appears. If the project uses an external form, booking service or content system, record the account owner and the process for granting access. Do not put credentials into a document that may be shared with several bidders or collaborators.
State constraints and priorities
Give a realistic launch reason and date if one exists. A seasonal event, a change of address or an expiring contract may be a hard constraint. “As soon as possible” does not tell a team what can be traded off. List the pages and actions that must work for the first release, then the items that can be improved later. If a budget range is available, share it so the proposal can match the scope; if it is undecided, say so rather than inventing precision.
Technical constraints matter when they are real: an existing domain, a required hosting account, a current content system, a legal review process or an integration controlled by another supplier. List who can make decisions about each. Avoid choosing a platform in the brief solely because it appears in a template. Describe the editing, security and maintenance needs first; the implementation can follow.
Write checks for the first release
Replace “finished website” with observable checks. Can a visitor find the relevant service from the homepage? Do the published claims match approved information? Do the main routes and downloads work on a phone? Are old important URLs redirected to useful destinations? Can the nominated editor make a routine content change without disturbing the layout? Is there a documented owner for the domain and the publishing account?
These are examples, not a universal checklist. Adapt them to the actual site. Review a complete visitor path, including the destination of the final action. A polished form that sends nowhere should fail the check. A static page can pass when it explains the available next step truthfully. Keep the checks in the brief so the project can be reviewed against its purpose rather than a vague impression at launch.
A brief you can copy
Use the following headings as a first draft. Keep each answer short and mark facts that need confirmation. The aim is a document people can discuss, not a form that must be completed perfectly before anyone can help.
- Purpose: What decision or action must the site make easier, and what is currently getting in the way?
- Visitors: Who are the main groups, what questions bring them here and which task matters most?
- Existing material: Which pages, images, documents and URLs exist, and who can verify or approve them?
- Page map: What is the job of each proposed page, and what next step follows it?
- Features: Which interactions must work at launch, what systems support them and who owns those systems?
- Editing: What changes regularly, who makes those changes and who reviews them?
- Constraints: What date, budget, account, brand or approval requirements are confirmed?
- Release checks: What observable tasks will show that the first version is useful and works?
Read the draft with the people who will supply content and maintain the result. Their corrections often reveal a missing dependency before it becomes an expensive change. Keep the document editable; as decisions become firm, update the brief instead of treating the first version as a contract with every answer already known. To begin locally, download AJM's website-brief worksheet, then use this outline to add the decisions that matter to your project.