# Should a Multi-Step Form Show a Back Button? A/B Test

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/should-a-multi-step-form-show-a-back-button-ab-test

## Hypothesis

If each step of the multi-step form gets a visible back button, users who want to fix an earlier answer can go back instead of abandoning the form. Recovered forms could raise the form completion rate, though the extra navigation may add a little to form completion time.

## When to run this test

Run this test when you see users getting stuck in the multi-step form because they cannot fix an earlier answer, such as step-level abandonment clustered on one screen, session recordings of people using the browser back button and starting over, or support contacts about information entered by mistake. If the button helps, those users go back, correct the answer and finish the submission, even if few people use it. Before launch, confirm that entered data survives going back; if it does not, fix that bug first, or you will be measuring your own data loss.

## Primary metric

**Form completion rate**: Compare successful submissions to see whether adding a back button affects completion.

## Other metrics

- **Form data loss rate**: Check whether previously entered information is lost when visitors go back and forward.
- **Step-level abandonment rate**: Compare exits at each step of the form.
- **Validation error rate**: Track validation errors that appear when submitting or moving between steps.
- **Form completion time**: Measure time from form start to successful submission.

## What to check before and during the test

- **Back control**: Add a visible back button without changing the existing forward action.
- **Keep constant**: Keep steps, fields, validation and data persistence the same in both arms.
- **Usage**: Track use of the button within the variant; compare overall completion across assigned arms.
- **Browser behavior**: Check how browser-back navigation works alongside in-form navigation.
- **Separate test**: A final summary screen with edit links is a separate variable.

## What to watch when reading the result

- Compare the form completion rate across the assigned arms. Longer completion time alongside lower step-level abandonment and fewer validation errors may be a fair price for easier corrections; if abandonment or the form data loss rate rises, do not ship.
- Track button use only within the variant, and do not dismiss the button as useless because few people click it; it can be a rare but critical recovery path. Make sure the variant does not block browser-back navigation, or the result will reflect that restriction rather than the button.
- What you find covers the form and step structure you tested. Where the form includes a payment step, add back navigation there without loosening payment security checks, and read that step separately.
- Only some users need to correct an answer, so the effect thins out across all traffic and the difference may be small. Work out the traffic needed to detect it with the [sample size calculator](https://alidemirbas.com.tr/en/calculators/sample-size-calculator), and do not stop the test early.

## Frequently Asked Questions

### What should be verified before adding a back button?

Entered data must survive moving backward and forward. Otherwise the experiment mixes navigation support with data-loss defects. Preserve fields, validation and step structure.

### Does low back-button usage make it useless?

No. It can be an infrequent but important recovery path. Use overall form completion as the primary outcome and report button use diagnostically within the variant.

### Where would extra navigation effort appear?

Inspect completion time, abandonment by step and validation errors. Preserve the number of steps while testing navigation rather than changing both together.

### How does browser-back behavior affect the test?

Make browser navigation compatible with form navigation. Do not block the browser’s back action. Preserve payment and transaction-safety checks where applicable.