What is a website project brief?
A website project brief is a working agreement about the problem, the people the site should help, the content and features needed, and the limits of the project. It gives the client, designer, developer and content team the same reference point before layouts or code begin.
A useful brief does not need to predict every screen. It should make the important decisions visible and identify the decisions that still need research. If a detail is unknown, write that down with an owner and a date for resolving it.
Start with the business outcome, not a list of pages
Describe what should be different after the site launches. “Build a modern website” describes an output. “Help qualified buyers understand our service and request a consultation” describes an outcome that can guide navigation, content and calls to action.
Add one primary visitor action and any supporting actions. For example, the main action might be requesting a quote; supporting actions might be reading a service page, reviewing work or downloading a specification. Avoid making every action equally prominent.
Choose evidence that can be measured without inventing a promised result. Examples include completed enquiries, product purchases, qualified calls, downloads or successful task completion in usability testing. Record the current baseline when one exists, and state when measurement will begin.
Define the audience and the questions they arrive with
Replace broad labels such as “everyone” or “business owners” with useful context. Note who the priority audience is, what they already know, what may make them hesitate and what information they need before taking the next step.
A concise audience note can follow this pattern:
- Audience: operations managers comparing suppliers for a time-sensitive project.
- Situation: they may be visiting on a phone after receiving a recommendation.
- Questions: can this team handle the required scope, what is the process, and how do we start?
- Desired next step: send a short project enquiry with enough detail for a useful reply.
This is a planning hypothesis. Validate it through existing enquiries, sales conversations, support questions, analytics or user research where available.
List content before approving the sitemap
Identify the content needed to answer the audience’s questions: service explanations, product information, evidence, policies, contact details and any downloads. Then assign an owner, source and approval status to each item. “Copy to follow” is a project risk when design depends on the length or structure of that copy.
For an existing site, create a content inventory with the current URL and a decision: keep, improve, combine, redirect or remove. Do not change useful URLs simply to make them look new. Google recommends logical site organization, descriptive URLs and useful internal links in its SEO Starter Guide.
Draft a small sitemap only after the content is understood. Each proposed page should have a purpose, intended audience question and next step. A page title in a diagram is not a substitute for content planning.
Separate required scope from possible ideas
Write the confirmed deliverables in concrete terms. Include page templates, content migration, forms, search, ecommerce functions, account areas, languages, integrations and analytics events. For each integration, record who owns the account and whether access already exists.
Add an explicit “not included” section. It might exclude copywriting, photography, product entry, ongoing SEO work or third-party subscription fees. This protects both sides from assuming that a related activity is automatically part of the project.
Keep a separate future-ideas list. A useful idea does not need to enter the first release. If it does enter scope, update the brief, timing and responsibilities together.
State design and brand constraints with examples
Supply approved logo files, colours, type guidance, image rules and brand language. Link to examples and explain what is relevant about each one: information hierarchy, navigation behaviour, editorial tone or motion. “Make it like this site” leaves too much open to interpretation.
Record practical constraints such as required legal wording, image licensing, supported languages and who can approve brand decisions. If no established visual system exists, say whether creating one is part of the project.
Put accessibility, responsive behaviour and performance in the brief
These requirements affect content, design, development and testing, so they belong in planning rather than a final checklist. W3C recommends integrating accessibility throughout the production process and evaluating it early, when problems are easier to address. See its guidance on planning and managing web accessibility and its WCAG overview.
State the intended accessibility standard or review approach, along with known needs for keyboard use, text alternatives, captions, readable error messages and zoom. Do not claim formal conformance unless the agreed evaluation supports that claim.
Name the devices and journeys that matter, while expecting layouts to adapt across screen sizes rather than targeting a few fixed devices. The MDN responsive design guide explains this multi-device approach.
For performance, define a budget or measurable target instead of writing “fast.” A performance budget can limit page weight, request count or user-centred metrics and gives the team a reference for design and technology choices. Google’s web.dev guide explains performance budgets; final targets should reflect the site’s audience, content and measurement method.
Include search and measurement requirements
List the services, products, locations or questions the site genuinely needs to explain. This is input for page structure and useful copy, not a request to repeat keywords. Google advises creating people-first content while using SEO to help search engines discover and understand it; see its guidance on helpful, people-first content.
Record technical needs such as editable titles and descriptions, canonical URLs, redirects, XML sitemaps, structured data where appropriate, and access to Search Console after launch. For measurement, define the decisions analytics should support. Track meaningful events and keep personal message content out of analytics parameters.
Clarify ownership, approvals and launch responsibilities
Name one decision-maker for each area: scope, content, design, technical access and launch approval. Document the review method, expected response time and number of revision rounds. Feedback such as “make it pop” is hard to act on; feedback tied to the audience, goal or requirement is easier to evaluate.
The brief should also say who supplies domain, DNS, hosting, email, ecommerce and analytics access; who approves privacy and legal content; who tests migrated content; and who maintains the site after launch. Never place passwords inside the brief—use an approved secure credential-sharing method.
A compact website brief checklist
- Project background and the reason for doing the work now
- Primary business outcome and visitor action
- Priority audiences, situations, questions and barriers
- Success evidence, baseline and measurement owner
- Content inventory, owners, approval status and sitemap
- Required pages, templates, features and integrations
- Explicit exclusions and future ideas
- Brand assets, design constraints and reference explanations
- Accessibility standard or evaluation approach
- Responsive behaviour and browser/device priorities
- Performance budget or measurable performance goals
- SEO, URL, redirect, metadata and Search Console needs
- Analytics events and privacy constraints
- Timeline, dependencies, review stages and decision-makers
- Hosting, domain, launch, handover and maintenance ownership
End the brief with open questions and assumptions. Review it together before design begins, then update it when an approved decision changes the project.
Turn the brief into a practical project plan
A clear brief gives discovery, design and development a shared starting point. WebHolick’s website design, UI/UX design and website development services connect those stages. If you are replacing an existing site, continue with the website redesign checklist. To discuss a project, send WebHolick your brief or current questions.