# How to Write a Website Project Brief for Your Small Business

https://ragipdiler.com/en/blog/working-together/website-project-brief/

By [Ragip Diler](https://ragipdiler.com/en/author/ragip-diler/) · 2026-10-28

A website project brief explains what your business needs the website to do, who it serves, what work is expected, and which constraints affect delivery. To write one, describe the customer and the problem first, then list the pages, content, functions, responsibilities, budget boundaries, and launch requirements. Mark anything you have not decided rather than asking a designer to guess.

You can start with short answers. The purpose is to give a designer enough context to ask useful questions and propose a defined scope. If you approach more than one provider, send the same brief and share any scope updates with each of them.

## Describe the business and the customer

Begin with what you do, whom you serve, and where you operate. Include your current website address if you have one, the languages the new site needs, and the person responsible for the project.

Then describe a customer situation. “Local homeowners planning a bathroom renovation” provides a clearer starting point than “anyone who needs a plumber.” Add what that person needs to understand before contacting you: coverage, types of work, availability, relevant experience, or the information needed for an estimate.

Keep business facts separate from assumptions. If staff have recorded inquiries from outside your service area, that is evidence you can share in an anonymized summary. If you suspect people cannot find the coverage information, label that as a question to investigate.

For an existing site, explain what you want to retain as well as what should change. Existing service information, useful photographs, a recognizable identity, or an editor your team understands may all influence the scope.

## State the outcome and the primary action

Explain the business problem without prescribing every screen.

“Make the website look modern” leaves the project open to interpretation. “Help customers check our service area and send a request our office can assess” identifies a task the website and team need to support.

Name the primary action, such as calling, requesting a quote, or booking an appointment. Explain what happens afterward. If a person submits a preferred time and reception must confirm it, describe the action as an appointment request.

Separate the desired business outcome from the checks used to accept the website:

| Type | Example |
|---|---|
| Business outcome | Receive more inquiries that match the services and locations the business supports |
| Website requirement | Make service coverage clear before a customer submits a request |
| Acceptance check | A test request reaches the agreed destination and shows the customer an accurate acknowledgment |
| Measurement plan | The office records which inquiries are suitable and why others are not |

These are illustrative requirements, not measured results. A working form can be checked before launch; whether inquiry quality improves needs evidence afterward.

If you have a reliable baseline, include it with its source and reporting period. If you do not, write “baseline not available” and assign someone to decide how it will be established. Avoid inventing a percentage target to make the brief appear more precise.

## List pages, content, and integrations

Give every proposed page a purpose. Use the [small business website planning checklist](/en/blog/business-websites/small-business-website-checklist/) to identify the information customers need, then record what you expect the project to include.

For each page or page type, note:

- The question it should answer and the next action it supports.
- Whether it is new, retained, revised, or removed.
- Who supplies and approves its text and images.
- Whether its content is ready or still needs work.

Be specific about scale. A design for one reusable service-page layout and the population of several service pages are different tasks. State both how many layouts are expected and how much content needs to be added, where known. Ask the provider to identify any remaining assumptions.

### Describe functions by what they must do

“Contact form” does not explain where the request goes or who handles it. “Send quote requests to our shared office inbox and acknowledge receipt without promising a price” gives the designer a process to work with.

For each function or integration, describe the trigger, destination, and responsible person. Include existing booking tools, email services, payment tools, or customer-management systems only where they are relevant. Say whether the tool already exists and who can arrange access. Share access securely later; keep passwords out of the brief.

Distinguish a link to another service, an embedded tool, and a custom connection. If you do not know which is appropriate, describe the intended experience and request a recommendation. The technical approach can be resolved during scoping.

### Record existing content and URL changes

For a redesign, include the current pages and files that need reviewing or moving. Ask the provider to identify who handles old-to-new URL mapping, redirects, and launch checks if addresses change. These are part of Google’s [guidance on site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), and should have an explicit place in the scope when applicable.

List brand assets and references too. Explain what you find useful in a reference, such as the way services are grouped or appointment status is explained. That gives the designer context without requiring a copy of another business’s website.

## Agree ownership, approvals, and constraints

Identify the project contact and final approver. Record who can verify service claims, supply content, review designs, and authorize publication. Include any availability limits that affect reviews.

State the delivery you need. Do you want design files for a separate developer, or a working website with content added and launch support? If responsibility is split, explain who coordinates the handoff and checks the finished implementation.

Include the following constraints where they apply:

| Area | What to clarify |
|---|---|
| Budget | Available range or ceiling, what it covers, and whether ongoing costs need a separate allowance |
| Timing | Desired launch date, the reason it matters, and dependencies such as content or tool access |
| Accounts | Who controls the domain, hosting, editor, and connected tools |
| Maintenance | Who updates content, handles technical upkeep, and receives post-launch questions |
| Accessibility | Intended standard or target, evaluation scope, and responsibility for addressing findings |
| Policies and approvals | Who supplies or arranges review of the policy wording and business-specific claims |

Accessibility needs an owner and resources. The [W3C Web Accessibility Initiative’s planning guidance](https://www.w3.org/WAI/planning-and-managing/plan/) recommends defining goals, assigning responsibilities, and planning evaluation. If you need help determining an appropriate scope, make that an open question in the brief.

These responsibilities also help you choose the right design partner: you can explain whether you need someone to lead the whole website project or contribute to a defined part of it.

## Fill in the example project brief

The following is a fictional planning example for a local plumbing business. It illustrates scope decisions, not a completed client project, a verified business problem, or a quoted service package.

### Worked example: a plumbing website redesign

| Brief section | Example answer |
|---|---|
| Business and customer | A local plumbing business serving homeowners within an approved coverage area. This project focuses on planned repairs and installations. |
| Reason for the project | The owner wants clearer service information and a defined route for quote requests. Whether the current site causes unsuitable inquiries remains unverified. |
| Primary action | Request a quote. Customers can also call during the published office hours. |
| Business outcome | Help the office receive inquiries it can assess against service scope and coverage. No reliable baseline is available yet. |
| Measurement owner | The office manager will agree a way to record inquiry suitability and establish a baseline before launch. |
| Proposed pages | Home; services overview; three individual service pages; service area; about; contact and quote request; applicable policy content. Final inventory to be confirmed during scoping. |
| Page and layout scope | The provider should distinguish reusable layouts from the work of adding all agreed pages and content. |
| Content | The owner supplies service facts and approved job photographs. The proposal should state whether copywriting is included. The owner approves final service claims. |
| Quote-request process | Requests go to the office inbox. The office manager reviews them. The acknowledgment confirms receipt and explains the agreed next step; it does not promise a price or visit. |
| Integrations | No custom customer-management connection is required at launch. The provider should recommend how to deliver and check form messages. |
| Existing content | Review current pages and photographs. Prepare a URL inventory and identify any redirects needed before replacing pages. |
| Delivery | Request a proposal covering design, implementation, content population, testing, and launch, with responsibilities and exclusions stated. |
| Accounts and editing | Business-controlled accounts. The office manager needs to edit service descriptions and hours; the provider should explain how that will work. |
| Approval and schedule | Owner is final approver. The desired launch follows content approval; dates and review windows must be agreed before scheduling. |
| Budget | Owner to confirm an available range before requesting a fixed-scope proposal. Separate project costs from recurring services and optional support. |
| Launch checks | Agreed pages contain approved content; coverage and contact details are accurate; a test request reaches the office; acknowledgment wording is correct; editing access and agreed checks are complete. |
| Outside launch scope | Online payments, customer accounts, a custom quoting calculator, and a new brand identity. |
| Open questions | Copywriting scope, accessibility target and evaluation, maintenance arrangement, policy-content review, and the final launch date. |

Notice that the example leaves some decisions open while assigning a route to resolve them. An incomplete answer is useful when it makes an uncertainty visible.

### Copyable website project brief template

Copy the prompts below into a document. Use “not applicable” where appropriate. For an unresolved item, add who will resolve it and when the answer is needed.

**Project and version**  
Project name: __________  
Brief owner and date: __________  
Current website, if any: __________  
Project contact and final approver: __________

**1. Business and customers**  
What we do: __________  
Primary customer and situation: __________  
Locations and languages: __________  
Questions customers need answered: __________

**2. Reason and outcome**  
Why we are starting this project: __________  
Known problems and supporting evidence: __________  
Assumptions still to check: __________  
Desired business outcome: __________  
Primary customer action and what happens afterward: __________  
Baseline, measurement method, and owner: __________

**3. Pages and content**  
Proposed pages or page types and their purposes: __________  
Existing content to retain, revise, move, or remove: __________  
Who supplies and approves text and images: __________  
Content that is missing, its owner, and expected availability: __________  
Brand assets and references, with reasons: __________

**4. Functions and tools**  
Required functions and the tasks they support: __________  
Existing tools, intended connections, and access owners: __________  
Who receives and handles customer requests: __________  
Technical decisions where advice is needed: __________

**5. Delivery and ownership**  
Design-only or working-website delivery expected: __________  
Implementation, content-entry, and migration responsibilities: __________  
Domain, hosting, editor, and tool-account ownership: __________  
Editing guidance or handover needed: __________  
Maintenance and post-launch support to discuss: __________

**6. Constraints and approval**  
Budget range or ceiling and what it covers: __________  
Recurring-cost allowance or open question: __________  
Desired launch date, reason, and dependencies: __________  
Reviewers, final approver, and review availability: __________  
Accessibility goals, evaluation, and responsibilities: __________  
Policy-content and business-claim review owner: __________

**7. Scope boundaries and checks**  
Essential for the first launch: __________  
Optional later work: __________  
Outside this project: __________  
Checks required before launch and who signs them off: __________  
Open questions, decision owners, and required decision dates: __________

Send the completed brief with your supporting material and ask the designer to identify assumptions, exclusions, and questions before confirming the scope. Keep a dated version as decisions change. That shared starting point gives you clearer inputs when you later compare website proposals.

For help taking the brief into design and implementation, explore my [website design and development](/en/services/website-design/) service.

Include your website if you have one, the customer action you want to support, and the decisions where you need help.


[Send me your project brief](mailto:dilerragip@gmail.com?subject=Website%20project%20brief)