Before you redesign your website, decide what should actually change

Before a redesign, record what the current site needs to preserve, what has a documented problem and how each proposed change will be checked. Appearance can motivate a review, but it does not establish that every part of the site is broken.

Define the decision in concrete terms: making the offer understandable, repairing an enquiry path or organizing important information. If the problem is still a hypothesis, include the investigation in the brief rather than presenting a preferred design as the proven answer.

For example, make the website more professional is difficult to verify. Explain the assessment deliverable before the enquiry form gives the team something to build and check. A visual refresh can still be a valid business choice; keep its purpose separate from a claim that it will solve unmeasured sales problems.

Write down what prompted the project: feedback, a changed service, a reproducible failure or a decision to reposition the business. Each reason suggests different work. This prevents a design team from having to guess whether the task is mainly presentation, content, structure or functionality.

List important pages, their purpose, key content and the paths visitors use. Save relevant observations with their page and context. Where authorized data exists, record the period and conditions so that later comparisons have a meaningful basis.

Include current URLs, search instructions and relevant page relationships in the baseline. These are checks to preserve and verify in the redesign plan. A screenshot alone cannot capture route behaviour, enquiry delivery or a search engine’s reported indexing state.

Start with the home page, main service pages, a useful guide, contact details and the enquiry journey. Add pages with meaningful search visibility or known business use when the owner can supply that information. Do not assume that a low visit count makes a page disposable: it may answer a specialist question during a valuable sale.

For each selected page, retain the address, its main answer, important claims and the next action. Save the mobile view where it exposes a different problem. If you have no analytics, your baseline can still describe the current website accurately; leave its performance unmeasured.

• Page purpose: the question or task the page serves.
• Useful material: explanations, examples, terms and contact information worth preserving.
• Journey: where readers arrive, what they can do next and any reproducible failure.
• Available owner data: the period, source and relevant enquiry or search context.
• Unknowns: the access or investigation needed before a removal or replacement decision.

Preserve useful explanations, supported proof and working journeys unless the new brief identifies a reason to change them. A section may be visually dated yet answer an important buying question. Record the role it serves before removing it.

Distinguish evidence of usefulness from familiarity. If a team says a page works well, ask which observation supports that statement. If that evidence is unavailable, the keep decision may still be reasonable, but it should remain a planning judgment rather than a measured conclusion.

A clear service description does not need a new promise merely because the typography changes. A relevant case should keep the context that makes its result understandable. If the offer changes, review both the current description and its supporting examples so old evidence does not silently support a different service.

Useful search content also deserves a deliberate decision. Record which questions a guide answers and how readers continue from it. If it moves or is merged, the replacement should preserve its useful answer and the routes that lead to it. The address itself can matter to existing links and bookmarks.

Name the condition and its consequence or unresolved risk. An offer missing its scope needs a confirmed explanation. A form with an observed validation problem needs a reproducible fix. A generic instruction to make the site modern is too broad to verify.

Keep different kinds of work visible in the brief. A new layout does not decide your business terms, and revised copy does not repair a failed submission. Problems can overlap, but the team needs to know what each change is meant to resolve.

A competitor comparison can reveal unanswered questions, but another site’s presentation is not proof that copying its design will work. Use the insight to write an original requirement based on your audience and facts.

Ask how far the documented problem extends. One page missing a deliverable may need an editorial change. A shared form error may need a common fix across pages. A navigation system that cannot accommodate the current services may require broader structural work.

Consider dependencies and upkeep as well as appearance. Can the existing site support the necessary content and journeys? Can the responsible team maintain the result? If every proposed correction requires a workaround, investigate whether the underlying structure is part of the problem.

A wider rebuild makes more sense when you can name the constraints it needs to remove. Before committing, compare the work, preservation risks and acceptance checks for a targeted correction and a rebuild. The least extensive option that meets the actual requirement is worth considering.

If evidence is incomplete, investigate the part that could change the decision. For example, confirm whether the current enquiry failure affects a shared form before commissioning replacements for every service page. Uncertainty belongs in the brief rather than becoming a confident claim that the whole site needs replacing.

These fictional entries show how an audit can narrow a redesign. The decision column gives a direction, while the verification column defines what must still be true after the work. A keep decision can include a new presentation while protecting the meaning.

Use one row for each important area. In Page or area, enter the address or shared component. In Keep, write the meaning or behaviour to preserve; in Change, describe the specific task rather than a style preference. Evidence or reason should explain why the row exists.

In Verify after, state how someone will check the result. Owner role identifies who can supply facts, make the change or confirm completion. You can name a service owner, editor, designer or developer without putting personal customer information in the worksheet.

The filled row is an illustrative example. The blank rows are for your own decisions; start with the areas most likely to affect the redesign scope. Print the matrix before leaving if you need a copy. It stores notes only while this page remains open and does not submit a brief or implement the work.

Group related tasks and identify dependencies, unresolved questions and owners. Separate mandatory preservation checks from optional experiments. A team should be able to see what needs a decision before design starts and what can be checked during implementation.

Include the current page, the observed problem, the supporting material, the proposed change and the acceptance check. Add the information the redesign must preserve. If the suggested change is still a hypothesis, say what needs testing before treating it as the final answer.

The fictional brief below is deliberately narrow. The business may still choose a new visual design, but this requirement can be assessed independently. It avoids turning one incomplete description into a claim that an entire website caused lost sales.

Acceptance should match the requirement. If the task clarifies scope, compare the new copy with approved product facts and test understanding. If it changes a route, verify the destination and relevant links. If it changes a form, use an authorized completion and delivery check.

Recheck the important baseline journeys and preserved information on the published site. Open old addresses, follow the main navigation and related links, inspect key service terms and repeat the agreed form checks on mobile and desktop. A design preview cannot establish that the released site behaves the same way.

For pages expected in search, ask the relevant specialist or property owner to compare the intended search settings and available indexing evidence. Public access is an eligibility question; it does not prove actual indexing. Google’s technical requirements explicitly distinguish eligibility from guaranteed indexing.

Keep a short record of the requirement, result and remaining issue. Correct a reproduced release failure before interpreting it as a marketing experiment. A completed redesign and a working form still need appropriate business data before you can claim more qualified enquiries.

Review the changed areas after release and revisit the wider journey when the offer, audience, navigation or enquiry process changes. The right interval follows your purpose and the scale of change; there is no useful universal schedule for every business.

If you compare behaviour later, keep the same definitions and note changes in traffic, campaigns and services. Direct verification asks whether the requested change works. Performance review asks what happened to relevant users and business outcomes. Keep both, but do not substitute one for the other.

An audit before redesign helps decide what to preserve and change. A review after redesign checks the implementation against those decisions and may identify new issues. Neither is a guarantee of search visibility or sales growth.

Use the observations to define the work before changing the whole website. If content, search and enquiry questions overlap, a complete Alytixx website audit can help you discuss them together and make the next brief clearer.