Begin with the job of the website
A useful brief describes the decision the website should support, not only the pages it should contain. The goal may be to make a complex offer easier to evaluate, prepare better enquiries or give an international audience a credible first view.
Name the primary audience
Choose the group whose questions should shape the first release. Secondary audiences can still be served without giving every group equal weight.
Define the next meaningful action
Decide whether the appropriate step is an enquiry, call, product exploration or another action that genuinely fits the buying journey.
Treat content as part of the product
Content determines structure, page rhythm and the evidence available to visitors. Waiting until the interface is finished usually creates avoidable redesign work.
Assign owners
Identify who can approve service descriptions, legal wording, imagery and technical claims before they become launch blockers.
Separate verified facts from aspirations
Use claims the business can support today. Keep future services and unverified outcomes clearly framed as plans rather than proof.
Make constraints visible early
Budget, timing, integrations, languages and internal approval cycles all influence the right solution. A strong scope uses these boundaries to guide choices rather than hide them.
List required systems
Record forms, analytics, CRM, commerce and content tools together with access owners and any known data restrictions.
Agree how launch will be judged
Set a small set of observable quality checks for content, accessibility, performance and critical journeys before discussing future growth.
Turn audiences into decision journeys
A label such as ‘small business owner’ is not enough to shape a useful page. Record what the person is trying to decide, what they already understand, what may make them hesitate and which evidence would help. This turns broad audience descriptions into practical choices about sequence, emphasis and calls to action.
Capture the questions behind each visit
Write the questions a visitor needs answered before moving forward. Group them by awareness, comparison and commitment so the site can support several levels of readiness without forcing everyone into the same path.
Choose a proportionate next step
An enquiry, call, product comparison, document download or related page can each be appropriate. The call to action should match the decision being made and explain what happens next, including any information the visitor must provide.
Document requirements as real flows
A feature list can hide important operational detail. ‘Contact form’, for example, does not explain what data is collected, who receives it, where it is stored or what happens when delivery fails. Describe each important feature from the visitor’s action through to the team’s response, including permissions and fallback states.
Map systems, access and data
List the CRM, analytics, booking, commerce and content tools involved. Name the account owner, required access, information exchanged and known privacy or retention constraints before an integration becomes a late technical surprise.
Plan multilingual ownership
Define which pages exist in each language, who translates and approves them, and whether regional contact details, pricing or legal wording differ. Translation is an ongoing publishing workflow, not a final export after design is complete.
Agree governance before production
A brief is also a working agreement. It should say who can make day-to-day decisions, which changes require wider approval and how unresolved questions are recorded. Clear governance protects the schedule while still leaving room for discovery, and it prevents late feedback from quietly rewriting decisions that earlier work depends on.
Create a precise acceptance checklist
Include content approval, responsive behaviour, keyboard access, form states, metadata, performance checks and critical browser journeys. State the tested scope accurately instead of implying that every device, network and edge case has been covered.
Prepare ownership and continuity
Confirm who controls the domain, hosting, repository, analytics and third-party accounts. Record redirect needs, credential handover, post-launch monitoring and the person responsible for routine content and dependency updates.
Questions readers ask
Not necessarily, but core messages, representative content, page types and approval ownership should be clear enough to shape realistic layouts. Detailed copy can continue in parallel when milestones and review responsibilities are explicit.
Use a small decision group that understands business goals, customer questions, content, technology and any legal constraints. Wider stakeholders can review at defined points; bringing everyone into every session often makes ownership less clear.
It should expose major assumptions without pretending discovery is complete. Record the objective, audiences, required content and functions, owners, constraints, approval method and launch checks, then mark genuine unknowns as questions to resolve.