Website design brief template for small businesses: what to decide before you hire

A website design brief is a short decision document that tells a studio what the website must help the business and its customers do. It should identify the pages, content, functions, responsibilities and tests that define the job. It does not need to prescribe every layout or technical choice.
Without a brief, "we need a modern website" can mean a five-page brochure to one person and a booking, payment and customer-account system to another. That gap appears later as a vague quotation, missing content, additional work or a site that looks finished but does not support the main customer action.
Use the template below before asking for proposals. Mark unknowns rather than guessing. A good studio can help resolve them during discovery, but both sides should know which decisions remain open.
A strong brief settles five things before design begins: the customer action the site must support, what is required at launch, who supplies and approves the content, what the studio must implement, and how both sides will decide that the work is complete.
Copy-and-fill website design brief template
1. Business and project
- Business name:
- What the business sells:
- Areas or customers served:
- Existing website, if any:
- Why this project is happening now:
- Named owner of the project:
- People who approve scope, content and launch:
2. Outcome and customer action
- The main business outcome we want:
- The primary visitor we are designing for:
- The main action that visitor should complete:
- Other important actions:
- Evidence that the action worked:
- Current baseline, if measured:
Go beyond "generate more leads." Name what a useful lead looks like. For example: an enquiry from a customer in the service area that identifies the required service and supplies enough information for a follow-up. A button click is not the same as a received, qualified enquiry.
3. Pages and content
| Page or content type | Visitor's question | Main action | Existing, revised or new? | Content owner | Approval owner |
|---|---|---|---|---|---|
| Home | |||||
| Service page | |||||
| About | |||||
| Contact or enquiry | |||||
| Other |
For each page, identify who supplies the words, photographs, logos, testimonials and legal text. An entry such as "content supplied by client" still needs a named owner, a deadline and a check that the business may use the material.
4. Scope priorities
Put every requested item into one of three groups:
- Must have for launch
- Useful later
- Out of scope for this project
This makes trade-offs visible. If the timeline or available resources change, the project can protect what matters without treating every idea as equally urgent.
5. Functions and integrations
For each form, booking tool, payment service, map, newsletter, customer system or other integration, record:
- what the visitor needs to do;
- the provider or existing account, if known;
- who controls that account;
- what data enters or leaves the website;
- who should receive a notification;
- what the visitor sees after success or failure;
- how the function will be tested;
- who handles fees, renewals and support after launch.
Describe the need before prescribing a plugin. "A customer can request an appointment and staff can confirm it" gives a studio room to recommend an implementation. Name an existing booking provider when retaining it is a project constraint.
6. Accessibility and conversion requirements
Accessibility means that people with disabilities can perceive, understand, navigate and interact with the website. State the intended standard, scope and evaluation method rather than writing only "the website should be accessible." If the project requires conformance with the Web Content Accessibility Guidelines (WCAG), name the WCAG version and level and get suitable accessibility expertise. W3C's explanation of conformance says WCAG uses testable success criteria and that evaluation combines automated testing with human evaluation. It also treats every page in a complete process as part of that process, so a usable contact page does not excuse an unusable confirmation step.
For forms, specify visible, descriptive labels, useful instructions, understandable error messages, keyboard use and confirmation of the result. W3C's form guidance explains that a label should describe a control and be associated with it in the code so browsers and assistive technology can present the right information.
A conversion is the useful action the website asks a visitor to take, such as sending an enquiry, booking, calling or buying. Connect that action to a specific page and an acceptance test. Examples:
- On a phone, a visitor can find the primary service and reach its enquiry route.
- A test enquiry shows a confirmation and arrives in the agreed monitored inbox with the required fields.
- A keyboard user can reach, complete and submit the form with a visible focus indicator.
- Error messages identify the field that needs attention and explain how to correct it.
7. Design and brand boundaries
- Existing brand assets and guidelines:
- Examples the business likes, with the reason for each:
- Examples it dislikes, with the reason for each:
- Required tone:
- Image sources and usage rights:
- Any design decision the studio may explore:
- Any element that must remain:
Instead of asking to copy a competitor, identify what works in the reference, such as restrained typography or a prominent booking path.
8. Search, measurement and existing URLs
- Search topics and services that matter:
- Existing pages or URLs that must remain discoverable:
- Analytics and search tools already in use:
- Required consent or privacy review:
- Events to measure:
- Who reviews results, when, and against what baseline:
A ranking or enquiry increase cannot be checked before launch. The studio can test whether intended pages are present, links work and agreed tracking has been implemented. Search visibility and qualified enquiries require observation after publication.
9. Responsibilities and dependencies
| Decision or deliverable | Business owner | Studio or implementer | Due date | Evidence of completion |
|---|---|---|---|---|
| Approve page list | ||||
| Supply final copy | ||||
| Supply licensed images | ||||
| Configure integrations | ||||
| Review staging site (a private preview of the new website) | ||||
| Test enquiries | ||||
| Approve launch |
The business normally owns business decisions and source material. The studio normally owns implementation and evidence that it meets the agreed requirement. Record the actual allocation because a particular project may divide the work differently.
10. Timeline, budget and quotation assumptions
- Desired launch date and why it matters:
- Internal approval dates:
- Content delivery dates:
- Known unavailable periods:
- Budget range or constraints, if the business is ready to share them:
- Items each quotation must separate:
- Ongoing costs to identify:
- How changes to the agreed scope will be handled:
A date is not a plan unless its dependencies have owners. Ask each studio to state what its estimate assumes, what is excluded and which third-party costs or renewals sit outside the build fee.
11. Acceptance criteria
An acceptance criterion is a condition that someone can check before accepting the work. Use this format:
Given [starting situation], when [person takes an action], then [observable result] happens.
Examples:
- Given a visitor is on the plumbing service page, when they select "Request a quote," then the agreed enquiry form opens and identifies plumbing as the service.
- Given required fields are empty, when a visitor submits the form, then each problem is identified in text and focus moves to a useful location.
- Given a valid test enquiry, when it is submitted, then the visitor sees confirmation and the agreed recipient verifies receipt.
Replace descriptions such as "looks professional," "easy to use" or "SEO friendly" with the check, the person responsible and the relevant pages or journeys.
At this point, the brief is useful enough to start a scoped conversation. If it shows that your project needs a custom WordPress build, send your completed website brief to WPShip. Include the page table, main customer action, integrations and unresolved owner decisions so both sides can discuss the scope from the same starting point.
A short hypothetical example
The following is a fictional example, not a WPShip customer result.
Business: A hypothetical local heating repair company.
Buyer and action: A homeowner in the service area needs to request a repair visit from a phone.
Must have: Home, repair service, service-area, about and contact pages; a short repair request form; tap-to-call link; migration of approved existing copy; basic analytics events for form start, successful submission and phone-link click.
Later: Online appointment selection and a maintenance-plan customer area.
Owner decisions: Confirm the service area, emergency wording, monitored enquiry address, final copy, licensed photographs and who may approve launch.
Studio implementation: Recommend the page structure, design responsive templates, configure the form, implement agreed accessibility requirements, prepare the staging review and provide test evidence.
Acceptance test: Given a visitor on a current mobile browser opens the repair page, when they complete a valid repair request, then a clear confirmation appears and the monitored address receives the service, postcode and contact details. The test record names the page, browser, date and recipient who verified delivery.
This example also shows why a brief should separate a launch need from a later idea. Adding live appointment inventory could change the system, data and support scope. It should not enter the build through an ambiguous sentence such as "include booking if possible."
What the brief should leave open
A brief should define the problem, constraints, responsibilities and result. Leave room for a studio to propose the content structure, visual system and technical approach, then ask it to explain how the proposal meets the agreed requirements.
Business Victoria describes a design brief as a way to set clear expectations between a business and a designer. The Digital Culture Network's website brief guidance likewise treats a brief as enough information for an agency to understand and quote the work, while leaving room for the agency's expertise.
The brief's job is not to design the website in advance. It turns a vague request into decisions, responsibilities and observable results. That gives a business a fairer basis for comparing proposals and gives the chosen studio something specific to question, improve and deliver against.