Guide / comparison

Refresh, repair or rebuild? Start with what works.

Before replacing a website, separate the part that looks dated from the part that actually prevents a customer from doing something useful.

Guidance by Happy to Handle. Updated . Added or revised the decision artifacts and local worksheets described in this guide.

01 / Guide / comparison

Name the customer task first

Pick one real task: understand a service, find opening hours, request a suitable quote or complete a booking. Try it on a phone and with a keyboard. Write down the point where it becomes unclear or fails. “It feels old” is a design observation; it is not yet a rebuild scope.

  • Can a first-time visitor explain the offer from the page?
  • Is the needed information current and easy to find?
  • Does the next action work, including its confirmation and error states?
  • Which existing pages, content or search entry points already do useful work?

02 / Guide / comparison

Keep is a valid outcome

Keep / repair / refresh / redesign decision matrix
ChoiceEvidence that could support itDisruption / dependencyAcceptance
KeepImportant customer tasks work; facts and ownership are accurateContinue proportionate upkeepRecord why change is not needed and when to review.
RepairOne reproducible defect within otherwise useful structureBounded diagnosis, backup and adjacent-task checksOriginal defect fixed and nearby behavior preserved.
RefreshWorking platform but outdated facts, navigation or presentationContent/asset review and representative template approvalUseful material retained; actual task improves under an agreed test.
RedesignDemonstrated structural/platform limit prevents the required journeyContent/URL inventory, migration, release and rollbackProtected paths, content, functions and handover pass agreed checks.

If one reproducible defect is the only blocker: Start with a bounded repair

What changes the cost of a website?

03 / Guide / comparison

Write a proportionate change decision

This blank worksheet stays in the page. Use roles and non-sensitive examples. Unknown values identify decisions to resolve; they are not a score.

Use roles and hypothetical examples. These fields stay in this page; no information is submitted or saved.

Separate a cosmetic preference from a broken task.

If the cause is unknown, leave diagnosis open.

Include recurring obligations and rights.

State what evidence would make another option appropriate.

A larger change needs its own approved scope.

A practical website project checklist

04 / Guide / comparison

Choose the smallest change that solves it

Repair
The structure and content fit, but a specific link, layout or function is broken. Define the issue and test the nearby paths after the fix.
Refresh
The platform is serviceable, but presentation, navigation or content needs a coherent update. Preserve useful material and review representative pages first.
Rebuild
The required structure, platform or functionality is no longer workable. Plan content, URL mapping, integrations and cutover as part of the project.

05 / Guide / comparison

Keep a record before changing anything

Inventory important URLs, forms, accounts, files and integrations. Record what must be kept, changed or retired. When URLs move, plan the destination and redirects instead of sending every old page to the homepage. A rollback plan belongs beside the launch plan.

06 / Guide / comparison

Use a representative slice

Review a homepage, a typical service page and the real conversion path before scaling the layout. Include a narrow screen, keyboard navigation, long headings, missing images and error feedback in the review. Reuse the tested patterns without copying the same answer into every page.

07 / Guide / comparison

Turn the decision into a brief

List the customer task, the evidence of failure, what needs to stay and the smallest change you think will help. Keep diagnosis open if the cause is unclear.

If a different decision is blocking you: Choose another question in this topic

Website redesigns and refreshes