A website project often starts with a conversation about appearance. That matters, but a more useful first question is: what should this website help someone do?
A clear answer makes decisions about content, navigation, design and technology much easier. You do not need a long specification to begin. A short, honest brief is usually more valuable than a list of features copied from another website.
Start with people and questions
Identify the main people who will visit. A prospective customer comparing professional services has different questions from an existing customer looking for support.
Write down what each audience needs to know. For a service business, that might include what you offer, whether it is suitable for their circumstances, how a project works and how to start a conversation.
Build the page structure around those needs. Internal department names rarely make good navigation labels if customers do not use the same language.
Choose a useful next step
Decide what the primary action should be. It could be an enquiry, a booking, a purchase or access to a useful resource. You can support more than one action, but treating everything as equally important usually makes a page harder to understand.
Keep enquiry forms proportionate. Ask for the information needed to understand the request, not everything that might be useful later. Mark optional fields clearly and explain what happens to the information.
An enquiry form also needs a real delivery route, server-side validation, spam handling and tested failure states. A form that looks finished but cannot send a message is not a finished enquiry journey.
Treat content as part of the project
Content affects layouts and timelines. Before design begins, establish who will write, review and approve it.
Useful starting material includes:
- A plain-language explanation of each service.
- Common customer questions and sensible answers.
- Genuine project information that can be published.
- Approved photographs and relevant usage permissions.
- Accurate business and contact details.
Avoid filling trust sections with unsupported claims. If testimonials are not approved, leave them out. A specific explanation of your process is more credible than an invented quote.
Decide how updates will happen
Not every website needs a content management system. A frequently updated publication and a small service website have different needs.
A static site can be a good fit when content changes infrequently and developer-supported updates are acceptable. A CMS can be worthwhile when a team needs to publish regularly. It also introduces editing workflows, access management and maintenance responsibilities.
Choose based on who will update the site, how often and with what level of technical confidence, rather than familiarity with a particular platform.
Plan for an existing website
If this is a replacement, record important URLs, content, downloads and integrations. Where URLs change, plan appropriate permanent redirects. Redirect a page to its closest useful equivalent, not automatically to the homepage.
Review available search data before removing content. Technical care during migration can avoid unnecessary disruption, but no one can guarantee that rankings will remain unchanged.
Keep a rollback plan and a copy of the old site before switching the domain to the new version.
Define what “ready to launch” means
Agree a small set of acceptance criteria. Include mobile layouts, keyboard navigation, working forms, metadata, broken links and the hosting setup.
Name the person responsible for the domain, hosting, backups, form delivery and future updates. Decide how problems will be reported after launch and what support is included.
A useful brief does not remove every unknown. It gives everyone a shared starting point and a sensible way to make decisions as the work develops.
If you are still at the “we know something needs to change” stage, that is enough to start a conversation. The first task can be making the problem clearer.