Give the website a clear business job

A great website helps a visitor make a decision and take a useful next step. Start by writing down who you serve, what you offer, and what people should do after visiting. A repair business might want visitors to check its service area and request a call. A wholesaler might need buyers to compare products and ask for a quotation. Those goals call for different pages and features.

Pick one main action, then list the questions customers ask before taking it. Use those questions to shape the first version. Success might mean receiving enquiries with enough detail to respond, or reducing calls about opening hours. Decide how you will review those outcomes without assuming that traffic alone means business growth.

Choose a designer by looking beyond the cover image

Review live portfolio websites, including on your phone. Can you find the service, understand the offer, and reach the contact details? Check whether the designer explains what they contributed: design, development, copy, or maintenance. An attractive screenshot does not show how a menu or form behaves. Ask for relevant examples and a clear explanation of the work.

Discuss how drafts are reviewed, who supplies content, what revisions cover, and how changes outside the agreed scope are handled. Ask who will build and support the site. A useful proposal names the deliverables and responsibilities rather than relying on vague promises such as “fully optimized.” Compare proposals against the same brief so you are comparing similar work.

Make navigation and mobile use straightforward

Use page names customers recognize, such as Services, About, and Contact. Group information around visitor tasks, and give links descriptive labels. A catering site could separate event catering from everyday delivery so people can quickly find the right enquiry route. Keep important details available in page content as well as menus.

On a narrow screen, check that text is readable without pinching, buttons are comfortable to tap, and forms are usable with the keyboard open. Test a longer service name and a real-length message, not just a tidy mockup. The web.dev responsive design guidance explains how layouts can adapt to different screens. Ask the designer to demonstrate your key customer journey on both phone and desktop.

Include speed and accessibility in acceptance checks

Large photos, unnecessary scripts, and heavy effects can make a simple task feel slow. Ask for appropriately sized images and a performance check on important pages. Web Vitals looks at loading, responsiveness, and layout stability. A test report is useful evidence, but a single score is not a guarantee of how every customer’s device or connection will perform.

Accessibility belongs in the plan from the start. Ask for readable contrast, visible keyboard focus, properly labelled form fields, sensible headings, and alternatives for meaningful images. Try using Tab to reach the menu and enquiry controls, and check that errors explain how to correct an entry. The W3C accessibility design tips provide concrete points to discuss. Automated checks help, but they do not replace manual review.

Write useful content and test the enquiry path

Explain what you do, who it is for, where you work, and what a customer needs to provide. Use accurate photographs and specific service descriptions. A cleaning service might explain the difference between a routine visit and a move-out clean, then tell customers which details to include when asking for a quote. Publish testimonials or results only when you have permission and evidence.

Keep enquiries focused. Ask for the information needed to respond, explain the next step, and provide a practical alternative such as a phone number. Test an actual message from start to finish and confirm that it arrives at the intended destination. A form that prepares text for copying is different from a form that submits it; the page should say which it does. Check that booking language reflects whether an appointment is actually confirmed.

Evaluate the proposal with this checklist

Before agreeing, request written answers to these questions. A missing answer is something to resolve in the scope, not something to assume will be included.

  • Purpose: Which customer tasks and business goals will the first version support?
  • Deliverables: Which pages, features, content work, and review rounds are included?
  • Portfolio: Can I inspect relevant live work and understand the designer’s contribution?
  • Usability: How will navigation, mobile layouts, keyboard access, and form errors be checked?
  • Performance: Which pages will be tested, and how will large images and scripts be managed?
  • Enquiries: Where do messages go, who receives them, and how will delivery be verified?
  • Costs: What is the build cost, what renews, and what counts as additional work?
  • Handover: Who owns the domain and accounts, and what files, licences, access, and training will I receive?
  • Support: Who handles updates, backups, faults, and ongoing content changes?
  • Approval: What evidence must be reviewed before launch, and who signs off?

Own the accounts and agree the handover

Register the domain and key service accounts under the business’s control. Invite your designer with appropriate access rather than making their personal account the only route to your website. Agree who owns the custom work, what third-party assets are licensed, and what can be transferred if you change providers.

Request a handover covering account access, renewal dates, site files or exports where applicable, editing instructions, and support arrangements. Keep recovery details secure. Before launch, review real content, phone links, mobile menus, and a delivered test enquiry. A website becomes easier to run when its purpose, acceptance checks, and responsibilities are clear from the beginning.