Start with the business decision
Name the commercial problem the website must solve: explain a complex service, qualify better prospects, support local discovery, reduce repetitive questions, sell products or create a clearer enquiry path. A redesign without a decision problem becomes a visual exercise.
Choose one primary conversion and any secondary actions. Define a qualified enquiry in operational terms so the team can distinguish a stored lead from a button click, spam message or irrelevant request.
Describe the priority customer and buying situation
Identify who is making the decision, what triggered the search, what they need to know before contacting the business and what commonly stops them. Include the priority service, geography, urgency and any qualification boundaries.
Avoid a persona built from adjectives alone. Useful evidence includes real sales questions, call notes, rejected enquiries, proposal objections, Search Console queries and the pages prospects already visit before contacting you.
State the offer and scope boundaries
List the services or products the site must prioritise, the locations genuinely served, the customers that are a poor fit and any promises the business will not make. Record whether pricing, ranges, minimums or lead times can be published.
If several business lines compete for attention, rank them. A proposal cannot resolve an internal priority conflict that the brief leaves hidden.
Inventory pages before choosing a page count
Begin with customer decisions and required content, then map those needs to pages. Typical groups include home, priority services, regional coverage, proof, process, pricing factors, insights, about, contact and legal information.
For an existing site, export every current URL and label it keep, improve, merge, redirect or retire. Record inbound links, traffic and conversions before removing anything. A quoted page count without a migration inventory is not a safe redesign scope.
Collect proof and mark its permission status
Gather real projects, screenshots, original photographs, testimonials, reviews, process evidence, team biographies, qualifications and supplier relationships. For every item, record its owner, source, date, publication permission and any factual limitation.
Separate available evidence from planned evidence. A case study waiting for client approval should not be treated as launch-ready, and an unverified outcome should not become a public performance claim.
Define functions and system boundaries
List forms, payments, bookings, ecommerce, search, customer accounts, CRM, email, accounting, analytics, maps, consent and any private workspace requirements. For each integration, identify the provider, account owner, data direction, failure behaviour and ongoing fee.
State what must happen after a submission or payment: validation, storage, notification, confirmation, retry and reconciliation. A screen that says success is not enough if the underlying record can be lost.
Protect search visibility during migration
Record the preferred domain, canonical host, current sitemap, valuable URLs, redirect requirements and existing Search Console access. Preserve strong URLs where their purpose remains; otherwise map each one to the closest useful replacement rather than redirecting everything to the home page.
Require unique metadata, one clear page purpose, useful headings, self-canonicals, crawlable internal links and structured data that matches visible content. Include a pre-launch crawl and post-launch redirect check in acceptance.
Specify measurement and privacy before launch
Name the analytics property, consent model, lead definition and events required. Track form starts, key calls to action and email clicks as interactions, but count a lead only when a genuine enquiry is stored successfully.
List fields that must never reach behavioural analytics or session recordings. Identify who can access raw enquiries, how long they are retained and how consent withdrawal changes tracking. Measurement added after launch loses the baseline.
Make content ownership explicit
Assign an owner for supplied copy, photographs, legal text, product data and factual approval. Set review rounds, response times and the rule for late or missing content. Decide whether the site can launch with approved sections while other material remains draft.
Record voice, spelling, prohibited claims, citation requirements and the factual reviewer. The design team should know which statements are verified, which need evidence and which must not be published.
Set accessibility and device acceptance
Name required browsers, devices, viewport priorities, keyboard behaviour, contrast expectations, motion preferences, form errors and text-resize needs. Include representative real pages rather than accepting only an idealised home-page mock-up.
Acceptance should cover navigation, enquiry, payment or booking paths, focus visibility, labels, responsive reading order and failure states. Automated checks help, but they do not replace keyboard and screen-size verification.
Clarify ownership, hosting and handover
Record who owns the domain, hosting account, source code, design files, content, analytics, profiles and third-party licences. Identify recurring costs, renewal dates, cancellation terms, backup responsibility and what happens if the supplier relationship ends.
Require administrator access, deployment and rollback notes, credential handover through a secure channel, dependency inventory and enough documentation for another competent team to operate the site. Avoid a launch that leaves the business dependent on one hidden account.
Give suppliers one comparable response format
Ask each proposal to separate discovery, design, content, development, migration, integrations, testing, launch, training and support. Require assumptions, exclusions, client responsibilities, milestones, acceptance criteria, change-control rules and recurring costs.
Compare ownership, risk and evidence—not only the total. A lower price may exclude content, migration, analytics or support; a higher price is useful only when the additional scope is explicit and commercially relevant.
Finish with launch and 30-day acceptance
Define the live checks: correct domain and HTTPS, priority routes, redirects, forms, stored enquiries, notifications, consent, analytics, sitemap, robots, canonical tags, structured data, speed, responsive behaviour and rollback readiness.
Agree who monitors errors and enquiries during the first week, who reviews Search Console and analytics after enough data arrives and what defects are included in the launch warranty. The brief is complete when both delivery and proof of delivery are defined.