Before You Rebuild Your Website: A Practical Briefing Checklist

Separate visual problems from content and workflow problems, and prepare the information a useful rebuild brief needs.

A website rebuild should begin with a reason more specific than looking dated. Perhaps prospects cannot understand the offer, staff cannot update important pages or enquiries arrive without enough context. Write down the problem and how you will recognise an improvement before choosing a new visual direction.

List what already works. Identify useful pages, customer questions answered well, enquiry routes and integrations that staff rely on. Ask the people who handle incoming enquiries which pages customers mention. A rebuild should preserve valuable content and working processes unless there is a reason to change them.

Separate the offer from the presentation. If the service itself is difficult to explain, a new layout will not settle the message. Prepare a plain-language description of what you deliver, who it is for and what happens after someone contacts you. Use actual project evidence rather than adding impressive numbers that cannot be supported.

Prepare a page inventory. Record existing page addresses, their purpose, the content owner and whether each page will remain, change or be retired. Flag pages used in campaigns, emails and printed materials. This gives the team a concrete list of destinations to account for instead of discovering old links after launch.

Map the enquiry journey. Follow a submission from the form to the person who responds. Record required fields, notifications, CRM handling and failure messages. Decide how duplicate submissions and unsuccessful deliveries should behave. A polished form is only useful if the enquiry reaches the right place and the visitor receives an accurate status.

Review the mobile tasks. Ask someone to find a service, inspect a project and start an enquiry on a phone. Watch for text hidden under navigation, controls that are hard to tap and fields that are difficult to complete. Record the issue and expected behaviour so acceptance is based on tasks rather than screenshots alone.

Agree the handover. Identify who will edit content, renew domains, manage hosting and respond when something breaks. Include access, documentation and a rollback plan in the release checklist. Decide who approves the final content and which changes require another review before publication.

A useful brief contains the current URL, the main problem, important pages, integrations and the person responsible for updates. Explore website design and development or ask us to review your existing website. A targeted improvement may be enough; the brief should leave room for that answer.