A better website brief starts with a business question

Start with the change

A brief becomes useful when it names a business goal. Perhaps customers cannot understand the offer, enquiries arrive without enough context, or staff spend too much time explaining the same information. Describe that friction in plain language. Identify who experiences it and what they should be able to do after the website launches.

Describe real journeys

List the questions a prospective customer asks before contacting you. Map the information needed to answer each question. A service buyer might need scope, process, evidence and a clear next step. A returning customer may need support details. These journeys help determine the navigation and page hierarchy.

Separate requirements from preferences

A preferred animation or visual reference communicates taste. A requirement describes something that must work: a form must reach the right team, an editor must update a service without changing code, or a page must remain usable on a small screen. Record both, with a reason and priority.

Define acceptance before implementation

Agree how the work will be checked. Include responsive layouts, keyboard access, enquiry storage, role permissions, editable content, redirects and deployment constraints. Give each requirement an observable outcome. This turns a subjective handover into a shared decision.

Bring the constraints into the conversation

State your hosting environment, content readiness, integration dependencies and review process. These constraints shape a practical delivery plan. A precise starting point gives strategy, design and engineering a common direction.