Website redesign or focused repair: how to decide

Name the decision the site should support

Describe the main tasks visitors need to complete. A hypothetical engineering firm may need buyers to understand its capabilities and request a suitable technical discussion. If visitors cannot find which materials the firm works with, the immediate problem may be information structure rather than visual style. Begin with that task, not a preference for a new layout.

Gather evidence from enquiries, support questions and a small set of practical user tasks where available. Distinguish observations from opinions. Someone failing to find a service is different evidence from a colleague saying the site feels old. Both may matter, but the proposed scope should explain which problem each change is intended to address.

Audit content and journey together

List important pages, their purpose and their owner. Check whether each page answers a specific buyer question and provides a relevant next step. Look for duplication, missing boundaries and outdated details. A navigation problem may originate in unclear service definitions. Moving the same ambiguous copy into a new menu will not resolve that issue.

Follow complete journeys on a phone and desktop. Can a person compare services, understand requirements and contact the team? Check keyboard use, readable text and error messages as part of the audit. Record where the experience fails and whether the failure is local or widespread. Several broken journeys may justify structural change; one missing explanation may not.

Evaluate the existing foundation

Ask how content is edited, how releases are tested and who maintains the site. Identify dependencies that cannot be safely updated or systems that prevent essential changes. A technically sound site with weak copy may be a repair candidate. A fragile foundation that makes every update risky can change the economics of preserving the current implementation.

Keep the evaluation proportionate. Do not label a system unsuitable simply because it is unfamiliar or not fashionable. Ask for concrete limitations and demonstrations. For the engineering example, an editor may need structured project specifications and document links. Compare whether those needs can be added reliably to the existing site before proposing migration solely for a preferred tool.

Compare two scoped alternatives

Write a repair option with exact deliverables: revised service content, clearer navigation, accessibility fixes and a tested enquiry route, for example. Write a rebuild option with its own deliverables, migration work and ownership model. Include content preparation and approval effort in both. Comparing a fully costed rebuild against an undefined repair produces a misleading decision.

State what each option will not solve. A repaired navigation cannot fix an unclear commercial offer. A rebuild cannot supply missing project evidence or guarantee better sales. Identify assumptions, such as continued access to the current code or availability of product information. If a risky unknown dominates the choice, commission a bounded investigation rather than treating uncertainty as a reason for the largest scope.

Protect useful existing material

Inventory public URLs, assets and content before any replacement. Decide which destinations remain, which need permanent redirects and which should be retired with an appropriate response. Preserve accurate, useful material rather than deleting it because it does not fit a new template. A redesign should not accidentally make a valuable service guide harder to find.

Agree how success will be assessed. Use task completion and content accuracy alongside appropriate business evidence, with honest limits on attribution. Plan a release review, rollback procedure and owner handover. For a focused repair, document the next threshold that would trigger a larger change. That makes the decision reversible and prevents a temporary fix from silently becoming a permanent strategy.

Redesign decision checklist

• Name the visitor tasks and the business decision they support.
• Separate observed failures from aesthetic preferences.
• Audit content ownership, navigation and complete journeys.
• Document concrete maintenance limitations.
• Compare repair and rebuild with equivalent scope detail.
• Preserve useful URLs, assets and approved evidence.
• Agree acceptance checks, recovery and future review points.

Bring the audit and both options into the project discussion. The right outcome is the smallest dependable scope that addresses the real problem and can be maintained afterwards. Sometimes that is a rebuild; sometimes a careful repair gives the business the clarity it needs without replacing everything that already works.