Should you redesign your website or repair what you have?

1. Describe the problem before choosing the solution

A website can feel tired without needing to be replaced. Equally, a polished homepage can hide broken forms, confusing service pages and an editing process that nobody trusts. Start with a short problem statement that describes an observable difficulty. “People cannot find our commercial maintenance service on a phone” gives a designer something to investigate. “We need something more modern” does not explain what success would mean.

Ask the person who answers enquiries what customers misunderstand. Ask the person who updates the website which jobs they avoid. Ask a recent customer what information they needed before getting in touch. These accounts will not tell the whole story, but they help direct the investigation towards actual work rather than personal preferences about colours.

Write down the consequence beside each problem. An incorrect telephone number needs prompt correction. A page that does not explain your service area may generate unsuitable enquiries. An awkward image crop may matter less. This gives your eventual agency a sensible order of work and stops a long list of minor frustrations obscuring the failures that deserve attention first.

Create a simple evidence log that can survive the handover between colleagues. Give each finding an identifier, a short description, the page address, the expected behaviour and the actual behaviour. Describe how seriously each fault affects the business, rather than simply how irritating it feels. Someone reviewing the log should be able to repeat the observation without the original reporter sitting beside them. This also protects against spending a project meeting debating a problem that was already corrected last month.

• Describe the affected task and the page where it happens.
• Record who noticed it, when it occurs and how to reproduce it.
• Separate confirmed failures from suggestions that still need checking.

2. Walk through the journeys that matter

Choose three to five tasks that a useful website must support. For a Belfast service business, these might be checking whether a service is available, finding evidence of similar work, asking for a quotation and changing an opening time. Include an internal editing task alongside customer tasks. A site that is easy to browse but impossible to maintain will gradually become less accurate.

Test on a real phone and a larger screen. Begin from an interior page as well as the homepage, because visitors may arrive directly at a service or project. Follow the enquiry through to the receiving inbox. A reassuring success message is not proof that the right person received the details. Record the actual result and keep any test enquiries clearly labelled.

Include basic accessibility observations: can you move through the menu and form using a keyboard, see where focus is, enlarge the text and understand each field label? The World Wide Web Consortium describes its Easy Checks as a first review rather than a complete assessment. Use that distinction when discussing findings. A quick pass can reveal an obstacle; it cannot certify the whole website.

Try an unfamiliar route through the site. Ask someone who did not help build it to find an answer using the language a customer would use. Do not guide their clicks or explain where a menu item lives. Observe where they hesitate, then ask what they expected to find. This is a small qualitative exercise rather than a representative user study, but it can reveal language your own team has become too familiar with to question. Keep personal information out of any shared observation notes.

• Find one important service without using the search box.
• Submit a labelled test enquiry and confirm receipt.
• Ask an editor to update a routine item without developer help.

3. Separate content, design and technical faults

Group problems by their likely cause before comparing options. Missing delivery information is primarily a content issue. A form hidden beneath unrelated material is a journey problem. A form that cannot send reliably may involve configuration, software or hosting. Several faults can occur on the same page, so avoid assuming a visual refresh will automatically solve everything visible there.

Some changes depend on others. You might be able to rewrite service pages immediately, while a confusing menu needs changes to the page templates. If every template change breaks another part of the site, a developer needs to inspect the underlying structure before promising a small repair. Ask them to explain what they have found in business terms, including examples of changes that can be made safely and changes that need more investigation.

A useful investigation ends with evidence, a proposed remedy and a remaining uncertainty for each important item. It should not become a report full of unexplained scores. One low laboratory performance score does not establish the cause of poor enquiries, and a healthy score does not prove visitors understand the offer. Combine technical checks with the practical tasks you have already observed.

Check whether the problem belongs outside the website. Slow responses may follow a successful form submission because nobody owns the inbox. Unsuitable enquiries may reflect an advertisement that promises a different service. An abandoned booking may involve an external provider rather than the main site. Draw the complete route and mark where responsibility changes. You can still improve the website’s explanation, but replacing its templates will not automatically correct a failure in another part of the process.

4. Recognise when a repair is proportionate

Repair is a credible option when the content structure still makes sense, the software can be maintained, and important problems have identifiable causes. A dependable website with an unclear contact page may need better wording, a simpler form and proper delivery checks. Replacing every page would introduce work that does not directly address the problem.

Ask for a repair proposal with clear limits. It should name the affected pages or features, explain the expected change and describe how completion will be checked. Include a backup and a way to recover from the change. Where possible, try the repair on a separate test copy before applying it to the live website. The level of preparation should match the consequence of a failure.

Agree a review point after the fix. For example, confirm that enquiries reach the correct inbox, then ask staff whether customers still report the same confusion over a sensible observation period. Do not turn a small sample into a firm claim about conversion improvement. The first question is whether the repair solved the observed fault and whether a wider problem remains.

A repair can also buy time for a considered redesign. Keeping contact routes accurate and essential pages usable while the business prepares content is often more practical than allowing the current site to deteriorate during a long procurement process.

A useful small repair can also test a wider assumption. If you believe customers are missing a service because of confusing navigation, trial a clearer label and a direct route on the existing site where practical. Agree the question and the observation method first. You may learn that the label was the issue, or that the service explanation itself is incomplete. Do not treat a short trial as a reliable revenue forecast; use it to reduce uncertainty about the next piece of work.

For faults that can be addressed within the existing website, our website support expertise explains how to organise the repair work.

5. Recognise when a redesign addresses the real constraint

A redesign becomes more persuasive when important problems share the same underlying limitation. Perhaps the business now serves two audiences but the navigation cannot explain the difference. Perhaps the editing system requires a developer for routine work, and the accumulated workarounds make changes increasingly fragile. These are reasons to examine the structure of the website, not simply repaint its pages.

Business changes can also justify a new approach. A company that previously sold one service may now need separate journeys for installation, servicing and commercial contracts. Before searching for website redesign specialists, list those journeys and the evidence each audience needs. This helps you judge whether a proposed rebuild reflects the business rather than an agency’s preferred template.

Ask which parts should be retained. A recognisable brand, a useful project library and clear service descriptions may still have value. “Start again” should not mean discarding everything without review. The proposal should distinguish structural changes from content rewriting, photography, integrations and ongoing care, so each part has a purpose and an owner.

Also ask what a redesign will leave unresolved. A new site cannot supply missing product information, answer enquiries for the team or guarantee search positions. Naming those dependencies early makes the scope more realistic and gives the business time to prepare.

Ask about the editing model as well as the visible design. Staff may need a controlled set of page components, consistent project fields or permission levels that prevent accidental structural changes. More freedom is not always easier to use. Request a demonstration of the intended editorial tasks and explain who will perform them. The proposed solution should match their available time and confidence, rather than assume they want to become website designers alongside their existing jobs.

If the evidence points towards a rebuild, our website redesign service starts with what should be kept, changed and tested.

6. Compare repair and replacement on equal terms

Compare the same business needs over the same planning period. One repair quotation may include only the immediate fault, while a rebuild quotation includes content, training and support. The larger figure tells you little until the scope is aligned. Ask both options to cover the essential customer tasks and explain any limitations that remain.

Include internal effort. Who will approve page content, gather project photographs, check product details and attend reviews? A technically straightforward rebuild can stall when those responsibilities are unclear. Repairs also consume staff time if they depend on repeated manual work. Record this burden even if you cannot confidently convert every hour into a financial figure.

Hypothetical example: a small building services company has clear service pages and a dependable editor, but its enquiry form sends to an unused mailbox. A focused repair, delivery test and ownership check could be appropriate. Another company with the same symptom also has unsupported software and no practical way to edit its service structure. It needs a wider assessment. The symptom alone does not determine the answer.

Show what is still uncertain in the comparison. Separate confirmed work, optional work and allowances that depend on further investigation. Ask what an allowance covers and how extra work would be approved. If a supplier cannot yet inspect an external connection, leave that question visible rather than inserting a guessed fixed figure into the spreadsheet. Record what is missing and the smallest investigation that would answer it. A low total is misleading if it quietly leaves out a connection your business needs.

Include a deliberate “do now” category in the options review. Correct factual errors and broken contact routes without waiting for the larger design decision, provided the changes can be made safely. Record those corrections so the proposed rebuild does not later reintroduce old information from an outdated copy. Also identify work that should wait because it would be discarded immediately by the chosen redesign. This avoids spending twice on the same problem while still protecting customers from an obvious current failure.

Ask how the investigation will end if the evidence is inconclusive. A short technical review should produce a usable decision, not simply a larger list of questions. Agree the systems or pages it will inspect, the business questions it will answer and the format of the recommendation. Where an uncertainty cannot be resolved without additional access, the report should name that dependency and explain its effect. This helps you judge whether another discovery stage would change the choice or merely delay it.

Record how the important customer tasks work before commissioning changes. Record the form recipient, editing steps and pages used in each task. If available, retain relevant existing measurements with their limitations. After work is complete, repeat the same checks rather than inventing a different success measure. You may learn that the site is easier to maintain even before you have enough commercial data to assess enquiries. That is a useful result if it was part of the agreed purpose. Keep that record with the final handover so later changes can be assessed against the same tasks.

• Compare immediate work, recurring care and work likely to follow separately.
• List assumptions, exclusions and dependencies on other suppliers for each option.
• Ask what evidence would cause the recommendation to change.

7. Protect useful pages and existing web addresses

Before a rebuild, make an inventory of the current site. Include service pages, project pages, downloadable documents and campaign destinations. Identify content that customers or staff still use. If you have reliable search and analytics records, use them to help prioritise review, while remembering that incomplete measurement can hide valuable pages.

When addresses change, prepare a mapping from each important old address to its closest relevant replacement. Google’s guidance on moving a website recommends preparing and testing the new site, mapping addresses, implementing redirects and monitoring afterwards. That is a migration task with its own owner. It should not be left until the final afternoon because the new design looks finished.

Do not send every retired page to the homepage by default. Discuss the appropriate destination for each group of content, including pages that genuinely have no replacement. Keep useful wording and context where it still serves readers. If the business is changing its domain, platform and page structure together, ask whether the changes can be staged to make faults easier to diagnose.

Keep copies of the inventory and the agreed mapping in the handover material. They are useful when somebody later discovers an old brochure link or a customer reports that a bookmarked page no longer works.

Do not overlook addresses outside the main navigation. Sales teams may share specification downloads, campaign landing pages or old project links in proposals. Search records can help, but ask staff about their own materials too. Check links in email signatures, printed brochures and active campaigns before launch. If a document is replaced, establish whether the old address needs an updated file or a relevant destination. The purpose is to preserve a useful route for a person who is already trying to find something specific.

For changes that affect how customers find you, connect the redesign brief with the SEO work behind your website.

8. Make launch a tested business change

Agree acceptance checks before development finishes. These should cover real actions: a customer finds a service, submits an enquiry, receives the correct confirmation and reaches someone who can respond. An editor updates a page. A key old address reaches the correct new content. Give each check a named reviewer and record what counts as a pass.

Choose a launch window when the right people can respond. A quiet trading period is only helpful if someone is available to check enquiries and resolve problems. Confirm who controls the domain and hosting, who can authorise changes and where the recoverable copy of the previous website sits. Test the recovery approach to a level proportionate to the work.

After launch, repeat essential checks on the actual public website. A test environment cannot expose every difference in email delivery, account settings or external connections. Monitor broken links, form receipt and important journeys, then review search reporting as new pages are processed. Google notes that search visibility can fluctuate during significant site moves, so avoid treating launch day as a guaranteed final result.

Write the plan for handling problems before release. It can be brief: who watches the enquiry inbox, who reviews reported faults, who decides whether a fault blocks trading and who communicates any temporary workaround. Confirm how to reach the developer during the agreed launch period. The plan should also name a business contact who can answer factual questions quickly. A technically available agency cannot resolve every uncertainty if nobody on the client side can confirm which service details or recipient addresses are correct.

• Confirm the content and enquiry recipient list before release.
• Record the decision maker for proceeding or restoring the earlier version.
• Book a review after launch with both the agency and the internal website owner.

9. Work through a hypothetical decision and approval review

Hypothetical example: a Northern Ireland consultancy has a service website built several years ago. Staff describe it as dated and want a replacement before a forthcoming event. The team pauses long enough to record four findings: visitors misunderstand one service, two forms have unclear labels, project pages take too long to publish and a supplier connection has no documented owner. This example is invented to demonstrate the decision process.

The first review separates urgency from scope. The misunderstood service can receive a factual rewrite immediately, subject to approval. The forms need a focused usability and receipt check. Publishing projects requires an editor demonstration to establish whether the delay comes from the software or an internal approval queue. The undocumented connection requires an account and responsibility review before anyone changes it.

The consultancy asks for three options. Option one repairs the confirmed faults and documents the existing setup. Option two makes the same repairs, then improves project publishing within the current system. Option three redesigns the site around a revised service structure and a new editing approach. Each option must state which observed problems it resolves, what it leaves behind and what business input it requires.

The comparison reveals that a full rebuild would depend on new service descriptions and project approvals that the business cannot supply before the event. The consultancy could still decide to rebuild, but it should not pretend the content dependency disappears. One sensible decision might be a defined repair stage followed by a separate redesign brief. Another might be postponing the website change planned for the event. The appropriate choice follows the actual constraints.

The approval note records the chosen option, the reasons, the excluded work and a review date. It also records the conditions that would trigger a wider reassessment, such as a technical inspection showing that safe maintenance is no longer practical. This prevents a temporary repair from becoming an indefinite plan by accident.

Use the same structure for your own decision meeting. Ask one person to present the evidence, another to explain operational constraints and the proposed supplier to explain the technical uncertainties. Keep the decision connected to the customer tasks established at the beginning. A preference for a new look can still be a valid brand choice, but it should be named as that choice rather than presented as a proven remedy for every business problem.

Before approving the choice, check the person responsible for each dependency has accepted it. A content owner needs time in their schedule, not merely their name in a document. An external supplier needs to confirm what access or assistance is available. A launch reviewer needs to know when they will test and how they will report a problem. Mark any unconfirmed responsibility as unresolved. This small approval check can expose a schedule that looks convincing on paper but relies on work nobody has agreed to do. Resolve those gaps before turning the chosen option into a fixed launch promise.

10. Finish with a decision brief you can act on

A useful brief can begin with one page. Describe the audiences, essential tasks, confirmed problems, available evidence and practical constraints. Add the current platform if known, the people responsible for content, and any dates driven by the business. Attach the detailed findings rather than making every supplier repeat the same discovery work without context.

Ask for a recommendation that explains why repair, phased improvement or redesign is proportionate. A responsible answer may identify a small investigation before a fixed scope can be offered. Judge the clarity of that uncertainty. “We need to inspect the booking connection before we can estimate the change” is more useful than a confident promise based only on the homepage.

Podium’s website redesign service is the next step when the evidence points towards a structural change. The aim of this guide is to help you arrive with a clearer problem and make a better decision about scope. Keep the approved brief beside the acceptance checklist throughout the project, so attractive design decisions remain connected to the work the website must support.

Bring a short set of questions to the first supplier discussion: what can be confirmed from the available evidence, what needs investigation, and what would you recommend doing first? Ask the supplier to explain a proportionate next step without assuming that the largest project is the best answer. Keep the decision record and the evidence log together. They will help a future colleague understand why the work was commissioned and whether a later request belongs within the same scope.

If visits are arriving but enquiries are not, use our website enquiry audit to separate traffic, content and contact-form problems before choosing a redesign.