Start with the moment someone arrives
Imagine one specific visitor opening the site. What happened just before that moment? Perhaps a recommendation brought them to a service business. Perhaps they searched for a product and need to understand delivery. A returning customer may already know the company and simply need an opening time. These visits require different information.
Write down the two or three most important situations. Use customer questions, enquiry emails and conversations as evidence. The GOV.UK Service Manual offers a useful principle here: understand what people are trying to achieve before deciding which features to build. A request for a chatbot may turn out to be a need for clearer answers about pricing.
Choose one primary action
Decide what a successful visit looks like. For an independent studio, it might be a qualified project enquiry. For a restaurant, it might be a reservation. Secondary actions can still exist, but giving every button equal emphasis makes the visitor do the prioritising.
Be precise about the action and its destination. “More leads” is an ambition. “A visitor understands the service, checks whether the likely scope fits, and submits a short project form” describes something a designer can make. It also exposes missing decisions: what qualifies an enquiry, who receives it, and how soon someone can respond?
Inventory the content before the pages
Collect the material you already have: service descriptions, photographs, product information, frequently asked questions and evidence of work. Mark each item as ready, needing revision or missing. Assign an owner. A beautiful case study layout is not useful if nobody can supply the problem, the work and the outcome.
Keep evidence honest. A concept project can show ability if it is labelled as a concept. A working prototype can demonstrate a useful interaction without becoming a claim about customer results. Decide which claims can be supported and remove the rest before design begins. This makes the final website easier to trust and easier to write.
- What must a visitor know before making contact?
- Which images and words can you legally publish?
- Who owns each missing piece of content?
- Which information will need regular updates?
Name the constraints that shape the work
A useful brief includes a budget range, the reason for the deadline, and the person who can approve decisions. It also lists existing systems that matter: booking software, payment tools, mailing lists or a customer database. Explain the job each connection performs instead of assuming that every tool needs a new integration.
Describe maintenance in practical terms. If someone needs to change a menu every week, editing that menu is part of the product. If the site will rarely change, a smaller publishing setup may be easier to support. Include responsibility for the domain, hosting, backups and account access so ownership remains clear after handover.
Make the first version easy to judge
Finish with a short acceptance checklist. Use observable tasks: a visitor can read the core offer on a phone, send an enquiry, recover from a form error and navigate with a keyboard. Agree on which pages and integrations belong in the first release. Keep later ideas in a separate list with their purpose attached.
Here is an illustrative brief in one paragraph: a local repair business needs homeowners to understand its service area and request a call back. The first release contains services, coverage, common questions and contact. The owner supplies photographs and answers, approves the copy and manages enquiries. Online payment can wait until the booking process is understood. That is enough direction to start a useful conversation.