Start with the decision your customer needs to make

“We need a more modern website” is an understandable starting point, but it leaves the important question unanswered: what should the new website help a customer do?

For a service business, that might mean understanding which offer is right, checking whether you cover their area and sending enough information for a useful first reply. Write those decisions down before collecting design references. A beautiful page cannot compensate for an offer that takes a phone call to explain.

Include who the service suits, who it does not suit and what a good enquiry looks like. If your team can only take a limited number of projects, that matters more than a broad target to increase traffic.

Separate a refresh from a rebuild

A dated visual style does not automatically mean the whole site needs replacing. Ask the agency to distinguish content problems, navigation problems and technical constraints. A useful page might need clearer wording and a better enquiry route. A platform that blocks essential changes may need a different foundation.

Give the agency your current address, a list of things customers struggle with and the features your team actually uses. Mention anything connected to the site: forms, bookings, payments, CRM records or email notifications. “Keep the form working” is a requirement worth making explicit.

Our website design and development service starts with those questions so the scope can match the problem.

Make a small inventory before changing the pages

List the important pages, what each one does and whether it needs to stay, change or be retired. Include pages that attract useful search visits, appear in proposals or are linked from ads. The homepage is rarely the whole website.

Where a useful URL can stay the same, say so. Where it must change, ask for a mapping to the relevant replacement and a check after launch. Google provides guidance for site moves with URL changes; a redesign should treat that work as part of the project rather than a detail left until the end.

Also identify the source of truth for facts: service descriptions, business details, project examples and approved testimonials. It is better to publish a clear explanation without a case study than to imply evidence you do not have.

Agree how remote feedback will work

Remote delivery works better when feedback has a shape. Name one person who can collect comments and make decisions. Agree when the team will review the page structure, the writing, the visual direction and the working build.

Send feedback against the goal. “This page needs to explain the difference between the two services” gives a designer something to solve. “Make it pop” leaves the business decision hidden.

If the team spans time zones, agree the review window and which discussions need a meeting. Written decisions, annotated screenshots and a short recording can keep a project moving without requiring everyone to be online at once. Meeting arrangements should be practical commitments, not assumptions based on a country label.

Choose a useful first conversion

A redesign brief should describe what happens after someone clicks the main call to action. What information does the form need? Who receives it? What should the customer see after submitting? What happens if sending fails?

A confirmation screen is only useful if the enquiry was actually accepted. Ask the team to test the full path from a phone to the monitored inbox or system. Keep the fields relevant; collecting a long company profile before a first conversation can make an enquiry harder than it needs to be.

For a business serving several countries, let people select their market and explain how remote delivery works. Our country websites cover India, New Zealand, Australia and the United States, with online collaboration available across the globe.

Put ownership and separate costs in writing

Ask who controls the domain, hosting, source files, analytics and third-party accounts. Agree what access the agency needs and what documentation will be handed over. A list of deliverables is more useful when the responsibilities are clear too.

The proposal should identify costs outside the build: software subscriptions, advertising, commissioned photography, paid fonts or ongoing maintenance where relevant. If you work across borders, confirm billing currency and payment terms before starting.

Changes are normal. Agree how new pages, extra features and additional review rounds are assessed so a good idea does not quietly turn into a disputed scope.

Review the working site before calling it finished

Read the key pages on a smaller phone. Try the menu with a keyboard. Send a controlled test enquiry and check the response. Look at important old URLs, new page titles, search indexing settings and the links from your campaigns.

Performance needs attention beyond the size of a hero image. Ask how quickly the main content appears, whether the page shifts while loading and whether controls respond when used. Google’s Core Web Vitals describe useful measures of loading, responsiveness and visual stability; field results still need real visits over time.

Finish with a launch checklist, a rollback plan and an agreed owner for future updates. Then review what the site is helping customers do, rather than judging the project only by the day it goes live.

Have an existing site and a problem you can describe? Send us your starting point. A clear brief can begin with a few honest sentences.

Further reading

Google: Site moves with URL changes ↗web.dev: Core Web Vitals ↗
Useful to someone you know?