The short version
The key ideas.
- Distinguish positioning, content, usability, and technical problems before choosing the scope.
- Preserve working assets and establish a baseline that survives the redesign.
- Use the smallest credible intervention to test your diagnosis before expanding the project.
Separate the symptom from the explanation
“The website feels dated” may describe a real issue. It does not explain what the business needs to change. A dated appearance could weaken confidence in a design-led company. It could also be an internal frustration with a site that still helps customers effectively. Treat the statement as a starting point for investigation, not as a completed business case.
Translate each complaint into a specific moment. Prospects cannot tell which service fits them. Recruiters keep sending a separate culture deck. Editors avoid publishing because the layout breaks. Visitors on phones cannot complete the enquiry form. These statements identify people, tasks, and observable friction.
Keep the symptom and your suspected explanation in separate columns. “Few enquiries” is a symptom; “the design is unconvincing” is one hypothesis. Other explanations include poorly matched traffic, an unclear offer, missing proof, a broken form, or a long purchasing cycle. A redesign becomes more useful when it addresses the causes you have evidence for. Otherwise, a new visual language can inherit the same commercial ambiguity.
Build an evidence file from the actual journey
Start with what already exists: enquiry records, sales questions, search terms, page analytics, support requests, and the publishing team’s workarounds. Add conversations with recent buyers and people who considered the business but chose another route. Ask them to recall what they needed to understand, where they hesitated, and what helped them move forward.
The GOV.UK guidance on user needs recommends combining existing evidence with interviews and observation, and treating untested internal opinions as assumptions. The context is public services, but this research discipline is useful when diagnosing a commercial website.
Review complete journeys instead of isolated screenshots. Follow a visitor from a relevant search or referral into a service page, then through proof and contact. Repeat the journey on a phone and with keyboard navigation. Check that the enquiry reaches the right person. Annotate where evidence is strong, where it is incomplete, and where stakeholders disagree. You do not need perfect certainty to proceed; you need a clear account of what you know and what remains a hypothesis.
Classify the work before estimating it
Most redesign conversations contain several different projects. Give each problem a home so the eventual scope matches its cause.
- Positioning: the company’s audience, offer, or reason to choose it is unclear. Resolve the strategic decisions before polishing the interface.
- Content: the right story exists but is incomplete, scattered, or hard to understand. Editorial work and information architecture may carry most of the value.
- Experience: people cannot navigate, compare, read, or act comfortably. Specific interaction and layout changes may solve the issue.
- Infrastructure: the publishing model, integration, or implementation prevents necessary work. Investigate the technical constraint before selecting a replacement.
Hypothetical example: a consultancy has expanded from one service into three, yet its navigation still reflects its original practice. A homepage reskin would leave buyers doing the same interpretive work. The likely intervention is a clearer service structure, rewritten supporting pages, and evidence for each offer. A new design system may support that change, but it follows the business diagnosis.
Some problems span categories. That is a reason to coordinate the work, not to collapse every problem into a vague request for modernization.
Choose between repair, refresh, and rebuild
A repair changes a limited part of the experience: a form, a page introduction, a navigation label, or an image treatment. A refresh updates the visual and editorial expression while retaining the underlying structure. A rebuild changes enough of the system that migration, publishing, and long-term maintenance become major considerations.
Use two questions to select the scale. How widely is the problem distributed? How deeply is it embedded? A confusing contact label is narrow and shallow. An unsuitable content model repeated across hundreds of pages is broad and deep. A visible problem is not necessarily a deep one, and an invisible publishing problem can be structurally significant.
When uncertainty is high, make a targeted improvement that tests the diagnosis. Rewrite one important service page and observe whether prospects understand the offer more accurately. Simplify a form and verify completion. Prototype a new editorial workflow with the content team. Treat these as learning exercises rather than promises of immediate revenue. A smaller intervention can strengthen the case for a larger project—or reveal that a larger project is unnecessary.
Decide what the redesign must preserve
A redesign should carry valuable knowledge forward. Catalogue pages that attract relevant visitors, explanations the sales team relies on, photographs with distinctive character, and content relationships that editors use. “Start from scratch” is a poor default when the existing site contains evidence of what works.
If URLs will change, plan the move as part of the project. Google’s site migration guidance covers mapping old URLs to new destinations, implementing redirects, and monitoring the transition. It also notes that search visibility can fluctuate during a significant move. A redesign proposal should allow time for this work rather than treating it as a final administrative detail.
Preservation also applies to measurement. Record the definitions of important events and the baseline period before making changes. If a “qualified enquiry” means something different after launch, the comparison will be misleading. Note concurrent changes in campaigns, offers, seasonality, or sales practice. A new site exists inside a changing business, so interpret outcomes with the surrounding conditions in view.
Separate what to keep, repair and rebuild
Create three lists before the creative brief. Keep includes useful content, familiar routes, working integrations and evidence that still reflects the business. Repair includes identifiable failures such as an unclear inquiry label, an out-of-date offer or unreadable mobile text. Rebuild includes structural constraints that cannot be resolved sensibly within the existing system.
For each item, record the consequence and the evidence. “The services page looks dated” is a starting opinion. “Prospects cannot tell which service includes ongoing support” is a question you can test. If the page’s structure already supports the answer, revising the content may be sufficient. If different audiences need conflicting journeys throughout the site, a broader rethink may be justified.
Use the lists to compare proposals. A credible recommendation should explain why each large change is necessary and how useful existing material will survive it. Pair this decision sheet with a written brief and a launch checklist. That keeps migration and continuity inside the project instead of treating them as cleanup after design.
Write a one-page redesign charter
Before briefing an agency, create a short charter that can guide decisions when enthusiasm and preferences begin to compete. Include the primary audience, the most important problem, the evidence behind it, the intended behaviour, and the proposed scope. Name the decision owner and the people whose input is essential.
Use this exercise: complete “Today, this visitor struggles to ___ because ___. We believe changing ___ will help them ___. We will assess that by ___.” Keep the sentence concrete. “Improve engagement” is less useful than “help a prospective client find a relevant project and understand our role in it.”
- List the three things that must improve.
- List the three things that must remain dependable.
- Identify one assumption to test before full production.
- Define the evidence that would justify reducing or expanding scope.
- Set a review after launch with a named owner.
The charter is not a prediction. It is a shared explanation of why the work exists. A successful redesign begins with that clarity and keeps returning to it, so each new page, interaction, and visual decision has a reason beyond looking different.
Sources & further reading
From perspective to practice
Start with a better diagnosis
Share what is no longer working and what has changed in the business. We can help separate focused improvements from a larger rebuild.
Discuss your redesign Explore services & pricing