A Browser Back-Button Contract for a Multi-Step Quote Configurator
Visitors press Back inside configurators. They do it to fix a mistake, to compare, or because they are used to it. If Back throws away their choices, or worse, keeps stale choices that no longer match the screen, they lose trust in the quote. This article proposes a contract you can write down before building, then test against. It is a design proposal, not a description of any existing tool.
Decide the contract first
For each step, answer three questions in writing:
- Does this step get its own history entry, so Back moves one step?
- Where does the entered data live: in the address, in page memory, in browser storage, or on a server draft?
- When a later step depends on an earlier answer, what happens if the earlier answer changes?
A workable default to consider: each step gets its own history entry, entered values are restored when returning to a step, and a changed answer invalidates only the later answers that depended on it, with a visible notice.
History navigation state table
Hypothetical four-step configurator: 1 Product type, 2 Dimensions, 3 Options, 4 Contact details.
| Action | Expected step | Expected data | Notice shown |
|---|---|---|---|
| Next from 1 to 2 | 2 | Step 1 kept | None |
| Back from 2 | 1 | Step 1 and step 2 values kept | None |
| Forward again | 2 | Step 2 values restored | None |
| Change product type, then Next | 2 | Dimensions kept only if still valid, otherwise cleared | Names what was cleared |
| Back from 4 to 3 | 3 | Options kept; contact details kept | None |
| Reload on step 3 | 3 | Restored from chosen storage, or a clear restart message | Yes, if restart |
| Open step 3 address directly | Earliest incomplete step | Nothing invented | Explains why |
| Back after submission | Confirmation or step 1 | No second submission | Explains |
The last two rows are where many designs break. A submitted quote should not be resubmitted by pressing Back and Next.
Branching choices
If the configuration is short and not sensitive, keeping it in the address makes steps shareable. If it contains personal contact details, consider keeping those out of the address and out of long-lived storage. If the configuration is long, a server draft may suit better, but it then needs an expiry rule and a way to discard it.
If you replace the history entry instead of adding one for small changes such as toggling an option, Back will skip those changes. That is usually what people want. Adding an entry for every click usually is not.
Hypothetical worked example
Imagine a visitor picks a wide product type, enters a width, reaches Options, then presses Back twice and switches to a narrow type. The width they entered is outside the narrow type's allowed range. Under the contract the width is cleared, a notice says the width was cleared because the type changed, and the options that depended on width are marked as needing a recheck. Pressing Forward does not silently restore the old width.
Stop conditions
Pause the release if any of these happen in testing: the screen shows one thing while the stored data says another; a Back press submits or duplicates anything; a changed answer leaves a dependent answer invalid but unflagged; or contact details appear somewhere you did not intend.
Acceptance checks
- Run every row of the table by hand, using the browser Back and Forward buttons, not just the on-screen buttons.
- Repeat after a reload and after opening the configurator in a second tab.
- Test with the keyboard only.
- Have someone unfamiliar with the design do a full pass and say aloud what they expect before each press.
- Record unexpected results as failures of the contract, not of the visitor.