AI app guides
Protect unfinished work in an app without pretending every draft is saved
Define when drafts persist, how users recognize saved state and what happens when two sessions edit the same work.
Zocri · 2 min read · Sources checked
Choose what a draft promises
MDN warns that the browser's beforeunload event is not reliably fired, especially in some mobile situations. A leave-page warning is therefore only one possible aid, not a complete saving strategy. For a long project brief, decide whether unfinished work should survive a refresh, a closed browser or a move to another device. Each promise requires its own evidence.
State whether drafts belong to a signed-in person, a particular browser or a shared team. A customer may assume that saved means available after signing in elsewhere. If the draft is only local, make that limitation understandable before they rely on it for important work.
Show state at meaningful moments
Use clear states such as saving, saved and could not save. Do not display saved merely because the person stopped typing. The message should correspond to the actual saving mechanism and should change if a later attempt fails. Include a useful retry or recovery action.
Decide whether attachments follow the same draft behavior as text. A saved description with a failed upload is a partial result. Show the remaining work so the user can return with confidence. Avoid making the presence of a filename look like proof that the attachment has been preserved.
Handle competing edits
Consider a person opening the same draft in two sessions or two teammates editing one shared brief. Decide whether the app detects an older version and asks for review, or supports another explicit collaboration model. Silent overwrites are especially confusing when both screens claim their work was saved.
Separate a draft from a submitted record. Once submitted, the business may need a stable version for review. If later edits are allowed, decide whether they create a revision or update the active request. The owner should know which version they are acting on.
Test ordinary interruptions
Enter a distinctive draft, wait for the saved state and refresh. Return through another session if cross-device saving is promised. Repeat with an interrupted connection, an attachment in progress and two open copies. Inspect the recovered content instead of relying on the status label alone.
Document the supported recovery boundaries in the product's help or operating notes. Give users a clear route when the app cannot recover an unsaved change. A useful draft feature protects effort through an explicit, tested saving model, while its language makes the remaining limits visible rather than offering false reassurance.