Start with the job the website must do
A website brief should describe the people using the site, the tasks they need to complete and the information the organization must maintain. A local service company may care most about enquiries and service-area clarity. An association may need resources, events and member information. An ecommerce project needs product discovery, inventory and checkout decisions.
When those needs are clear, technology becomes easier to choose. Starting with a favourite platform often leads to workarounds that would have been unnecessary if requirements came first.
Build a page inventory
List the pages that exist now, the pages that are actually useful and the gaps visitors still encounter. Keep important existing URLs in the migration plan when they have links, traffic or established search visibility. Merge duplicated or thin pages when one stronger page would serve people better.
Assign content ownership
Every important page should have someone responsible for keeping it accurate. Rates, staff details, locations, policies and service descriptions decay quickly when nobody owns the update process.
Define integrations early
Booking tools, payments, CRM systems, email marketing, maps, inventory, analytics and account areas can affect both architecture and privacy. Identify them before design approval so they are not bolted on at the end.
Prepare for launch and ownership
Before launch, document the domain registrar, DNS, hosting account, administrator access, analytics, third-party services and backup/recovery process. The organization should know how to regain access if a contractor is unavailable.
Plan content around decisions, not departments
Visitors rarely think in the same categories an organization uses internally. A customer may want to compare services, confirm whether a business serves a particular location, understand the process, or find the right contact. Organizing the website around those decisions usually produces clearer navigation than mirroring an internal org chart.
For service businesses, this often means separating high-intent service pages from broader informational guides. For example, a transportation site may need airport, hourly, chauffeur and long-distance route pages, while a city guide may need things-to-do, itineraries, neighbourhoods and trip-planning resources. The structure should reflect the task, not a template.
Write a requirements sheet before design starts
A practical requirements sheet should cover the number of page types, forms, data sources, third-party tools, administrator roles, required integrations, accessibility expectations, analytics, migration needs and launch constraints. It does not need to be a technical specification. Its purpose is to expose decisions early enough that they can influence the design.
- Identify the primary conversion or completion goal for each important page.
- Record which information changes often and who is responsible for updating it.
- List any existing URLs that must be preserved or redirected.
- Define whether the site needs search, accounts, booking, ecommerce, maps or database-backed content.
- Decide what must work without JavaScript and what genuinely requires interaction.
Use comparable live sites carefully
Reference sites are useful when they are used to discuss specific decisions rather than copied wholesale. WebsiteForLess.ca is an example of a service-led structure with planning guides and portfolio content, while Surrey-BC.ca demonstrates a deeper editorial architecture built around destination information rather than lead generation.
A more application-oriented project such as MyLimoRide.com has different requirements again because trip types, rates, stops and booking flow have to be considered as part of the interface. The lesson is not that one layout is better. It is that the website plan should match the job.