A Website Brief That Prevents Expensive Surprises

A useful website brief describes a job the site needs to do. It gives a designer or developer enough information to distinguish a simple public page from a system that stores records, assigns work, or accepts payments. The best starting point is usually one real customer journey, written in plain language.

This guide is a scoping method, not a promise that one package fits every business. Use it to make proposals easier to compare and to identify the decisions you still need to make.

Start with a visitor and one action

Write down who arrives, what they already know, and what they should do next. “A homeowner with a leaking pipe should understand our service area and request a callback” is more useful than “we need a modern website.” It identifies a visitor, an urgent question, and a next step.

List the information that person needs before taking action. Services, relevant examples, location, availability, and a clear contact route often matter more than a long feature list. Choose evidence you can actually supply. Do not add invented testimonials or performance figures to fill a layout.

Describe what happens after contact

An email link, an email-delivered inquiry form, and a saved lead inbox are different deliverables. A form can look identical while the work behind it changes substantially.

Describe the handoff explicitly: who receives the request, which details are required, where the record lives, and who follows up. If staff need statuses, assignments, private notes, or permissions, say so before agreeing to a public-site-only proposal. Those capabilities affect the backend and the review process.

Inventory content and access

Separate material that is ready from material that still needs work. Include your logo, service descriptions, approved images, contact information, policies, and examples of completed work. Mark the person who can approve each item.

For accounts, identify the domain owner and the person who can arrange hosting access. Do not put passwords in a public project brief. Agree on an access-sharing method during kickoff. Keep vendor subscriptions, business email, stock media, and domain registration visible as separate responsibilities.

Set a review boundary

A revision round should mean a consolidated review of the agreed build, rather than an unlimited stream of changed requirements. Name the reviewer and describe how feedback will be collected.

Write a short acceptance checklist. Can visitors find the service? Does the contact route work? Do agreed pages contain the supplied content? Is the layout usable on a phone? If a backend is included, add its specific permission and record-handling checks. New pages, integrations, or workflows should be treated as scope changes.

Use the brief to compare proposals

Compare inclusions, exclusions, content responsibilities, third-party costs, revisions, and handoff. A lower number is hard to interpret when one proposal includes a lead workspace and another stops at email.

You do not need every detail settled before an initial conversation. A clear first workflow and an honest list of unknowns are enough to begin. Explore DDG website scopes, or use the build finder to identify a starting point.