Before you approve a new website design, agree what the website needs to help people do, what content you can provide and who can make decisions. Those answers give a designer something useful to work with and give your business a fair basis for reviewing the result
A website redesign brief does not need polished marketing language. It needs clear decisions, honest gaps and named responsibilities. You can begin with incomplete information, provided the brief makes those uncertainties visible instead of leaving the project team to guess
Start with the customer action, then explain the problem
Choose the main action the website should support. A service business might need visitors to request a relevant quotation, while a product supplier might need buyers to find specifications and contact the right person. “Make the website more modern” describes an appearance; it does not explain what the new experience must make easier
Describe the people taking that action and the questions they need answered first. A buyer comparing suppliers may need delivery coverage, product suitability and a clear contact route. A marketing manager researching an agency may need to understand the service, the working process and the information required to start
Then record the existing problem with whatever evidence is available. That could be recurring questions from enquiries, a confusing navigation path, outdated service information or a form that fails to reach its recipient. Separate observations from assumptions. If people say they cannot find a service, include that feedback; do not turn it into an unsupported claim about every visitor
If your main concern is traffic that produces few enquiries, first check where the enquiry journey breaks down. The right project may be a focused improvement rather than a complete rebuild
Turn the goal into an agreed scope
Connect the business goal, the visitor’s task and the available content before choosing layouts. Record what belongs in the initial launch and what can follow later. A useful brief might distinguish the essential service and contact pages from a future recruitment area, rather than treating every possible feature as equally urgent
Make an inventory of pages before changing the structure
List the current pages and their URLs, including useful pages that are not in the main menu. Add each page’s purpose, content owner and proposed action. Search Console, analytics and enquiry feedback can help inform decisions where access is available, but avoid treating an absence of data as proof that a page has no value
Use practical content actions: keep useful content, rewrite inaccurate or unclear material, merge overlapping pages where their purpose fits, and retire material the business no longer needs. Give each decision a reason. A quieter page may still answer an important support question or receive links from elsewhere
A redesign does not automatically require new URLs. Keep a working address when it still suits the page. If an address must change, record the relevant destination before launch so the implementation team can prepare and test the permanent redirect
Google’s guidance on URL changes recommends mapping old URLs to their corresponding new destinations. Where content is removed without a relevant replacement, return an appropriate 404 or 410 response. Do not redirect unrelated retired pages to the homepage. A migration can involve ranking fluctuations, so a redirect plan is a control to manage the change, not a promise that search visibility will remain unchanged
Assign content and asset owners before design approval
For every planned page, name the person who can supply accurate information and the person who can approve it. They may be the same person, but the responsibility should be explicit. A designer can organise a service explanation; the business still needs to confirm what that service actually includes
Gather current brand files, suitable digital images, service descriptions, contact details and any product information required for the agreed scope. Confirm permission to use the material. Mark missing assets and agree how they will be produced, sourced or replaced rather than leaving placeholders to become an accidental launch decision
For a bilingual website, identify the owner of each language and agree how corresponding pages will be reviewed. Translation, layout direction and ongoing updates need consideration together. If a service changes later, someone needs responsibility for keeping both versions accurate
Also agree how feedback will be collected. A single consolidated response from the business is easier to act on than conflicting comments from different people. The brief should identify who resolves disagreements and who can sign off the content
Describe functions as tasks people must complete
“We need a contact form” leaves several decisions open. Explain who uses it, which information is necessary, where the message should arrive and what happens when submission fails. Specify whether an enquiry is routed to one recipient or different teams, and identify who will respond
Apply the same approach to bookings, search, account areas or product filters. Describe the user task, the information involved and any system the feature must connect to. Flag uncertain integrations for investigation before they become assumed deliverables
Include mobile behaviour in the brief: how navigation opens, how contact controls work, how longer passages are presented and how forms remain usable on smaller screens. Agree the devices and browsers to be checked, without treating one screenshot as evidence of every possible experience
Accessibility should also enter the project early. W3C’s accessibility planning guidance recommends defining goals, assigning responsibilities and including acceptance testing. Agree the intended standard and review scope with the project team. Keyboard use, clear labels, readable contrast and understandable errors belong in the discussion; a visual redesign alone does not establish accessibility conformance
Define what must pass before launch
Write the acceptance checks while the project is being scoped. They should connect to the work you have agreed, so everyone knows what evidence is needed before the site goes live
- Business review: approved service information, accurate contact details, correct language versions and permitted assets
- Build review: usable navigation, readable layouts, working links and the agreed mobile and accessibility checks
- Enquiry review: successful and unsuccessful form behaviour, plus confirmation that a test message actually reaches its intended recipient
- Search review: intended public pages are accessible, URL decisions are implemented and staging restrictions are not accidentally carried into launch
- Handover review: the business has appropriate access, knows how to request or make updates and understands ongoing responsibilities
Keep measurement precise. A contact-button click, a received enquiry and a confirmed customer are different events. If reporting is part of the agreed work, define what will be measured and who checks that collection works. Do not assume that a working button proves a received message or a sale
Use this brief to start the conversation
Copy the prompts below into your project notes and answer them in plain language. Mark unknowns for discussion; an honest gap is more useful than an invented requirement
- Business reason: what needs to change, and what evidence supports that decision?
- Audience and action: who is the website for, and what should they be able to do?
- Initial scope: which pages, languages and functions are essential for launch?
- Existing content: what will we keep, rewrite, merge or retire, and what happens to each URL?
- Inputs: which copy and assets are ready, what is missing, and who owns each item?
- Approvals: who consolidates feedback and signs off content and design?
- Acceptance: which checks must pass, who performs them and who authorises launch?
- After launch: who owns access, updates, enquiry handling and ongoing review?
Once these decisions are visible, you can discuss a website design project with ADAMS around the work your business actually needs. Start with the brief, resolve the gaps and agree the scope before approving the visual direction