A good web design brief states the project's main goal and how you will measure success, names the audience and the pages or features needed to reach them, and sets out timeline, budget range and any technical or accessibility requirements. Leave any of these out and vendors are left guessing, which shows up later as scope creep or a quote that does not match the final invoice.
TL;DR:
- Including a detailed sitemap, technical requirements, and clear scope helps vendors provide accurate quotes and prevents scope creep.
- Stating accessibility standards like WCAG 2.2 level AA and expected compliance costs early reduces costly redesigns after launch.
- Using fixed, phased, or budget band payment structures and realistic timelines ensures better control over project costs and deadlines.
- Involving stakeholders from the start and providing visual examples prevent misunderstandings and ensure clear feedback throughout the process.
- Clarifying post-launch support and maintenance expectations upfront avoids surprises and ensures ongoing website performance and updates.
Table of Contents
- Essential elements of a web design brief
- Step by step: preparing a brief vendors can quote against
- Accessibility and technical requirements to specify
- Setting the budget and timeline in the brief
- Common mistakes and red flags to watch for
- A copyable brief skeleton and final checklist
- Who should be involved in deciding the brief
- Using competitors and inspiration sites to guide design
- What to expect for maintenance and support after launch
- How a website design company can turn a brief into a low risk project
- How Webnora can help with your next website
- FAQ
- Sources
Essential elements of a web design brief
A web design brief does not need to be long, but it does need to cover the same ground every time so vendors can compare like with like. A commonly used structure, drawn from template guidance used across UK agencies, includes the following core fields.
- Project summary and company background: a short paragraph on what the business does, who it serves and why the website matters now.
- Objectives and KPIs: state the goal in measurable terms, for example "increase enquiry form submissions" rather than "look more professional".
- Target audience and user needs: describe who visits the site, what they are trying to do and roughly how many of them there are, if known.
- Scope and deliverables: list the pages, features and integrations needed, split into must haves and nice to haves.
- Sitemap: a simple list or diagram of pages and how they connect, detailed enough to show structure without wireframing every screen.
- Functional and technical requirements: the content management system, any third party tools, and hosting preferences.
- Content ownership: who writes the copy, who supplies photos and video, and by when.
- Timeline, milestones and approvals: key dates and who signs off at each stage.
- Budget or budget range: enough detail for a vendor to judge whether the project fits, plus payment terms.
- Branding, visual references and accessibility requirements: existing brand assets, sites you like, and the accessibility standard you expect.
Each field earns its place because it answers a question a vendor would otherwise have to ask, or guess. A brief that skips the sitemap, for instance, often results in a quote based on "a website" rather than the eight pages and booking form you actually need.
Step by step: preparing a brief vendors can quote against
Writing the brief is easier once you have gathered the right material and settled who needs to be involved.
- Identify stakeholders and gather assets first: pull in whoever approves budget and design, and collect existing analytics access, brand guidelines, logos and any copy already written.
- Draft constraints and priorities before the detail: write your objectives, audience and budget range first, since these shape every later decision about scope.
- Describe users through two or three priority journeys: instead of a full persona document, note what your top visitor type wants to do on your three most important pages.
- State integrations and data flows in plain terms: name the booking system, payment provider or CRM you need connected, and whether data needs to sync both ways.
- Separate must haves from nice to haves: mark each feature clearly so vendors price the essential build first and quote extras separately.
- Format for clarity: attach screenshots of sites you like, link to competitor pages, and date or version the document so revisions do not get confused with the original.
Pro Tip: Send the brief as a single document rather than a string of emails. Vendors quote more accurately when everything sits in one place.
Gathering analytics access matters more than it sounds. If a vendor can see which pages currently get traffic and where visitors drop off, they can challenge assumptions in the brief rather than simply building what was asked for.
Accessibility and technical requirements to specify
Accessibility works best as a stated requirement from day one, not a late addition. Gov recommends designing for accessibility from the start, meeting WCAG 2.2 level AA as a minimum, as recommended by government guidance, and publishing an accessibility statement.
The Web Content Accessibility Guidelines group requirements into four principles, perceivable, operable, understandable and robust, which gives you a shared vocabulary for acceptance testing with any vendor.
Include these in your brief:
- The accessibility standard you expect, such as WCAG 2.2 level AA, and whether you want a formal audit before launch.
- A request for an accessibility statement once the site is live.
- Required browser and device support, so testing scope is clear from the outset.
- A page load target and the SEO basics you expect, such as a sitemap file and clean URL structure.
- The CMS, hosting and third party tools involved, so there are no surprises about where the site will live or what it depends on.
- Acceptance criteria for both accessibility and performance, meaning a clear description of what "done" looks like before final payment.
Setting the budget and timeline in the brief
How you present budget and timeline affects whether you get comparable quotes or a spread of wildly different numbers.
- Fixed price suits a well-defined brief with a known page count and feature list, since both sides know what is included.
- Time and materials suits projects likely to change shape as you learn more, though it makes budgeting less predictable.
- Phased delivery splits the project into stages, each with its own acceptance criteria, so you can pause or adjust after the first phase.
- A budget band rather than a single figure, stating what is included and excluded, helps vendors judge fit without you committing to one number too early.
- Realistic timelines signal that you want a properly built site rather than a rushed one; a brochure site for a small business typically needs less time than a custom build with integrations and bespoke features.
Common mistakes and red flags to watch for
Vague objectives or an undefined audience are the single biggest cause of proposals that miss the mark, because vendors fill the gaps with assumptions that may not match yours. Mixing visual preferences into functional requirements, such as "modern and clean" sitting next to "needs a booking calendar", also makes estimates harder to pin down.
- Leaving out accessibility or performance expectations tends to surface as extra cost once a client asks for compliance after launch.
- Watch for vendors offering no references, no clear milestones, or a fixed price that sits well below everyone else's quote.
- Expect some change requests regardless of how tight the brief is, and agree upfront how those will be priced and approved.
Pro Tip: Ask every vendor the same three questions: what is excluded from this quote, how are changes priced, and what does the acceptance process look like?
A copyable brief skeleton and final checklist
Paste this into an email or RFP and fill in each line.
- Project summary:
- Objectives and KPIs:
- Target audience:
- Scope (must have / nice to have):
- Sitemap:
- Integrations and technical requirements:
- Timeline and milestones:
- Budget range:
- Approval process and contact:
Before sending, run through this checklist:
- Objectives are written as measurable outcomes, not vague ambitions.
- Must have and nice to have features are clearly separated.
- Accessibility standard and audit expectations are stated.
- Timeline includes key milestones, not just a launch date.
- Budget range and payment terms are included.
- Content ownership is assigned to a named person.
A downloadable version of this skeleton, available as a template in document form, saves you building the structure from scratch each time.
Who should be involved in deciding the brief
A brief written by one person in isolation tends to miss requirements that only surface once other stakeholders see the draft. At minimum, involve whoever controls the budget, whoever approves the final design, and whoever will manage the site day to day after launch.
For a small business, this might be just the owner and perhaps a marketing contact. For a larger organisation, it usually includes someone from marketing, someone technical who understands existing systems, and a decision-maker who can sign off budget without further escalation. Naming these people in the brief itself, with a note on who has final approval at each milestone, avoids the common problem of a vendor delivering work that then gets rejected by someone who was never consulted.
It also helps to agree, before the brief goes out, how feedback will be gathered. A single point of contact who consolidates comments from the wider team prevents vendors receiving conflicting instructions from different stakeholders on the same project.
Using competitors and inspiration sites to guide design
Including examples of sites you admire, whether direct competitors or businesses in a completely different sector, gives a vendor a shortcut to understanding your taste without you having to describe it in abstract terms. Design brief guidance recommends including working examples alongside goals and deliverables precisely because visual preference is hard to put into words accurately.
When listing examples, note what you like about each one specifically: the navigation on one, the colour palette on another, the way a third handles its homepage layout. A list of links with no commentary leaves a vendor guessing which element actually appealed to you. Competitor sites are useful for this too, not to copy them but to identify where your own site needs to do better, whether that is clearer pricing, a faster homepage or a simpler enquiry form.
What to expect for maintenance and support after launch
A brief that stops at launch day often leads to a mismatch in expectations once the site goes live and something needs updating. State in the brief whether you expect ongoing maintenance as part of the project or as a separate arrangement, and what that covers: security updates, content changes, plugin updates or technical support if something breaks.
Ask vendors directly how they handle post-launch requests, what response times look like, and whether support is included for a set period after launch or charged separately from day one. Clarifying this upfront avoids the awkward moment, a few weeks after launch, when you discover that a simple text change counts as a billable extra rather than something covered by the original project.
How a website design company can turn a brief into a low risk project
A typical process includes a short discovery conversation against the brief before any design work starts, checking objectives, must have features and content ownership so nothing gets assumed later. The focus throughout often stays on mobile-first design, SEO fundamentals and a lightweight, fast-loading build, since these affect both user experience and how easily the site gets found.
Sites are commonly built from scratch rather than from recycled templates, and clients review and approve the finished site before any payment is made, which removes the usual risk of paying upfront for work that might not meet the brief.
— Ar
How Webnora can help with your next website
If your brief is ready, or close to it, Webnora works directly from that document to scope a business website, landing page, redesign or SEO setup built specifically for your goals rather than adapted from a template. Each site is custom built, mobile-first and set up with SEO fundamentals in place from launch, which matters most for small businesses competing for local search visibility.
Because you review and approve the finished site before paying, there is no financial commitment until you can see the result matches your brief. You can view examples of past work on the portfolio page or see the process in full on the how it works page before requesting a quote.
FAQ
What are the 7 C's of a website?
Different sources define this slightly differently, but a common version covers clarity, consistency, content, customer focus, connectivity, creativity and credibility. There is no single official standard for this framework, so treat it as a useful checklist rather than a fixed rule.
What is an example of a design brief?
A typical example includes a project summary, objectives and KPIs, target audience, scope and deliverables, a sitemap, timeline, budget range and accessibility requirements. The copyable skeleton above follows this same structure and can be adapted for most small business projects.
Can you explain web design in a simple way?
Web design is the process of planning and building a website's layout, visual style and functionality so visitors can find information and complete tasks easily. It covers everything from page structure and navigation to colour, typography and how the site performs on mobile devices.
What is a brief example?
A brief is a written document that sets out what a project needs to achieve, who it is for, what it must include, and the budget and timeline available. For a website, that means stating the goal, audience, required pages and features, and any technical or accessibility standards the finished site must meet.
Sources
These sources informed the accessibility and structural guidance in this article and are useful for readers or vendors who want to verify the detail directly.