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.
Diagnose the problem before choosing the visual direction
A site can look dated and still have a content, positioning, technical, or conversion problem underneath. Start with observed friction, not a style trend.
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 visual system no longer supports the level of trust the business needs for its current market.
- 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 information architecture when the offer has changed, priority pages are buried, content duplicates itself, or visitors need a clearer route from question to action.
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 system around audience and decisions
A strong redesign links the visual direction to the content hierarchy, interaction behavior, and conversion path. The design should make the business easier to understand—not simply look different.
- Name the audience groups and the questions each one brings to the site.
- Set a primary action for each major page, with a clear reason to take it now.
- Plan the first-screen message, supporting proof, page sequence, and next-step language before detailed visual work begins.
- Define a reusable visual and component system so new pages do not dilute the redesign immediately after launch.
- Agree how responsive layouts, typography, images, motion, and accessibility will behave rather than treating desktop 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.