Check the customer journey, mobile experience, content ownership, and enquiry handling before you announce a new website.
The short version
Build around customer tasks, not a page count.
Test enquiries from a phone through to the backend.
Agree who owns updates, access, and recovery.
Define what the website must do
Start by naming the tasks visitors need to complete. A customer may need to understand a service, see an example, check a location, or send an enquiry. Prioritise those tasks in navigation and page structure. A visually polished homepage is useful only when the next step is obvious. Agree which content is essential for launch and which material can be added later.
Write the content before polishing layouts
A website is ready when the customer can complete the task, not when the last animation is finished.
Check | What to verify | Review owner |
|---|---|---|
Content | Services, office details, and next steps | Content owner |
Enquiries | Validation, storage, and response ownership | Developer and enquiry owner |
Accessibility | Headings, labels, focus, and contrast | Design and development |
Handover | Accounts, backups, and updates | Business owner |
Prepare service descriptions, contact information, image permissions, and calls to action early. Replace broad claims with concrete deliverables. For an organisation working in Kenya and Malawi, make the appropriate office and contact routes clear. Do not imply that a photograph is a real office or employee unless that is accurate. Keep a named owner responsible for updating each important page.
Design for the phone in the customer’s hand
Check navigation, forms, image crops, and text size on narrow screens. Compress photographs and avoid loading a large video merely for decoration. A page should remain understandable while images are loading. Use descriptive headings and visible keyboard focus. Test labels, error messages, and contrast rather than assuming a template makes every page accessible.
Test enquiries all the way through
Submit a clearly identified test enquiry and confirm that the record reaches the intended backend. Check that the team can read it and follow up. Verify required fields, invalid email handling, and recovery after a server error. Keep newsletter permission separate from the permission needed to answer an enquiry. Never place real customer information in screenshots or development fixtures.
Agree ownership and maintenance
Document who controls the domain, hosting account, repository, and content management system. Give staff access appropriate to their responsibilities and avoid shared administrator passwords. Agree how backups are created and how restoration is checked. Record the process for security updates, expiring certificates, and urgent content corrections. A launch handover should explain how the website will be operated, not just where it is hosted.
Launch with a short review cycle
Check redirects, page titles, missing pages, social previews, and contact links before announcing the site. After launch, review real visitor questions and failed enquiries. Keep a short list of improvements ordered by customer impact. This checklist is a practical starting point; the appropriate technical controls and hosting arrangement depend on the organisation and the information it processes.
Before you start
Agree the audience, deliverables, and owner.
Check examples against your own team’s context.
Review the work with the people who will use it.
Further reading and practical references
W3C’s page structure tutorial explains how headings and page regions support navigation. Use it to review the structure of service pages, rather than judging headings only by their visual size.
Put the plan into practice
Name the audience, deliverables, and owner.
Review the examples with the people doing the work.
Choose one improvement and agree when to evaluate it.
Have a brief you want to develop? Talk to Brookside about your project.
Written for practical planning. Adapt the examples to your organisation and review platform guidance before implementation.
