A Simple Website Brief Template for Freelancers and Small Businesses
A website project can start with a simple request: “We need a new site.” But that leaves important questions unanswered. What should the site help people do? Which pages are essential? Who is writing the copy, and what does “finished” mean?
A website design brief template gives you a shared place to answer those questions. It does not need to be a polished strategy document. For a small business or freelance project, a few pages of clear, realistic information can prevent misunderstandings, reduce rework and help everyone make better decisions.
Use the template below whether you are hiring a freelancer, briefing an in-house colleague or planning the work yourself. If you do not know an answer yet, write that down too. An honest question is more useful than a confident guess.
What a website brief is for
A brief describes the problem the website should solve, the people it needs to serve and the practical boundaries of the project. It helps a designer make informed choices about structure, content and appearance. It is not a complete technical specification, nor a guarantee that every detail is settled before work begins.
For example, “make the site feel modern” is hard to act on because people interpret modern in different ways. “Help local customers check our services and request an appointment from a phone” gives the designer a task to solve. You can still discuss visual direction, but it now has a useful context.
Good briefs focus on outcomes rather than prescribing every screen. A small business owner may know that bookings are the priority, but not whether the best answer is a booking form, a phone number or an external booking system. Leave room for the designer to recommend an approach, then agree on it together.
Website design brief template
Copy the prompts below into a document and answer them in plain language. Short answers are fine. Add links, examples or notes where they help explain what you mean.
1. Business and project basics
- Business or project name: What name should appear on the site?
- What you do: Describe your main products or services in one or two sentences.
- Project lead: Who makes decisions and provides feedback?
- Other contributors: Who will supply copy, photography, approvals or technical access?
- Project type: Is this a new site, a redesign, a content refresh or a specific feature?
Keep the description concrete. “We provide independent accountancy services for sole traders and small firms in Bristol” gives a stronger starting point than “We help people succeed.” If the business has several audiences or services, list them rather than squeezing them into one broad statement.
2. The problem and desired result
- Why are you doing this now? For example: the site is difficult to update, services have changed, or customers cannot find booking details.
- What should the website help visitors do? Examples include request a quote, make a booking, understand a service or find opening hours.
- What would a useful result look like? State a result you can observe, such as fewer calls asking for information already on the site.
- What is out of scope? Note work that is not included, such as a new logo, online shop or ongoing copywriting.
Try to separate the business goal from the website feature. “We need a chatbot” is a proposed solution; the underlying issue might be that visitors cannot find answers to common questions. A clearer FAQ page could be simpler to maintain. A brief should explain the need and treat the solution as something to evaluate.
3. Audience and their needs
- Who is the main audience? Describe relevant traits, such as location, role or familiarity with your service.
- What are they trying to do? Think about the question or task that brings them to the site.
- What might hold them back? They may need to compare costs, understand eligibility or feel confident sharing contact details.
- Are there secondary audiences? Include them if they have different needs, but identify which audience takes priority when choices conflict.
Imagine a two-person bicycle repair shop. Its main visitors may be local riders looking for a repair, not cycling enthusiasts researching components. They need to know what the shop fixes, where it is, whether they need an appointment and how to get an estimate. That picture can guide page order and calls to action more usefully than a broad label such as “people who like bikes.”
When you are unsure about visitor needs, look at questions customers already ask, email enquiries, search terms or conversations with staff. The UK Government’s guidance to start by learning user needs is written for public services, but the principle is useful for small websites too: understand the task before settling on the design.
4. Pages, content and features
- Essential pages: List the pages needed for launch, such as Home, Services, About, Contact and FAQs.
- Content to include: Note the key information each page must communicate.
- Features: Name practical requirements such as a contact form, event listings, appointment requests or downloadable documents.
- Content owner: Say who will write, review and supply each item.
- Existing material: Link to the current site, brand files, photography and documents that may be reused.
A page list is a starting point, not a reason to create a page for every service variation. If you have not mapped the structure yet, Wandesign’s guide to planning a small-business website sitemap before writing copy can help you decide what belongs where.
Be specific about features. “A contact form” could mean name and email fields, or a detailed enquiry form with file uploads and routing to different staff. Describe what the visitor needs to submit and what should happen after they submit it. Keep the first version as simple as the task allows; extra fields can make a form harder to complete and create more information to manage.
5. Brand and visual direction
- Brand assets: Provide your logo, colours, fonts and any existing guidelines.
- Desired impression: Choose a few useful qualities, such as calm, practical or welcoming, and explain why they fit.
- Examples you like: Link to sites and identify what works: clear navigation, readable type or strong product photography.
- Examples you dislike: Explain the specific issue, rather than saying only that the site looks bad.
Examples are reference points, not instructions to copy another business. A site you admire may have a large photography budget or a different audience. Explain the element you want to learn from, then let the designer adapt it to your needs.
If you have no established brand, say so. Agree whether the project includes basic visual decisions such as colours and typography, or whether it should work with temporary branding. This avoids the assumption that a full identity will appear as part of a website build.
6. Accessibility, devices and practical requirements
Tell the designer about requirements that affect how the site is built and used. These might include people using keyboard navigation, visitors reading on small screens, staff updating content without code, or customers with limited internet access.
- Accessibility: State any known needs, such as captions for video, clear keyboard focus or plain-language content.
- Devices and browsers: Note any important audience context, but expect the site to work across common screen sizes.
- Languages: List languages needed at launch and who will provide translations.
- Privacy and data: Explain what information forms collect and who needs access to it.
- Existing systems: Mention email, booking, payment or customer-management systems the site must connect to.
Accessibility is not just a finishing touch. Choices about headings, contrast, labels and keyboard operation affect the design and content from the start. The W3C’s WCAG overview explains the Web Content Accessibility Guidelines, a widely used set of recommendations for making web content more accessible. You do not need to turn a brief into a compliance audit, but it is useful to raise accessibility early and agree what will be checked.
7. Budget, timing and responsibilities
- Budget range: Give a realistic range and say whether it includes tax, hosting, content or ongoing support.
- Target date: Explain any fixed deadline and what causes it, such as a product launch or seasonal opening.
- Availability: State when decision-makers can review work and how quickly they can usually respond.
- Ongoing ownership: Say who will update the site, pay for hosting and manage domain access after launch.
A deadline only works if it includes the time needed for content, feedback and revisions. If the site must launch before a trade event, agree which pages are essential for that date and what can follow later. A smaller, complete first release is often more manageable than trying to finish every future idea at once.
Be clear about approval. One person can gather comments from colleagues and send a single considered response. Several people giving separate, conflicting notes can create extra rounds of work and make it difficult to know which direction is final.
Worked example: a local repair shop
Here is how a short brief might translate into useful project decisions:
- Business: A two-person bicycle repair shop serving customers within a few miles.
- Problem: The current site is hard to read on phones and does not explain which repairs the shop offers.
- Primary task: Help a potential customer check whether the shop handles their repair and ask about availability.
- Essential pages: Home, Repairs and prices, About, Find us and Contact.
- Feature: A short enquiry form asking for contact details, repair type and preferred contact method.
- Content: The shop owner supplies service details and prices; the designer helps organise the information.
- Constraints: A modest budget, an opening date before the spring season and no online payment at launch.
That brief suggests a focused first site rather than a full ecommerce build. The home page can quickly point to repair information and location; the form can collect enough detail for a useful reply without asking customers to complete a long questionnaire. If online booking becomes a proven need later, it can be scoped as a separate improvement.
How to make the brief useful once work starts
Share the brief before design begins, then use it as a reference when new ideas appear. A request for a gallery, extra form field or new page is not automatically a problem. Ask what need it serves, whether it fits the agreed scope and what it means for time or cost.
Keep the document editable. Update it when you make a decision, and mark unresolved items with an owner and a date to revisit them. For instance, “Owner to confirm whether Saturday appointments are available by 12 March” is more actionable than leaving the question buried in meeting notes.
Finally, agree a simple definition of launch-ready. It might mean that essential pages are approved, forms have been tested, contact details are correct, the site works on a phone and someone knows how to make routine updates. A brief cannot remove every uncertainty, but it can make the important decisions visible before they become expensive surprises.
Frequently asked questions
How long should a website design brief be?
Long enough to explain the goals, audience, content, constraints and responsibilities. A small business brief may fit into a few pages. Clarity matters more than length, and you can link to existing documents instead of repeating them.
Do I need to know the design or technology before writing the brief?
No. Describe what visitors need to do and any practical requirements you know about. A designer can help compare possible layouts or platforms once the goals and constraints are clear.
What if I do not know my budget yet?
Set a range if you can, or explain the limit you are working within and ask for options at different levels. Be explicit about whether content, hosting, maintenance and taxes are included in that limit.
Should the brief include the website copy?
It should say who will write and approve the copy, and what information each page needs. The finished copy can come later, but leaving ownership unclear may delay design and development.
Can I change the brief after the project starts?
Yes. New information can justify a change. Record what is changing, why it matters and whether it affects cost, timing or other agreed work before asking the designer to proceed.
