The Undo Test: Scoring UK Digital Journeys on Whether They Let Users Change Their Mind

Most UK product teams test the forward path. They script the happy journey, confirm the confirmation page, and sign off. The reverse path — the one taken by anyone who misreads a question, changes a delivery address, or simply wants to check what they entered two screens ago — is rarely scripted at all. Yet the browser's Back control is the most-used navigation affordance in existence, and what it does inside a modern single-page application is often decided by accident rather than design.

This article sets out a practical audit that any UK product team can run in a day, and a scoring model that turns the findings into something a delivery manager can act on.

Why reversal deserves its own test

A service that cannot be reversed is not neutral. It transfers risk to the user: the risk of paying twice, of submitting a duplicate application, of losing twenty minutes of typed answers, or of arriving at a verification screen with no route back to the details that caused the failure. Under the WCAG 2.2 success criteria, error prevention for legal and financial submissions (3.3.4) and redundant entry (3.3.7) both assume a user can review and correct what they have provided. If Back destroys that ability, the criterion is not met in practice, whatever the audit spreadsheet says.

There is also a commercial argument. Abandoned checkouts, duplicated contact-centre calls and disputed card authorisations are expensive. Many of them begin with a user pressing Back and finding themselves somewhere they did not expect.

The five failure modes to look for

In our audits of UK services — banking, local authority portals, retail checkout, health bookings — the same patterns recur.

1. State loss. Answers evaporate on return, sometimes silently, sometimes behind a generic session warning that may or may not be true.
2. Duplicate submission. Returning to a payment or application screen and pressing the primary button again generates a second request, a second authorisation, or a second case reference.
3. The misleading warning. An interstitial claims progress will be lost when it is saved, or claims it is saved when it is not. Both erode trust, and the second is worse.
4. Focus and position loss. The page reappears at the top, or the virtual cursor lands nowhere in particular. For screen reader and keyboard users this is disorienting in a way that sighted mouse users never see.
5. The one-way door. A confirmation or pending state that refuses both forward and backward movement, leaving the user to telephone during opening hours.

A repeatable audit protocol

1. Map the reversible moments

List every point in the journey where a reasonable person might change their mind: after address entry, after the confirmation-of-payee name check, after selecting a delivery option, after uploading evidence, after a one-time passcode has been requested, and after the final submission button has been pressed. These are your test points, not the screens that are easiest to reach.

2. Build a back matrix

Do not test on one browser and call it done. Run the matrix across Safari on iOS, Chrome on Android, Firefox on desktop and Edge on desktop, and at three depths: one press, two presses, and a long press-and-hold to the history origin. Record what the user sees, what the network sees, and what the back-end sees — three different questions that frequently produce three different answers.

3. Instrument the journey

Use the browser's network panel and server logs alongside the screen recording. For any submission screen, count the POST requests generated by repeated Back-and-forward cycles. Check whether an idempotency key is present and honoured. For redirected payment authentication — increasingly common under Strong Customer Authentication — test what happens when the user returns from their banking app via the browser rather than via the merchant's return URL, and whether the order is left in a pending state that the user cannot resolve.

4. Read the warning copy aloud

Interstitials are the service's voice at its most anxious. Read each one aloud and ask whether it is accurate, specific and actionable. "Your answers will not be saved" is honest. "Are you sure?" with no consequence stated is not. Where progress genuinely is stored, say so and say for how long.

5. Test with assistive technology

Repeat the critical back journeys with NVDA on desktop and VoiceOver on iOS. Note whether focus returns to a sensible element, whether the page announces a change of context, and whether any restored content is reachable without re-traversing the entire document.

The twelve-point rubric

Score each of the six criteria from 0 to 2 across the full matrix, taking the weakest result as the score rather than the average.

Criterion	0	1	2
State retention	Answers lost with no warning	Partially retained or inconsistently retained	All answers restored accurately
Submission integrity	Repeat submission creates duplicate case or charge	Duplicate blocked but error unclear	Idempotent and clearly confirmed
Warning accuracy	Messaging contradicts reality	Vague or unactionable	Specific, accurate, actionable
Focus restoration	Focus lost or reset to top	Focus lands nearby	Focus returns to the relevant control
Dead-end recovery	No route forward or back	Route exists but undiscoverable	Clear route onward and back
Assistive technology parity	Journey breaks	Degraded but completable	Equivalent experience

10–12: sound. Reversal behaves as users expect. Keep it in regression testing. 7–9: fragile. Works in the lab, likely to break under real load or after a release. Prioritise the weakest two criteria. 0–6: one-way. The service assumes users never change their mind. Treat this as a defect, not a design preference.

Fixes that hold

Persist draft state server-side with a clear resumption window rather than relying on tab memory. Make submissions idempotent so that a repeated request returns the original reference rather than creating a new one. Prefer history replacement over history stacking for intermediate states, so that Back moves between meaningful steps rather than between transient ones. Restore focus explicitly after a view is rebuilt. And review every warning against what the system actually does — a truthful message is cheaper than a support call.

Make it routine

Add the back matrix to the definition of done for any change that touches a form, a payment step or an identity check. Two hours of scripted reversal testing per release is inexpensive compared with a duplicated authorisation or a missed application deadline. Users will press Back. The only question is whether the service has decided what that means.