A silent failure became a moment users actually trusted
Retention among users who hit an interruption moved the most — direct evidence the fix addressed the real bottleneck, not a symptom of it.
The app couldn't tell "I meant to leave" from "I lost my test"
A user starts a paid mock test, gets a call, and closes the app. Ten minutes later they reopen it — and there's no sign the test ever existed. Nothing distinguishes an accidental closure from an intentional one, and nothing offers a way back. The product simply moved on, and so, eventually, did the user.
For the user
- Frustration and disappointment — time, effort, and money already spent felt wasted
- No path back to a test they'd already paid for and partly completed
- Disrupted learning progress — mock tests are a self-assessment tool, and a broken one undermines the reason to use it at all
For the business
- Direct revenue exposure — unresolved paid sessions are a natural refund trigger
- Falling engagement — users who hit this once had a real reason to stop trusting the mock test feature specifically
- Compounding churn — a broken re-entry point discourages the next purchase, not just the current one
Where the evidence actually came from
Before designing anything, I wanted to know whether this was a real, sizeable problem or a loud edge case. Four signals, pulled together, said it was real.
Retention and drop-off among users who'd started a mock test, measured against those who hadn't — the clearest quantitative signal that something broke mid-funnel.
Recurring language in support conversations — "lost my test," "app closed," "can't find where I was" — pointing at the same moment from a different angle.
Mapped against Nielsen's usability heuristics: a direct violation of visibility of system status and user control and freedom at the exact point of interruption.
Because mock tests are paid, every unresolved interruption was a plausible refund request — the qualitative complaint and the revenue risk were the same event.
That second number undersells the real problem — see Reading the data honestly below for why.
Why an automatic prompt, specifically, was the right intervention
The obvious fix is "let people continue." The harder question is why a specific mechanism — an automatic prompt at app launch, rather than a settings toggle or a reminder — was the one likely to actually work. Five behavioral principles shaped that call. Click each to expand.
People remember unfinished tasks more vividly than completed ones, and carry a low level of tension until they're resolved (Zeigarnik, 1927). A user who got cut off mid-mock-test was almost certainly still carrying that unfinished feeling when they came back — the product just never gave it anywhere to go.
Losses are felt roughly twice as strongly as equivalent gains (Kahneman & Tversky, 1979). A half-finished, paid mock test represents real invested time and money — losing that progress registers as a loss, not a neutral reset.
Nielsen's usability heuristics favor recognition over recall — don't make people remember information or navigation paths when the system can just show them.
Decision time increases with the number and complexity of choices available (Hick, 1952). At the exact moment of app relaunch, attention is scarce and intent is still forming.
People judge an experience largely by its peak moment and how it ended, not its average (Kahneman). For a paid product, the last remembered moment of a broken test — no continuation, no explanation — disproportionately shapes overall trust, even if everything before it worked fine.
Three ways to solve it — and why one won
I scored each option on how directly it intervened at the actual moment of failure — app relaunch after an interruption — rather than working around it.
Persistent session state
Maintain the mock test's session state even when the app is fully closed, so the test is technically resumable at any time.
Automatic prompt on app launch
Show a popup or bottom card automatically when the user relaunches the app, asking if they want to continue their mock test — with a clear, prominent way to resume.
Push notifications
Send reminders to continue the mock test at predefined intervals or personalized timing, reaching users even when the app isn't open.
The first version, shipped to learn
v1 translated the chosen idea directly: a bottom-sheet prompt on app launch, naming the unfinished test and offering a single clear way back in. It shipped deliberately as a testing build, not a finished answer.
What a short round of usability testing surfaced
I ran v1 past existing learners on the app before treating it as done. Three concrete, fixable problems came back — none of them about whether the idea worked, all of them about whether the execution was clear enough.
The illustration competed with the actual message for attention — it needed to support the prompt, not lead it.
Users wanted more context about the test itself before deciding — what subject, how much was left — not just that "a mock test" existed.
Cancel and Continue read with almost the same visual weight, undermining the one clear action the whole prompt existed to drive.
Same idea, sharpened by what testing found
v2 kept the core mechanism and fixed exactly what testing flagged: clearer, more direct language; the subject and remaining questions surfaced up front; and a Continue button with real visual weight against Cancel.
Drag to compare the two shipped prompts directly.
Retention jumped. Drop-off also went "up." Here's why both are good news
Retention among users who hit an interruption moved from 12% to 72% — the headline result. But the drop-off number moved from 9% to 18%, which looks, at a glance, like it got worse. It didn't — and understanding why matters more than the number itself.
What I'd carry forward, and what I'd do differently
Brainstorming without constraints first — scoring ideas against effort and directness only after the option space was genuinely wide, not narrowed too early by what felt "buildable."
Assuming the reason behind a metric shift instead of asking. The drop-off number looked like a regression at first glance — the honest move was to dig into what it actually measured before writing the story around it.
Run structured, moderated usability sessions before v1 shipped, not after — the three fixes in v2 were all things a pre-launch round could plausibly have caught earlier.
Instrument analytics and event logging before shipping v1, so the "before" baseline is real telemetry rather than a partial picture reconstructed after the fact.
Pair the prompt with persistent session state as a complementary layer, not an alternative — so resumption still works even outside the exact app-launch moment the prompt depends on.
Interested in working together?
I'm always open to discussing product design work, new projects, or opportunities to collaborate.
Send message