Write a website brief that prevents expensive assumptions

A useful website brief defines the customer decision, the required pages and the responsibilities behind delivery. It gives the designer enough clarity to propose a scope without guessing your business.

Start with the visitor’s task

Name the people the website should help and what they need to decide. A service buyer may want scope, process and a way to discuss a requirement. A shopper needs product information and fulfilment conditions. “Make it modern” does not answer either need.

Choose a primary action for each important page. Consultation, enquiry and purchase have different content and system requirements. Keep the action realistic for the visitor’s stage rather than placing a purchase prompt on every explanatory page.

Build a page-and-purpose table

Page or section	Briefing question
Homepage	What should a new visitor understand immediately?
Service pages	Which distinct buying questions does each answer?
Evidence	What real work or clearly labelled demonstration may be shown?
Contact or consultation	Which information is needed and where does the request go?
Insights	Who writes, approves and maintains the articles?
Store, if required	Which products, payment and fulfilment scope must work?

Specify content and asset ownership

List approved business facts, service details, brand files and images with permission for use. Identify who supplies draft copy, who edits it and who signs it off. A page allowance does not necessarily include research, article writing or photography.

For a redesign, include existing routes and important dependencies. The brief should say what needs to be retained, migrated or redirected. Do not allow a visual refresh to erase a working enquiry route or a valuable page without an explicit decision.

Describe the operating requirements

Identify forms, email delivery, bookings, payment-provider connections and any external application. State which accounts already exist and who owns them. A screenshot of a desired feature does not establish access, entitlement or implementation scope.

Also decide who will maintain the site after handover. Routine content editing, software updates, backups and technical support are different responsibilities. WordPress blocks can support editable content, while shared integrations still need appropriate technical ownership.

Define acceptance and readiness

• Agreed page list and primary visitor journeys.
• Approved content, assets and necessary access.
• Mobile and keyboard review of the agreed interface.
• Actual form and integration tests in the intended environment.
• Ownership, training and launch decision.

Add your budget range, required date and approving contact. Foxbyte’s package delivery period starts after readiness and written kickoff, not simply when the first brief is sent.