Conversion repair

Start with the real conversion obstacle

Finding a conversion problem only helps when the next change removes the real obstacle. Check intent, the first screen, proof, friction, speed, and measurement before changing cosmetic details.

Illustration of a broken customer path being repaired through conversion checkpoints

Choose a repair you can explain

Start with a page that receives relevant visits and an obstacle you can describe. Record what the visitor was trying to do and what prevented it.

If you have only a low conversion rate, use part one’s diagnosis first. The rate tells you an outcome; it does not identify which change will help.

  • Observed failure: a form rejects a valid entry. Reproduce and repair it.
  • Observed confusion: readers cannot tell what the enquiry includes. Clarify the promise and observe another attempt.
  • Uncertain preference: two clear versions may perform differently. Compare them with a suitable test.

A broken action does not need to remain broken while you wait for an experiment.

Match the change to the evidence

Wrong arrival

If an ad promises a product that the landing page does not supply, correct the ad or destination. Review search, email and internal-link promises too. A new button cannot make the wrong offer fit.

Unclear opening

If visitors cannot identify the service or next step, state the audience, outcome and scope near the start. Make the action describe what follows. Remove competing claims, badges or sliders that obscure that decision.

Missing proof

If buyers ask whether a product fits or a service covers their situation, place the relevant specifications, examples, limitations or process beside that question. Add delivery, price, refund or guarantee terms only where they apply and are accurate.

Difficult action

If a useful enquiry cannot be completed, inspect required fields, error messages, payment steps and confirmation. Keep information the business needs; remove requirements with no use at that stage.

Slow or unstable use

If content loads late, controls move or filters respond slowly, reproduce the problem on the affected page and device. Investigate images, scripts and the shared site components responsible.

A clearer form can keep a necessary question

Suppose an upholstery workshop needs photographs to assess a repair. In this hypothetical example, visitors stop at a required field labelled “Attachments”. Removing it might increase submissions while leaving the workshop unable to assess them.

Proposed change: label the field “Photos of the furniture”, explain which views are useful and show the actual supported file types and size limit. Give a clear error if a file is rejected. Offer an alternative contact route if the business can handle one.

Keep: the information needed for the assessment. Remove: unrelated questions that can wait until the workshop knows whether it can help.

Check: can a visitor understand the request, upload a supported file, correct an error and receive confirmation? Does the workshop receive enough information to reply?

A higher submission count alone would not establish success. Review incomplete enquiries and extra follow-up work alongside completed submissions. This is a proposed repair, not a reported client result.

Write the change as a testable statement

Use this structure: “For this audience on this page, we observed this obstacle. We will make this change. We expect this action to become easier, and we will check this outcome.”

For the photo field: “Visitors do not know which images to upload. We will clarify the label and instructions. We will check successful uploads and whether enquiries contain usable photographs.”

  • Scope: name the page, field or step being changed.
  • Evidence: keep the observation or reproducible error beside the proposal.
  • Outcome: choose successful completion or qualified demand, not a decorative interaction.
  • Possible downside: check whether the change reduces needed information or makes another task harder.
  • Owner: assign the repair to the person who controls the copy, form, checkout or shared site behaviour.

Keep changes focused enough to understand. A coherent repair may include a label, instructions and an error message together; treating each word as a separate experiment would not help.

Choose how to evaluate the change

Use direct verification for a known defect. Use observed tasks to check whether people can understand and complete a revised route. Use a controlled comparison when you need evidence about the relative effect of working alternatives.

These methods answer different questions. Successful usability sessions do not establish a conversion uplift across all visitors.

  • Direct repair: reproduce the failure, make the fix and confirm successful completion and receipt.
  • Limited traffic: observe realistic tasks, inspect enquiries and compare suitable periods. Describe before-and-after changes without claiming they isolate cause.
  • A/B test: assign eligible visitors randomly to the original and revised versions. Define the main outcome, sample needs, duration and analysis before interpreting results.

Sample requirements depend on the effect you need to detect and available traffic. See the UK government’s A/B testing guidance.

Check the working page before judging results

  1. Test the changed page on desktop and a phone, including slow loading, required fields and correction of an invalid entry.
  2. Complete the action and confirm that the business receives the order, booking or enquiry. Identify test records so they do not inflate results.
  3. Check that measurement records successful completion once, rather than counting repeated clicks as new outcomes.
  4. Inspect the pages that share the changed form or component. A reusable fix should work for each affected route.
  5. Record the change date and any concurrent campaign, price or service changes that may affect comparison.

Core Web Vitals provide evidence about loading, responsiveness and visual stability. Compare field information from real use with controlled tests used for diagnosis; a good score does not prove that visitors understand the offer or become customers. See Google’s Web Vitals guide.

Decide what the result supports

The obstacle is removed

Confirm the original task works and that the change has not damaged another route. Keep the repair even if traffic is too limited to quantify its commercial effect.

The outcome improves

Check enquiry quality, completion and downstream results, not only the headline rate. Consider whether your comparison supports a causal conclusion or only an observed association.

The result is unclear

Keep uncertainty explicit. Check measurement, visitor mix and the original assumption. Do not announce a winner from a few visits or keep extending an experiment until a preferred result appears.

A new problem appears

Correct or reverse the harmful part, then check the original task again. Record what was learned before selecting the next supported improvement.