A useful website brief explains the business decision, priority audiences, important user journeys, required evidence and content, functional dependencies, quality standards, success measures and who owns each decision. It gives the delivery team enough context to solve the problem without prescribing every screen in advance.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Begin with the business decision, not the visual style
A website brief should first explain why the project exists and what must improve. Examples include helping qualified buyers understand a complex service, reducing unsuitable enquiries, supporting a new market or replacing a site that the team cannot maintain. A statement such as ‘make it modern’ describes a preference, not a business outcome.
Name the commercial or operational decision the website must support, the current evidence and the constraints that cannot move. Include the launch window, responsible decision-makers, legal or brand requirements and any systems that the site must continue to work with.
GOV.UK's service guidance recommends understanding users and the problem before committing to a particular solution. The same discipline makes a commercial website brief more useful: describe the problem clearly, then allow research, content and design to shape the most appropriate experience.
- Why the project is needed now
- The business outcome that should change
- Known constraints, dependencies and approvals
- The person who can make scope and content decisions
Define priority audiences and the journeys they must complete
List the audiences in priority order and describe what each person needs to decide or do. A buyer comparing suppliers needs different evidence from a returning customer seeking support, a candidate considering a role or a partner checking company information.
Map the important journey from arrival to outcome. Note likely entry pages, the questions that must be answered, the proof required and the next action. Include less confident users, mobile visitors and people arriving from search, advertisements, referrals or shared links rather than assuming everyone begins on the homepage.
Keep audience descriptions tied to observable needs. Internal labels such as ‘enterprise persona’ are less useful than the situation, urgency, objections and information needed to move forward.
- Priority audience and the situation that brings them to the site
- Top questions and concerns before they contact you
- Desired outcomes such as enquiry, booking, application or self-service
- Alternative routes for people who are not ready to convert
Inventory content, proof and ownership before design begins
A premium interface cannot compensate for missing or unapproved content. Identify the pages and reusable content types required, what already exists, what must be rewritten and who can verify each claim. Separate confirmed proof from material that is still an aspiration.
Provide accurate service information, locations, contact routes, policies, product details and brand assets. Real case studies need permission and evidence; testimonials, numerical results, certifications and partner logos should not be invented or published without approval.
For every important page, define its purpose, primary reader, key message, supporting evidence and next step. This creates a content model that can survive visual redesigns and future additions.
- Existing pages and files to keep, improve, merge or retire
- Approved logos, photography, video and brand guidelines
- Claims, case studies and credentials with an evidence owner
- Content author, reviewer and final approver for each section
Specify functions, integrations and failure behaviour
Describe what the website must do beyond displaying pages. Common requirements include forms, appointment booking, CRM handoff, payments, customer portals, multilingual content, search, analytics, marketing consent and connections to existing tools.
For each integration, record the system owner, available access, data that moves, expected confirmation and what happens when the connection fails. A form is not complete merely because it shows a success message; the enquiry must reach the right team, remain traceable and avoid exposing personal information.
Define roles and operating responsibilities. The brief should say who publishes content, responds to leads, reviews errors, renews services and approves changes after launch.
- Required functions and the user journey each one supports
- Systems, data fields and permission boundaries
- Success, error, retry and manual fallback behaviour
- Post-launch owners for content, enquiries and technical support
Make accessibility, performance and search acceptance criteria
Quality expectations belong in the brief, not in a final polish list. Set an accessibility target, supported devices and browsers, content readability expectations and the testing needed before acceptance. W3C guidance recommends defining accessibility goals, responsibilities, resources and ongoing monitoring rather than assigning the work to one late-stage review.
Describe performance in terms of user experience. Core Web Vitals cover loading, responsiveness and visual stability through LCP, INP and CLS. Treat them as measurable quality signals while also testing the actual pages, devices and network conditions important to the audience.
Search requirements should include descriptive page titles, crawlable navigation, canonical URLs, useful page copy, structured business information and a sitemap. Google recommends standard links with href attributes and clear anchor text so people and crawlers can understand where links lead.
- Accessibility target and who verifies it
- Mobile, browser and realistic network test conditions
- Performance budget for important templates and media
- Crawlable links, metadata, canonical rules and structured information
Agree measurement, delivery stages and the launch boundary
Choose measures that reflect the website's purpose before selecting dashboards. Useful signals may include qualified enquiry completion, booked consultations, successful self-service, content engagement on decision pages, support demand and the sources of unsuitable leads.
State which events and conversions need measurement, the consent and privacy constraints, who reviews the data and what decision each measure informs. Avoid collecting information simply because a tool makes it available.
Finish the brief with delivery stages, review points, acceptance owners and explicit exclusions. Plan content migration, redirects, analytics validation, backups, rollback, team training and post-launch observation. A clear launch boundary protects quality while keeping later ideas visible in a separate backlog.
- Decision-linked conversion and journey measures
- Discovery, content, design, build, testing and launch reviews
- Acceptance criteria and named approvers
- Redirect, backup, rollback and post-launch monitoring plan
Further reading
Frequently asked questions
How long should a website brief be?+
It should be long enough to remove important ambiguity and short enough for every decision-maker to use. A focused brief with linked evidence, a content inventory and acceptance criteria is usually more valuable than a long document filled with generic company history.
Should a website brief specify the exact design?+
It should document brand rules, required assets, constraints and examples of relevant preferences, but it should not prescribe every screen before the team understands the users, content and journeys. Define the outcome and acceptance standard, then let design solve the problem.
What technical details belong in the brief?+
Include required functions, integrations, data flows, permissions, content management needs, accessibility and performance targets, analytics, search requirements, hosting constraints and post-launch ownership. Unknowns should be marked for discovery rather than guessed.
Who should approve a website brief?+
The business owner, content owner and delivery lead should agree it, with input from people responsible for sales, operations, legal or privacy, support and technical systems where relevant. Name one person who can make final scope decisions.