Mobile app development / DIJION
Keeping user input safe: drafts and return flows
A form design guide separating drafts, server saves and submissions across interruptions, account changes and retries.
Completing a form takes effort. A phone call, an expired session or an accidental Back action can erase that effort. Saving every field forever is not an adequate response. First decide what people expect to recover, what should never remain on the device and what evidence makes the operation complete.
Separate three kinds of saved state
Text on screen, a device draft and a server-confirmed record are different states. In an illustrative feedback form, entering a message does not mean that a persistent draft exists or that delivery succeeded. Make the saved indicator reflect the actual storage result.
Scroll the table horizontally to see all columns.
| State | Accurate message | Next step |
|---|---|---|
| Screen only | Not saved yet | Explain the loss before leaving |
| Local draft | Draft saved on this device | Offer recovery on return |
| Server acknowledged | Message sent | Prevent duplicate submission |
Define the draft boundary
A draft key based only on the screen name can mix content from different accounts. Separate the account and record contexts, and decide what sign-out does to the draft. Keep secrets such as passwords outside automatic draft storage. Retention, deletion and reopening behavior belong in the same decision.
Android’s state-saving documentation distinguishes temporary UI state from persistent data. The distinction also helps design: preserving a selection during rotation and recovering a document after closing the app are different promises. Specify which promise applies before choosing storage.
Explain recovery instead of silently overwriting
When an older draft exists, do not silently replace a newer record. Explain that an unfinished draft is available on this device and offer Continue and Delete. If the server record changed, identify which version is being opened. A timestamp alone does not resolve conflicting edits.
A retry may repeat an operation that already happened
After a timeout, the server may already have completed the operation. Preserve the message, but do not let retry create a duplicate. Where the server supports it, use an operation identifier to check the result or distinguish repeated attempts. Without that support, avoid claiming definite success or failure.
Acceptance checks
- Enter data, switch to another app and return.
- Disconnect during submission; check that input survives and the uncertain result is explained.
- Switch accounts; the previous account’s draft must not appear in the new account.
- Delete the draft and reopen the app; deleted content must not reappear.
The useful handoff is a field-level storage boundary and an expected outcome for each interruption. This turns “do not lose input” into a behavior that engineering can implement and quality checks can verify.