Leave with a diagnosis, a decision framework, and a better brief for a focused redesign conversation.
Treat this as a planning aid, not a universal formula. The right decision still depends on the business, its audience, its existing systems, and the responsibilities agreed for the project.
Work out the real problem before choosing a new look
A site can look dated and still have a deeper problem underneath: the wrong words, the wrong structure, or something technical. Start with what you have watched go wrong, not with a style you have seen elsewhere.
Collect examples: customer questions, support requests, sales objections, dropped enquiries, content maintenance pain, pages that regularly need manual explanation, and technical constraints. These are stronger redesign inputs than a moodboard alone.
- Visitors cannot quickly explain what the business offers, who it is for, or why it is credible.
- The navigation and page structure no longer match the services, products, locations, or audience the business has today.
- Important mobile journeys are difficult to complete, or the site has become fragile to update.
- The site no longer looks like a business people would trust with this size of decision.
- The site cannot support a necessary form, booking, lead handoff, analytics, content workflow, or integration without workarounds.
Decide whether to improve, restructure, or rebuild
Not every issue calls for a full rebuild. The right intervention depends on the gap between the existing system and the business you need the site to serve next.
Improve
Use focused improvements when the architecture is sound and the problem is concentrated: unclear calls to action, weak page copy, a poor mobile layout, missing metadata, or a limited visual refresh.
Restructure
Rework the pages and the menu when what you sell has changed, important pages are buried, the same thing is said in three places, or people cannot get from their question to an answer.
Rebuild
Consider a rebuild when technical constraints, duplicated templates, unsupported dependencies, performance problems, fragile publishing, or a completely changed business model make piecemeal changes less responsible.
Protect the parts that already carry value
A redesign should not discard useful equity because the surface is changing. Record what needs to remain reachable, measurable, or familiar before a new structure is agreed.
This inventory is not bureaucracy. It is how a launch team avoids breaking a useful path by accident. It also clarifies what must be migrated, replaced, redirected, or consciously retired.
- Existing URLs, pages with meaningful organic visibility, inbound links, campaign links, and resources people regularly share.
- Contact workflows, lead destinations, tracking conventions, business email addresses, booking tools, product data, and legal or policy content.
- Accurate copy, imagery, documents, and brand elements that still represent the business well.
- Account access and ownership for domains, hosting, CMS, analytics, tag management, email, and any connected service.
Shape the new site around the people using it
A strong redesign connects how the site looks to what it says and what people are meant to do next. It should make the business easier to understand, not just newer to look at.
- Name the different kinds of visitor, and the question each one arrives with.
- Give every important page one main action, and a reason to take it now.
- Decide what the first screen says, what backs it up, and what comes next—before anyone starts on the visual detail.
- Agree a set of reusable page parts, so pages added later still look like the same site.
- Agree how it behaves on a phone, how text and images resize, and how it works for someone who cannot use a mouse—rather than treating the desktop version as the only real design.
Brief the work and launch with intent
A redesign brief is strongest when it gives the studio a real business context, a decision to make, and the constraints that will influence implementation.
Include the current URL, the reason the site needs to change, audience priorities, pages and content that must remain, known technical limits, content readiness, integrations, access to relevant accounts, and what success would look like in practical terms. Be direct about timing, budget context, and internal reviewers.
Before launch, use a migration and QA plan—not just a visual sign-off. New URLs, redirects, forms, measurement, metadata, production access, and handoff all deserve a named owner.