Implementation worksheet · 6 min read
An Android Onboarding Back-Navigation Test Matrix
Decide what back means at every point in the flow and write it down before implementing: back on step one (leave onboarding, or exit the app), back on a middle step (previous step, with state preserved), back on the final step, back from a modal inside a step (close the modal only, never the step), back during an in-flight network call, back after a deep link jumped into the middle, back with predictive back gestures enabled, and back after process death restored the flow. Test each on both the gesture and the button, because devices differ. The case that costs most is back on step one exiting the app entirely — the user is gone, and on a first session they often do not come back.
Android back is a system affordance that users press reflexively, and an onboarding flow built as a series of screens inherits whatever the navigation stack happens to do. The result is a flow that works when you tap through it forwards and behaves unpredictably the moment anyone navigates backwards — which on Android is constant.
Put it into practice
1. Write the intended behaviour per step before implementing
A short table: step, back destination, state preserved. This is a design decision and it is usually made by accident, inherited from whatever the navigation library does by default. Deciding it in advance takes ten minutes and eliminates most of the matrix below.
2. Handle back on the first step deliberately
The options are leaving onboarding into the app, or exiting the app. Exiting is the default in a lot of implementations and it is almost never what you want during a first session — it turns a reflexive gesture into a lost user. If onboarding is mandatory, a confirm-to-exit prompt is the honest compromise.
3. Preserve state going backwards
A user going back to a step should see what they entered, not a blank form. Nothing signals a careless implementation faster than losing typed input to a back gesture, and it is the one users notice immediately because they have to retype.
4. Scope back to modals and sheets correctly
Back inside a modal closes the modal and nothing else. Getting this wrong dismisses both the modal and the step, which looks like the app skipping a step arbitrarily. Every modal and bottom sheet in the flow needs checking individually — it is the most repeated bug in this list.
5. Define back during an in-flight request
The user taps continue, a request is running, they press back. Either block back with a visible indicator or cancel the request cleanly. What must not happen is navigating back while the response lands and advances the flow underneath them, which produces a UI that appears to move on its own.
6. Test predictive back and deep-link entry
Predictive back changes what the user sees during the gesture and can reveal a screen you did not expect. A deep link landing mid-flow creates a stack with no earlier steps, so back has nowhere to go — decide whether it leaves onboarding or synthesises the earlier steps, and make sure it does not exit the app.
The back-navigation matrix
Copy this structure into your review document and record your observed result for each row.
| Case | Intended behaviour | Gesture | Button |
|---|---|---|---|
| Back on step 1 | leave onboarding, not exit app | ||
| Back on a middle step | previous step, state preserved | ||
| Back on the final step | previous step, not completion | ||
| Back inside a modal | close modal only | ||
| Back inside a bottom sheet | close sheet only | ||
| Back during an in-flight request | blocked or request cancelled | ||
| Back after deep-link entry mid-flow | defined destination, never app exit | ||
| Back after process-death restore | resumes correctly | ||
| Predictive back preview | shows the intended destination | ||
| Back with the keyboard open | dismisses keyboard first |
A failure worth checking
Back on step one exiting the app. It is the navigation stack's default and it converts a reflexive gesture — the most-used control on Android — into an abandoned first session. The user does not experience it as their own mistake; they experience it as the app closing. Whether they return is not something the analytics will explain, because the event looks identical to any other exit.
Common questions
Should onboarding be skippable?
Usually yes, and an explicit skip is far better than users discovering that back exits. A visible skip control gives you a measurable signal about which step loses people; back-to-exit gives you an indistinguishable app close.
Does this apply to iOS?
The swipe-back gesture raises the same state-preservation and modal-scoping questions, but iOS has no back-exits-the-app case, which is the most damaging row here. The matrix is worth running on both; the severity ordering differs.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.