A website redesign proposal can arrive before anyone has established why the current site is difficult to use. The visible problem might be a mobile menu covering the content, an unanswered service question or a structure that cannot support the business’s next requirement. Those findings call for different scopes of work
To decide between a website redesign or targeted fixes, connect the task that is failing with its cause, the parts affected and the work needed to verify a solution. The aim is a recommendation you can review before replacing useful pages, content or functionality
Main image: Conceptual illustration of a change to one part of a fictional website, not a client project or test result
Describe the task before choosing the project
Start with something a visitor or content editor needs to complete. “Find whether a programme suits our team and send a relevant enquiry” gives the review a purpose. “Make the website modern” leaves both the problem and the completion check open
Record what happens, where it happens and the conditions in which you can reproduce it. Include the page, language, device or browser, the intended action and the point where the route becomes unclear or stops. Keep the observation separate from a possible explanation: a menu covering a heading is visible evidence; an unsuitable theme is a diagnosis that still needs checking
GOV.UK’s user-research guidance recommends examining existing evidence and observing actual or likely users, while treating unsupported suggestions as assumptions. That principle is useful here: ask someone relevant to attempt the task, and record what they do and where they need help
If the concern is visits that produce few enquiries, use our enquiry-journey diagnostic to investigate that broader question. A redesign decision needs a more specific account of what the website itself prevents
Map how far the problem reaches, then check the cause
Look at comparable pages before deciding how much must change. A misplaced element might belong to one page, a shared template or a navigation component used throughout the site. A shared component can produce a widespread fault while still having a focused repair
Separate missing information from an implementation limit. If a service page does not explain suitability, ask whether the business can supply an accurate answer and whether the existing page can present it clearly. Replacing the site will not produce that answer on the business’s behalf
A structural question concerns how the site organises and maintains important tasks. The business may need clearer relationships between services, equivalent language versions or reusable content that the current setup cannot support reliably. Ask the implementation team to demonstrate that limit and the alternatives considered, rather than accepting “the system is old” as the whole explanation
Use page age, appearance and repeated complaints as prompts for investigation. None establishes the appropriate scope alone. Equally, do not assume that a small-looking visual problem will be simple to correct until its dependencies are understood
Use measurements to investigate, not to select a rebuild automatically
Match the evidence to the question. A slow page, an unclear service explanation and a message that fails to reach its recipient need different checks. A report can locate a symptom without proving its cause or showing that a new design is the remedy
Google’s PageSpeed Insights documentation distinguishes controlled lab diagnostics from real-user experience data. It also explains that a page or site may lack enough samples to show real-user data. Use the available evidence with its limits; a missing field report is not proof of good performance, and a single lab score does not determine whether to replace the site
For usability, follow the important routes on the actual page, including a phone and keyboard where relevant. Check that people can find the information, understand labels, correct errors and complete the intended action. Confirm contact delivery separately when that is part of the task
W3C’s Easy Checks provide an initial accessibility review but explicitly do not cover everything. An attractive mockup or a successful quick check therefore cannot establish complete accessibility. Agree the assessment needed for the project, rather than adding an unsupported compliance claim to the redesign proposal
Compare a targeted improvement with a wider redesign
Ask for the same outcome to be considered through both routes. What could be preserved, what would change, what depends on that change and how would the team show that the task works afterwards? Comparing two attractive homepage concepts does not answer those scope questions
A targeted improvement is worth testing when the cause is understood and the current foundation can support the agreed task. It might involve a shared menu correction, a clearer service section or a specific contact function. Check related pages so a local success does not hide a problem introduced elsewhere
A wider redesign becomes a stronger discussion when the necessary changes depend on a different information structure, shared layouts or a maintainable way to manage essential content. A rebuild changes the implementation behind the site; it is not automatically required whenever layouts change. The proposal should name which foundations need replacing and why
Compare the work around the implementation too: content preparation, language review, integrations, testing, permissions, ongoing upkeep and the business’s availability to approve changes. A smaller initial task can still leave recurring work behind, while a larger project can introduce transition work that needs a named owner
If the cause is uncertain, commission a bounded investigation or prototype first. Define the question, the material the team needs, the test and the decision that follows. This is a way to reduce uncertainty; it is not a promise that a small fix will always be sufficient
Work through a fictional training website
Imagine a company that provides training for business teams. A visitor needs to understand whether a programme fits the team’s needs, then discuss the requirement. This is an illustrative scenario, not an ADAMS client project, a real website test or a measured result
The same task can reveal different problems
Suppose the mobile menu covers the programme introduction. The first job is to reproduce that behaviour and inspect its source. If it comes from a shared navigation setting that can be corrected safely, the work may be a targeted repair followed by checks of the pages using that navigation
Now suppose visitors can reach the page, but the intended audience and information needed for an enquiry are unclear. The business needs to approve that content. If the existing layout can carry it, a content and page improvement may address the gap without replacing the whole site
A wider project needs a demonstrated constraint
A different finding would be that the company needs a maintainable programme structure and equivalent Arabic and English content, while the current implementation relies on disconnected page copies that cannot support the agreed updates reliably. If the technical review confirms that constraint and explains why a focused change is inadequate, a wider design and implementation project has a reason to be considered
Keep those findings separate. Correcting the menu does not settle the content question, and needing better content does not itself prove that the platform must change. The proposed scope follows the verified limitation and the business’s actual requirements
Protect what works while making the change
Before implementation, record the useful pages, language relationships, contact routes and connected systems that must continue working. Agree how the proposed work will be reviewed away from the public site where practical, who authorises release and what recovery arrangement is appropriate if a problem appears
Keep useful URLs when they still serve the same page. A visual redesign does not require new addresses. If URLs must change, Google’s site-move guidance calls for corresponding destinations, tested redirects and updated references. It also warns that search rankings may fluctuate during a move. These controls manage a transition; they do not guarantee unchanged visibility
Review the proposed change against the original task, then check affected routes after release. A backup or a recovery plan needs its own agreed process; neither means that every change can be reversed instantly without consequences. Include content, language and enquiry checks in the release responsibilities
For uncertain design improvements, record what will be observed afterwards and which other changes could influence it. For a confirmed functional fault, demonstrate that the fault is resolved. A before-and-after screenshot alone does not prove either a working journey or a business result
Approve a decision with a clear scope and completion check
Ask the recommendation to state the task, confirmed problem, evidence, proposed change, elements being retained and dependencies still open. Add the person responsible for each input and the check required before release. Where the cause remains uncertain, make that uncertainty visible in the agreed next step
If a wider project is justified, our website redesign brief helps turn the decision into content, functionality and launch requirements. Use it after agreeing why the project is needed, rather than allowing a long deliverables list to substitute for that decision
ADAMS can help review the current site and scope the appropriate website design and improvement work. Share the page and the task you need it to support, together with any observed failure, required language versions and operational limits, so the next proposal addresses a problem you can explain and verify