Unsaved changes UX: make leaving an editor a clear decision

Name the work that will be lost

GenPix asks Discard your changes? and explains that recent unsaved edits will be lost. Yuna asks about discarding a video creation and offers Cancel and Discard. The distinction between changes and a creation matters because the user may interpret the second as losing the whole new project rather than only the current buffer.

Write the message around the actual stored state. If a saved version remains, say that the unsaved changes will be lost. If no project exists yet, explain that the current creation will not be retained. Avoid All work will be lost when an autosaved version is available, and avoid Changes will be lost when the action actually removes the only copy.

Do not use a warning as a substitute for correct state tracking. Only show it when leaving creates a meaningful loss. An unchanged editor should exit normally. If a field was changed and then restored to its original value, decide whether the buffer is still meaningfully dirty. Excess warnings teach people to dismiss the dialog before reading the consequence.

Put the action in the button label

Behance offers Discard and Keep Editing in its project warning. Filto pairs Discard changes? with copy that all edits will be lost and buttons Cancel and Discard. Keep Editing is particularly direct because it tells the user what the safe return does, while Cancel depends more on the surrounding question.

Prefer Discard changes to a bare destructive icon, and Keep editing when the alternative returns to the editor. Keep the labels short enough to read but specific enough to act on. Color can support destructive intent, yet it does not explain whether the original asset, project or recent adjustments are affected.

Make the safe route a real return to the same editor state. Restore the cursor, selected object and scroll position where relevant. Do not close the warning and then navigate away anyway. If the user opened the dialog through a back gesture, cancelling the gesture should leave the editing task intact rather than partially applying navigation.

Avoid confirmation questions that reverse the meaning of Yes

Photo Editor asks whether current edits should be left unsaved and labels the destructive action Discard Edits. Mojo asks Go back without saving? but uses Confirm and Cancel. The latter requires the person to read the question to understand what Confirm will do.

A question phrased in the negative makes generic affirmative buttons especially risky. Yes to leave without saving and Yes to save before leaving are opposite outcomes. Keep the action label stable even when the message wording changes: Discard changes, Save draft or Keep editing should remain interpretable on their own.

Avoid combining several choices into one ambiguous sentence. Do you want to save or leave? cannot be answered by Yes and No. Use a title that identifies unsaved work, a concise consequence and separate action labels. Localized copy should preserve those meanings even if the sentence order differs, and buttons need room for longer translations.

Offer Save draft when the work can be retained privately

HeyGen exposes Save Draft, Discard and Cancel in its Unsaved Changes dialog. Captions offers Save, Discard Changes and Cancel while an Export action remains visible in the editor behind it. These three-choice patterns preserve a middle path between losing work and continuing the editing session.

Use Save draft only when the result is genuinely a draft. Name where it can be found afterward, particularly for a first-time project. If Save stores a project but does not export a file, keep that distinct from Export. The warning should not unexpectedly start rendering or publishing just because the person wanted to leave the editor safely.

Treat save as an operation that can fail. Keep the editor and its buffer alive until storage confirms success. If saving fails, return to the warning or editor with retry and Keep editing available. A spinner followed by navigation is not sufficient if the save result is unknown. Do not discard the only in-memory copy while waiting for the response.

Say when saving makes changes public

Crea asks whether to save a template in drafts and offers Save as Draft, Discard and Cancel. Linktree states that saved changes will appear on the user’s Linktree and offers Save changes, Discard changes and Keep editing. This is a significant difference: one preserves private work, while the other describes a public update.

Do not let Save become an accidental publication step. If an action changes a public page, name that consequence in the message and button when needed. If the product supports draft review, keep Save draft and Publish separate. A user leaving an editor should not have to choose between losing work and making unfinished content visible to others.

Maintain separate draft and published versions when the workflow requires approval. A saved draft can remain reviewable without altering the live version. Confirmation should identify which version was stored or updated. If another editor has published changes since the draft opened, detect the conflict and provide a deliberate resolution rather than overwriting live content from an old buffer.

Route every exit through the same preservation policy

Define clean, edited, saving, saved, failed and conflict states. Keep a stable draft identity and compare the current buffer with its last confirmed saved version. The warning should use that state, not a guess based on whether the screen has been open for a while. Autosave, if implemented, needs a confirmed timestamp or version rather than a permanently reassuring Saved label.

Use the same policy for the back button, close control, platform navigation and any supported gesture dismissal. Do not let an outside tap choose a destructive action. Backgrounding the app is not deliberate discard; preserve work locally or through an appropriate draft mechanism where feasible. A dialog cannot protect a buffer after the process has already been terminated.

Make the dialog accessible: identify its purpose, move focus into it and return focus correctly after Keep editing. Destructive choice should require an explicit action. If buttons wrap with large text, retain their order and readable labels. Avoid a timed dismissal or default destructive selection that pressures users into deciding before they understand the consequence.

Test the save failure before the discard success

Edit a project, leave through several navigation routes and choose Keep editing each time. Verify the exact buffer remains. Then choose Save draft while storage is unavailable and confirm that the work is still recoverable. These tests matter more than a screenshot of the ideal saved state.

Measure lost-work reports, failed saves, restored drafts and repeated warnings on unchanged buffers. Do not optimize solely for fewer dialog appearances if it increases accidental loss. Likewise, frequent Keep editing selections can indicate that users changed their minds rather than that the warning is defective. Investigate intent and state together.

Test a new project, an existing saved project, an autosaved edit and a public update separately. Include another editor’s conflicting change when collaboration exists. Confirm that each warning names the correct scope and that saving does not publish unexpectedly. A reliable exit makes preserving work easy while keeping destructive and public consequences explicit.

Check every route out of the editor

Use these checks on a working build, not only on the polished reference state.

• ✓Does the warning identify recent changes versus an entire new project?
• ✓Can every button be understood without answering a negative question?
• ✓Does Keep editing restore the exact buffer and navigation context?
• ✓Are draft save, file export and public publication distinct actions?
• ✓Does a failed save retain the only copy and offer a recovery route?
• ✓Do gestures and backgrounding avoid implicit destructive choices?
• ✓Are stale drafts and conflicting saves handled before any overwrite?

Connect safe exit to export and recovery

Compare mobile sharing and export screens to distinguish storing project work from creating or sending an output file.

The mobile error-state examples help specify a save failure that preserves input and offers a next action.

The account-deletion flow review addresses a different destructive task. Do not copy its account-level consequences into a warning about recent edits.