Website Design Brief: A Practical UK Small-Business Guide
A website design brief explains who the website is for, what people need to do, what the project must deliver and how the result will be checked. A useful brief gives an agency enough information to discuss scope and price while leaving room for its expertise. It does not need to dictate every screen before the project begins.
This guide is for UK small businesses preparing a new site or redesign. It includes a practical structure, example requirements and questions for comparing proposals. Sources were checked on 5 November 2026. The examples are illustrative and do not describe a client project.
Explain the problem before listing features
Start with the reason for the project. Describe what is difficult now, who experiences that difficulty and what you want to improve. “Visitors cannot tell which service covers their enquiry” gives a designer something more useful to investigate than “we need a modern website”.
The Digital Culture Network’s website-brief guidance explains that a brief helps prospective agencies understand what to consider when quoting. It recommends clarity and concision, with room for agencies to contribute ideas. Use a template to organise relevant information, rather than treating every suggested field as compulsory.
Give a short introduction to the business: its services, location or coverage, current website and the person coordinating the project. Include constraints that affect the work. Avoid a long company history unless it helps explain the audience or the problem.
Identify audiences and the tasks they need to complete
Describe the people who will use the site and their main tasks. A prospective customer comparing services has different needs from an existing customer looking for support. Put those tasks in priority order so the agency can understand what matters most.
The GOV.UK Service Manual’s guidance on user needs starts with understanding people and what they need to accomplish. It is written for government services, but the question is useful when preparing a business brief too: what does a visitor need to get done?
Separate evidence from assumptions. If customers regularly phone to ask where you operate, say how you know that. If you suspect the contact form is difficult, identify that as something to investigate. The brief should help the agency ask better questions, not present every guess as research.
A simple audience-and-task note
- Audience: a prospective customer with a time-sensitive enquiry.
- Task: establish whether the service covers their location and contact the business.
- Current issue: coverage information is difficult to find.
- Question to investigate: where do visitors expect to see that information?
This is an illustrative example. Adapt it to real enquiries and user feedback rather than inventing an audience profile solely to fill the brief.
Define scope and separate essentials from later ideas
List the main types of pages, content and functions you expect. Explain what each is for. A list such as home, services and contact is a starting point, but the agency also needs to know whether services have different layouts, whether existing material must be migrated and whether editors need to create more pages later.
Divide requirements into essential for launch, desirable if feasible and possible later work. Ask the agency to identify assumptions and dependencies in its proposal. That makes it easier to discuss a realistic first release without allowing useful future ideas to become unnoticed commitments.
Our guide to choosing web-design services provides related background. In a brief, go beyond the name of a service and describe the result you expect to receive.
Turn features into requirements you can check
For every important feature, write what a user should be able to do and how you will know it works. “Contact form” leaves many decisions open. A more useful description identifies the fields, destination, confirmation and staff process that need to be agreed.
| Vague request | More useful briefing question |
|---|---|
| A better contact page | Which enquiry types should visitors submit, and where should each reach the team? |
| Easy editing | Which content must staff update without developer help? |
| Good on mobile | Which priority tasks will be tested on small screens? |
| Fast website | How will performance be measured, on which pages and under what conditions? |
Agree the detail with the agency rather than choosing technical numbers without context. A measurable requirement is useful when both parties understand the test and the circumstances in which it applies.
Assign content, images and approvals
Identify who will write, review and supply the content. Include photography, logos, documents and any other material needed for launch. State whether existing pages should be kept, rewritten, merged or reviewed before a decision.
Set a realistic approval route. Name the person who consolidates feedback and distinguish subject-matter review from final sign-off. If several colleagues can request conflicting changes, decide how disagreements will be resolved before design work starts.
Ask what content format and delivery dates the agency needs. A design schedule can depend on material that the business must supply. Put those dependencies beside the proposed launch date so they can be discussed openly.
Include accessibility and maintenance from the start
The W3C Web Accessibility Initiative’s planning resources cover managing accessibility, responsibilities and involving users. Include accessibility expectations in the brief and ask how they will be designed, tested and maintained, rather than treating them as a final visual adjustment.
Explain who will maintain content after launch and what training or documentation they need. Ask which tasks are covered by an ongoing support arrangement and which will require a separate quote. Identify the person who will own updates, backups and reporting.
Our explanation of hosting and domain registration can help with the ownership discussion. The brief should identify existing arrangements and the decisions needed, rather than assuming the agency will take over every account.
Give budget and timing useful context
Explain the budget available and what it needs to cover, using pounds sterling for a UK project. Distinguish the initial project from recurring costs such as hosting, licences and support. Ask proposals to state whether VAT and third-party costs are included.
For timing, describe the reason for a deadline and which dates are fixed. An event, contract end date or planned campaign may create a genuine constraint; a preferred launch month may allow more flexibility. Ask the agency to identify milestones, review periods and information it needs from you.
A budget discussion is more useful when the agency can suggest scope choices. Ask what could be phased and what dependencies would make a smaller first release sensible. Do not hide essential requirements until after a price has been agreed.
Compare proposals against the same brief
Ask each agency to respond to the same version and identify exclusions, assumptions and unresolved questions. If the brief changes, send the revision to everyone still quoting. Otherwise, apparently different prices may describe different projects.
Use MadeByShape’s briefing guidance as an example of how an agency approaches the initial discussion. Your own decision should consider the proposed response to your needs, not just whether a proposal repeats the headings of a template.
Write down selection criteria before comparing quotations. Relevant factors may include understanding of the audience, approach to testing, clarity of handover and the support offered. Ask for explanations where a proposal leaves responsibility unclear.
A compact brief structure to adapt
- Business context and the problem to solve.
- Audiences, priority tasks and available evidence.
- Launch scope, deliverables and later ideas.
- Content, images, migration and approvals.
- Functional requirements and acceptance checks.
- Accessibility, performance and maintenance expectations.
- Budget, timing, dependencies and proposal requirements.
Finish with a list of questions you want the agency to help resolve. A useful brief can contain uncertainty, provided it is visible. The aim is a shared basis for discussion, a comparable proposal and a result that can be checked.
Before sending the brief, ask a colleague who has not helped write it to read it. Can they identify the audience, launch scope, decision-maker and next step? Use their questions to find missing information and remove ambiguity before requesting proposals.
Frequently asked questions
How long should a website design brief be?
Long enough to explain the project clearly. Use concise sections and supporting material where it helps, rather than aiming for an arbitrary page count.
Do I need a finished sitemap before contacting agencies?
A draft can help, but identify it as a starting point. Explain the content and user tasks, and ask the agency to test the proposed structure.
Should I include websites I like?
Yes, if you explain which elements are relevant and why. An example is a discussion aid rather than an instruction to reproduce another site.
Should the brief include a budget?
Useful budget context helps agencies propose realistic scope. Clarify what the amount covers and request recurring and third-party costs separately.
Can the brief change during the project?
Yes, but agree how changes affect scope, cost, timing and acceptance. Keep a shared current version rather than relying on scattered messages.
