Agree on the job before asking for a price

A useful website redesign brief explains what must improve, what must survive the change, and how you will decide the work is ready to launch. Give every supplier the same brief and ask them to separate included work, optional work and unresolved assumptions. That makes the proposals easier to compare than a request for “a modern website”.

You do not need to design the website before hiring someone. You do need to describe the business problem, the content and systems involved, and who can make decisions. Unknowns belong in the brief too: they can become a discovery task rather than an unspoken promise in a fixed price.

Here is the structure I would use for an existing business website. A new brand starting from scratch can omit the migration work, but should still agree on the customer journey and handover.

Separate a visual refresh from a larger change

Write down why you want to change the site now. Is the offer difficult to understand? Does the mobile enquiry process fail? Can staff no longer update the content? Has the business moved into another market? Each reason suggests different work.

A visual refresh can retain the existing content structure and working integrations. A restructuring changes which pages exist and how people find them. A platform change can also affect editing, forms, hosting and connections to other tools. These changes can be combined, but they should be priced and tested explicitly.

Do not assume a complete rebuild is the answer to a local problem. If one campaign page is confusing and the rest of the site works, ask whether improving that journey is a sensible first phase. Conversely, a fresh homepage will not fix an enquiry that never reaches the person responsible for it.

Define the visitor's task and the business handover

Choose a priority visitor and describe the action they need to complete. “A prospective customer can understand the service, check whether it fits and request a relevant quote” gives the designer more to work with than “increase engagement”.

Then describe what the business receives. Where does the request go? Who owns the response? Is a calendar, order system or CRM involved? Link to the current journey and explain the point where it becomes difficult. Keep the detailed choice of form fields in a separate task; my enquiry-form guide can help with that.

The products in my portfolio show why this matters. SpainProperty connects location guides and property discovery with a consultation. Sport Bisztró & Pizzéria connects a menu with pickup and delivery ordering. Those require different content, interactions and acceptance tests. They are examples of scope, not evidence of a promised increase in enquiries or orders.

Inventory the pages before counting the new ones

Make a working list of existing pages, articles, downloads and campaign destinations. For each, record its purpose, language, whether it stays or changes, and who approves its content. Where available, use actual search, traffic and enquiry evidence to prioritise the review. Mark missing evidence as unknown.

Page count alone is a poor description of effort. Several service pages can share a layout, while one booking page can require substantial integration work. Ask suppliers to distinguish reusable page types, content population and interactive features.

For every language, name who writes, translates and reviews the copy. Also agree who supplies photographs, checks permission to use them, and handles any missing material. “Content supplied by the client” needs an owner and a delivery date. Include time for the person who will later edit the site to try that task before handover.

Put existing URLs in the launch scope

If page addresses change, require a list matching old URLs to their destinations. Google's site-move guidance calls for URL mapping and updates to internal links, canonical references and language annotations. It also warns that rankings can fluctuate while a changed site is processed. A migration plan cannot guarantee unchanged traffic.

Ask for permanent server-side redirects where content has moved, following Google's redirect guidance. Avoid treating the homepage as the destination for everything that disappears; the replacement should make sense for someone following the original link.

Make the handover concrete: who prepares the URL list, who approves removals, who tests the redirects, and who checks indexing after launch? Include links used in active ads and emails in your own review. A redesign is not complete if an important customer entry point has been forgotten.

Replace vague quality promises with launch checks

Agree on tests before reviewing the finished design. For a service website, I would include a visitor finding the right service on a phone, submitting a test enquiry, receiving a clear confirmation, and the responsible colleague finding the request in the agreed destination. Test the failure path as well as the successful submission.

Accessibility checks should include keyboard operation, visible focus, usable text enlargement and clear form labels and errors. W3C's Easy Checks is a useful starting point, and explicitly is not a complete accessibility evaluation. If you need a full assessment against a named standard, make that a separate, defined deliverable.

For performance, specify the page types and test conditions. Google's Web Vitals guidance distinguishes loading, responsiveness and layout stability, and separates development tests from real-user measurement. A good lab result does not establish that every visitor has the same experience. Agree on pre-launch checks and a later review of field data when available, rather than asking for one impressive score.

For a bilingual site, check the whole journey in both languages: navigation, service information, validation messages, confirmation and the page reached after switching language. Testing only the translated homepage leaves much of the job untested.

Compare ownership, exclusions and ongoing costs

Ask each supplier to show which parts they will deliver and which depend on you or another provider. Separate design and development from copywriting, photography, translation, paid services, migration and ongoing support. An item described as optional should not also be essential to the proposed launch without an explanation.

Agree who controls the domain, hosting, website source or platform account, analytics and connected services. Use appropriate account invitations when access is needed; a brief should identify account owners, not contain passwords. Clarify how another developer could take over and what documentation and training are included.

Name the launch decision-maker and the person responsible for post-launch problems. Ask how defects are handled, how additional requests are estimated and what recurring costs remain. A deadline should include its reason and dependencies: a campaign launch is different from a preferred date with unfinished copy.

A short brief you can copy

Use these prompts as headings in a document. Short, specific answers are enough for an initial conversation; attach supporting lists where useful.

  • Current website and reason for the redesign: what is difficult today, and what should remain?
  • Priority audience and task: what should the visitor understand and complete?
  • Business handover: where does the enquiry, booking or order go, and who handles it?
  • Scope: which page types, languages and integrations must launch, and what can wait?
  • Existing material: which URLs and content need review, and what evidence is available?
  • Content responsibilities: who supplies, writes, translates and approves each part, and when?
  • Visual direction: which references help, and exactly what do you like about them?
  • Acceptance: what visitor, staff, mobile, accessibility and performance checks are required?
  • Commercial boundaries: what budget is available, what is excluded, and which costs recur?
  • Launch and handover: who approves, who operates the site, and what support is needed?

Ask suppliers to return the brief with their assumptions and open questions. If a difficult integration is still uncertain, request a bounded investigation before committing to the full build. That is more useful than pretending the uncertainty has disappeared because a proposal has a total price.

If you are preparing a redesign, send me the current URL and the main problem through the contact page. Your message reaches hello@davidbuka.com. I can help turn that into a clear scope for website design and development, including the parts that connect to marketing and daily operations.

Sources checked on 16 October 2026. The cover is an original editorial illustration, not a photograph of a client brief.