Start with one sentence: this website helps a particular person make a particular decision and take a particular action. A tutor might want someone to understand the subjects offered and request a lesson. A repair workshop might want a customer to describe a problem before a quote. Those journeys need different content and different forms.
Explain the offer and the intended visitor
Write down who the service is for, what the customer receives and any important exclusions. List the questions someone needs answered before contacting you. Useful questions include what is included, what the customer supplies, how price is agreed and what happens after an enquiry.
Keep fixed facts separate from suggestions. An approved service name, price or contact address should not change during a design exercise just because a different phrase fits the layout. Include your desired timing, any budget constraint and who approves the content. Mark anything that still needs a business decision. A designer can help structure missing content, but should not invent an ownership policy or a response-time promise.
Bring content and material you can use
Prepare the current logo, approved images, service descriptions and contact information. For each important image or claim, identify its source and the permission to use it. A reference website can communicate a visual preference; it does not grant rights to copy its photographs, wording or original artwork.
If you want to show past work, explain what was actually delivered and which details may be public. A fictional concept should remain labelled as fictional. A screenshot of a private prototype should not become a claim about a customer's sales or bookings.
Describe the customer action from end to end
For an enquiry form, say what information is needed, where it should go and who will answer. For booking or payment, identify the actual service or account that will handle it. Account access should use an agreed secure route, not passwords written into the brief.
Then consider failure. What should a visitor see if a required field is missing, a booking slot is unavailable or payment is not confirmed? How can they get help? These questions are part of the website's job, rather than details to discover after a button is added.
A fictional example: a music teacher
Suppose a music teacher offers individual lessons and wants lesson enquiries. The brief identifies adult beginners as one audience, states the actual instruments taught and explains that lesson times are agreed after contact. It includes permitted photographs and an enquiry destination.
An instant booking calendar is outside that first scope. The form must not tell a visitor a lesson is booked merely because the request was submitted. Before launch, the agreed check is that a clearly identified test request reaches the teacher and the page explains the next step accurately. This is a planning example, not a Brivendale customer result.
Agree handover and the launch checks
Ask what editable source or access you will receive, who owns each account and who handles renewals and later changes. State the intended use of any PDF, menu or downloadable material; an editable source needs an agreed format.
A compact preparation checklist is:
- One clear audience, offer and main visitor action.
- Approved facts, content and permitted assets.
- The actual enquiry, booking or payment route and its owner.
- Scope, required costs, revisions, handover and ongoing responsibilities.
- Checks for readable desktop/mobile pages, links, keyboard use and the complete customer journey.
Brivendale's website and application services can be scoped around those requirements. Bring your starting point through Your project, including what already exists and what you want someone to be able to do. The work and price are agreed for the actual project.