Website project brief: a practical template

What is a website project brief really for?

A project brief is neither a document reserved for large projects nor a way of turning an idea into fifty pages of specifications. It is a written starting point: it explains the problem to solve, the people involved, and the expected result. Its job is to make discussion concrete before tools, mockups, or prices enter the conversation.

Without that frame, two people can hear “rebuild the website” and imagine opposite projects. One imagines updating a few pages; the other imagines a new identity, a client area, and content migration. Putting the elements in writing avoids comparing quotes that do not cover the same work.

The document does not need to be perfect to be useful. It should distinguish what is already certain from what remains a question. Website design is framed much better with honest, incomplete answers than with a feature list copied from a competitor.

• The problem to solve in one or two sentences.
• The concrete result expected for visitors and for the team.
• What is certain, and which decisions are still open.
• One person able to validate the scope as the project moves forward.

Start with the goal and the people who will use the website

The first question is not “which pages do we need?” but “what must a person be able to achieve here?” Requesting a quote, booking a meeting, understanding an offer, buying a product, submitting a file, or entering a private area do not create the same journey.

Then describe the people involved in everyday language: a prospect who does not know the business yet, an existing client, a reseller, an internal team, or a candidate. For each, note what they are looking for, what could block them, and the action that matters. This creates a stronger architecture than reproducing an existing menu.

A primary goal can coexist with secondary goals, but they need to be ranked. A website trying to sell, recruit, inform, attract partners, and act as an internal tool from its homepage may do everything less well. The project brief helps choose what must come first.

• What primary action should a visitor complete in under two minutes?
• Who is the website primarily speaking to?
• Which information must reassure them before that action?
• Which measure will show the website is genuinely useful?

Define the right format: website, store, or application

A useful project brief defines the nature of the project without rushing into technology. A storefront website presents an activity and makes contact easier. A store adds a catalogue, basket, payment, and order management. An application lets people work with accounts, data, permissions, or rules that evolve.

This boundary matters because it changes the questions to ask. A presentation site mainly needs clear content, proof, and a contact journey. A store also needs to handle products, delivery, returns, and post-purchase relationships. A tool with accounts requires roles, visible data, history, and responsibilities to be defined.

The web technologies guide comes only after that decision: it helps choose a fitting foundation. When the heart of the need is to move data or enforce business rules, web app development can make more sense than a website continually patched with workarounds.

List the content before talking about design

Content is often what blocks a launch: copy, photos, product details, prices, case studies, testimonials, documents, or translations. The project brief should state what already exists, what must be rewritten, and who can validate it. This is not editorial paperwork: a page without ready content does not become clear because its mockup is finished.

It is useful to write an initial site map, even an imperfect one. Home, offers, work, about, resources, contact: these labels are not an obligation. They help check that every piece of information has a place and visitors do not have to guess where to go. If a section cannot be described in one sentence, it is probably not ready to become a page.

For each important asset, note an owner and a delivery point. That makes it possible to organise reviews without suddenly asking for copy, photos, or translations at the end of a project when nobody planned for them.

• Expected pages or sections, even as a draft.
• Copy, images, documents, and data already available.
• Content to create, review, or translate.
• One identified person for each approval.

Describe features by use, not by module names

Write what a person must be able to do, rather than the name of a plugin or technology. “A visitor can choose a time slot and receives a confirmation” is more useful than “integrate a calendar”. “The team can edit a product record without breaking the layout” describes the need better than a list of extensions.

The features worth specifying are those that genuinely change the scope: forms, booking, payment, catalogue, languages, CRM connection, client area, access roles, data import, signature, or automation. They need simple rules beside them: who can access them, which data is needed, what triggers an action, and what happens if it fails.

A future idea can be mentioned without being funded immediately. Separate essentials for launch, improvements to plan next, and hypotheses that are still vague. This protects both budget and timeline while keeping a visible path forward.

• Features essential at launch.
• Useful features that can be deferred.
• Data to enter, read, import, or export.
• Roles and permissions for each person who signs in.

Plan search visibility and existing content from the start

Search visibility is not a matter of adding keywords at the end. It starts with the subjects pages must cover, understandable titles, genuinely useful content, and stable addresses. In the project brief, note the services or questions the site must explain, the geographical areas it truly serves, and the pages already earning visibility.

For a rebuild, the existing website inventory matters as much as the new mockup. Old addresses, pages receiving visits, forms, documents, and measurement tools need to be identified before cutover. The website rebuild and SEO guide explains that preparation in detail.

Finally, plan who will update content after delivery. A website that nobody can maintain rapidly loses its value, whatever technology sits beneath it. SEO is developed over time through useful pages and observed decisions, not promised rankings.

• Existing pages to keep, improve, merge, or redirect.
• Search topics genuinely related to the offer.
• Access to analytics, domain name, and hosting.
• The person responsible for publishing after launch.

Discuss budget and timing without asking for a random number

A useful budget is not necessarily a fixed number. It can be an envelope, an order of magnitude, or several scenarios: an essential first version, a fuller version, and later extensions. What matters is stating what is included: content, design, development, migration, hosting, maintenance, training, and follow-up.

The timeline also needs real dependencies. A launch date does not say whether copy, photos, translations, products, access, and approvals will be ready in time. Note external constraints — an event, opening, contract end, campaign — then the people who must approve each stage.

This transparency makes it possible to compare proposals on the same scope. A lower quote is not automatically less suitable; it may simply include fewer pages, less migration, less guidance, or fewer functions. An estimate helps put these parameters in a concrete order before requesting a detailed quote.

• An envelope or budget scenarios rather than an isolated price.
• Target date, external constraints, and approval margin.
• What is included after launch.
• What depends on content, access, or decisions from the team.

A simple template to complete before the first meeting

The first project brief can fit in a few pages. The goal is not to create an exhaustive technical specification: the team delivering the project should still propose and explain the choices. This document makes sure everyone starts with the same problem, the same priorities, and the same visible constraints.

Start by answering in your own words. The parts where you hesitate are valuable: they become the first questions for the meeting. A serious provider will not ask you to choose hosting, a CMS, or a framework alone before understanding how the website will be used; they will help translate this document into a solution and scope.

• 1. Context: activity, trigger, and current problem.
• 2. Goal: expected result for the visitor and the organisation.
• 3. Audiences: people involved, needs, and expected actions.
• 4. Content: pages, documents, photos, proof, and owners.
• 5. Features: essential, useful, and later.
• 6. Constraints: languages, existing tools, data, timing, and access.
• 7. Budget and next steps: envelope, date, approvers, and next decisions.

The document opens the discussion; it does not replace scoping

A project brief reduces ambiguity, but it does not replace discussion or trade-offs. Some answers appear only when real content, technical constraints, or journeys are examined. The good sign is not a document full of jargon; it is being able to understand what must be decided now and what can wait.

If you already have these elements, even as notes, use them to talk about your project or begin an estimate. The first discussion can then focus on priorities, risks, and the first useful version rather than an abstract list of technologies.