Website Redesign Planning: What to Decide Before Design Starts

What should trigger a website redesign, if not simply an outdated look? A specific business change the current site is failing to support: more qualified enquiries, easier ecommerce discovery, better self-service for existing customers, stronger credibility with a new audience, or more efficient content operations for a growing team. Start by naming that change explicitly.

Translate the chosen goal into observable outcomes before any design work begins. "Improve credibility" is difficult to assess after launch; "reduce the proportion of enquiries that ask a question already answered elsewhere on comparable sites" is something that can actually be measured against real behaviour before and after the redesign.

Identify the two or three journeys that matter most to this goal and prioritise the redesign around them, rather than treating every page as equally important. A redesign aimed at ecommerce discovery should invest disproportionately in category and product page work, even if other pages receive comparatively less attention in this cycle.

Involve the people who will operate the finished site, not only those commissioning it, since their understanding of recurring customer confusion or administrative friction is often more accurate than assumptions made at the planning stage by people removed from daily operations.

Write the business change and its observable outcomes into a short brief that both the internal team and any external partner agree to, so design decisions later in the project can be tested against this original intent rather than evolving to match personal taste.

Should a redesign start from a blank page? Rarely a good idea, because the existing site usually contains valuable signals about what works, what does not, and what search engines and customers already rely on. Review analytics, search visibility, current content performance, recurring customer questions, accessibility gaps and any real technical constraints before deciding what to replace.

Identify pages and content that already perform well, whether through traffic, conversion or search ranking, and understand specifically why, so the redesign preserves or improves on these strengths rather than inadvertently discarding something effective in pursuit of a fresh look.

Catalogue every URL that currently receives meaningful traffic or search visibility, and plan appropriate redirects for anything being restructured or removed. Losing accumulated search visibility through careless URL changes is one of the most common and most avoidable costs of a redesign.

Use the audit to separate genuine weaknesses worth fixing from habits simply inherited from the previous design without ever being questioned. Not every element of the current site is wrong; some may simply need refreshed presentation rather than wholesale replacement.

Share audit findings with whoever is designing or building the new site before visual concepts begin, so design decisions respond to evidence about real user behaviour and search performance rather than being made independently and reconciled with the audit only afterward.

Why does content need to exist before visual design starts? Because real content exposes structural and hierarchy problems that placeholder text conveniently hides. Create the sitemap from genuine user needs and business priorities, then draft actual key messages and page content before detailed visual design begins, rather than designing elegant layouts for text that does not yet exist.

A sitemap built around how customers think about their problem, rather than around the business's internal department structure, usually performs better, since visitors rarely care which internal team owns which page and simply want their question answered in a logical place.

Draft headlines and key points for each major page early, even roughly, and test whether the sitemap can actually accommodate them without forcing awkward compromises. If a page needs to communicate three distinct messages that do not fit comfortably together, that is a sign the sitemap, not the design, needs adjustment.

Avoid letting visual design decisions, such as a particular layout template or component library, dictate what content can be included. The content priorities identified in the business-change stage should shape the design, not the other way around, since a visually elegant template that cannot accommodate necessary information will eventually be worked around badly.

Review the draft sitemap and content plan with people from sales, support and operations, since they often notice missing pages or confusing groupings that someone focused purely on design and aesthetics may not catch until much later in the project.

Who will actually run this website once it launches? This question deserves as much attention as the design itself. Decide who owns day-to-day updates, who approves new content, who manages hosting and security, and who is responsible for ongoing maintenance and measurement, before finalising the platform the site will run on.

Platform decisions should reflect these responsibilities realistically. A platform that offers powerful customisation but requires specialist skills to maintain is a poor fit for a team without access to those skills, regardless of how capable the platform itself may be in principle.

Define how often content should realistically be reviewed and updated, and who has the time and authority to do it. A site built with ambitious self-service content plans but no one actually assigned to maintain it will drift out of date quickly, undermining the credibility the redesign was meant to strengthen.

Clarify approval workflows before launch, including who can publish directly and who needs sign-off, so the operating model does not have to be improvised reactively once real content changes are needed urgently after go-live.

Document the operating model alongside the technical handover, including login access, hosting arrangements, backup schedules and a basic maintenance checklist, so operational knowledge does not remain solely with whoever built the site and is lost if that relationship ends.

What belongs on a pre-launch checklist beyond "does it look right"? Functional testing across the elements that are easy to overlook visually but costly to get wrong: every form actually submits and notifies the right person, analytics and conversion tracking fire correctly, redirects from old URLs work as planned, metadata is accurate, and performance and device compatibility are confirmed before the public sees the new site.

Test forms specifically with realistic data, including edge cases such as unusual characters, long input and mobile keyboards, since a broken contact form on launch day can silently cost enquiries for days before anyone notices the problem.

Confirm analytics and goal tracking are correctly configured before launch, not after, so that the first days of real traffic on the new site produce usable data rather than a gap in measurement during the period when comparison to the old site matters most.

After launch, monitor search visibility and conversion signals closely for several weeks, since search engines need time to process a changed site, and some fluctuation is normal. Distinguish expected short-term adjustment from a genuine problem requiring a fix, such as a missed redirect or a page that no longer ranks for a term it previously did.

Keep a rollback or rapid-fix plan ready for the first days after launch, including direct access to whoever can make urgent changes, so a discovered issue can be corrected quickly rather than waiting for a routine update cycle.

The most expensive mistake is treating assumptions as settled decisions. Before design starts, challenge requests that sound obvious but have no clear reason behind them. “We need a more modern website” is a starting point, not enough guidance for choosing between competing ideas.

Copying competitors is another trap. Their navigation, features and visual style may reflect priorities that have little to do with yours. Use other websites to discuss specific qualities, such as readable text or clear product comparisons, rather than asking a designer to reproduce an entire experience.

Watch for these common problems: - Turning every stakeholder preference into a requirement. Ask which user need each request serves and what happens if it is left out. - Assuming a new feature will solve an unclear offer. A calculator, chatbot or booking widget cannot compensate for confusing information. - Discussing only the ideal visitor. Include people using small screens, slower connections, keyboards or assistive technology when setting expectations. - Treating integrations as minor details. Confirm what information must move between systems, who can access it and what should happen when a connection fails. - Adding automation without considering consent or relevance. If WhatsApp and email flows are proposed, define their purpose, permission requirements and stopping rules together.

A useful test is to ask: would we still request this if nobody else had it? If the answer is uncertain, mark it as an assumption to investigate rather than a promise to deliver. This keeps fashionable ideas from quietly becoming expensive obligations.

Run a short validation exercise before approving the full design effort. Its purpose is to expose uncertainty while changes are still relatively simple, not to produce polished screens or guarantee that every decision is correct.

Start with the highest-risk questions. These might concern whether visitors understand the offer, whether a proposed feature is technically feasible, or whether the available budget can support the expected level of customisation. Work through them in this order: - List the assumptions that could cause substantial rework if wrong. Give each one an owner and a date for finding an answer. - Choose the simplest useful test. Discuss sample wording with potential users, sketch a key interaction, or ask a developer to investigate an integration requirement. - Set a decision rule before reviewing feedback. Agree what evidence would justify proceeding, revising the idea or dropping it. - Record the outcome and its limits. A few conversations can reveal confusion, but they should not be presented as proof of what every visitor wants. - Update the brief and estimate. Make unresolved questions visible, with a contingency allowance or a separate discovery task where appropriate.

Finish with a clear commitment point: proceed, reduce the scope, or investigate further. Keep a short decision log so later discussions can distinguish new evidence from previously settled preferences. That gives the design team a firmer starting point without pretending the plan can never change.