How to brief a business website that has a job to do.

Start with a decision, not a page count.

“We need a premium website” describes an impression. A useful brief describes a change: a buyer should understand the product, compare the right options and start a qualified conversation. Write that change in one sentence. Then name the audience, the buying situation and the action you want to make easier.

A lighting retailer might need customers to shortlist pieces before a showroom visit. A specialist service business might need a buyer to understand scope before booking a call. Those are different jobs, even if both sites need beautiful imagery.

Separate evidence from aspiration.

Collect the materials that actually exist: product photographs, specifications, approved project examples and current business information. Mark anything awaiting approval. A website should not have to invent proof because the brief only contains adjectives.

For every case study, record what was delivered, what is live and what has been measured. A screenshot is evidence of an interface. It does not, by itself, prove more sales. Real constraints give designers better material than generic claims.

Make the enquiry route part of the design.

Decide who receives a lead and what they need to respond. A short form with service, context, timing and contact details may be more useful than a large questionnaire. Tell people what happens after submission.

Test the failure path as carefully as the success screen. If storage is unavailable, preserve the input and offer a retry or a reviewed handoff to another channel. A button click is not a lead until the intended system has received it.

Give motion a purpose and a boundary.

Use motion to introduce a composition, explain a change or guide attention. Keep navigation and the main action available while an opening plays. Content must remain understandable with motion disabled or media missing.

Include small-screen layouts, keyboard access, reduced motion and image budgets in the brief. These decisions are easier to protect when they are acceptance criteria, rather than items remembered just before launch.

Agree what happens after the launch.

Name the owner of content, hosting, enquiries and updates. Separate the one-time build from ongoing costs and responsibilities. Document how to restore the previous release and export the data.

Start measuring a small number of meaningful events: completed enquiries, qualified conversations and the paths people take to them. Improve the experience from actual questions and behaviour before adding more pages or animations.

Keep the useful part

The short checklist.

One audience and one primary next step
Approved facts, assets and project permissions
A working enquiry destination and owner
Mobile, accessibility and performance acceptance checks
Clear handover, maintenance and measurement responsibilities

Have a brief in mind?

Bring the context. We’ll help work out a useful next step.

Start the conversation