H8.01.3unsaved changes warningdesignresearch

Leaving with unsaved edits needs a prompt

Aliases: dirty state prompt · leave confirmation · unsaved edits

What it is

While updating a record, edits often sit locally before they become the server’s current value. That gap is unsaved / dirty state. When someone leaves on purpose—back to the list, closing a tab, switching records—the gap is discarded unless the product asks first and offers stay, discard, or save. This is intentional navigation. It is not whether a draft survives a killed process, and not whether edit chrome looks unlike view chrome.

Why it happens

Leaving is cheaper than saving. Back, an edge swipe, a click on another row, all beat hunting for Save. Attention is already on the next job, so the save status is not scanned. If every keystroke is already on disk, a leave prompt is pointless; if save is an explicit act, leave is a shortcut that swallows work. The prompt works by turning navigation into a decision about the gap. Fire it too often—on field blur, preview, opening an attachment—and people learn to hit Leave every time; the prompt is dead when a long draft is actually at risk. With no visible dirty mark, people do not believe they changed anything and dismiss the prompt as a false alarm.

Studying it

Plant a change that must persist, then insert leave chances: back, close, switch record, reload. Compare no prompt, prompt always, prompt only when a gap exists.

Independent variables: presence of a dirty mark, whether the prompt splits save / discard / stay, whether autosave has already cleared the gap. Dependent variables: loss rate after leave, habitual dismiss rate, blocks when nothing had changed.

Lab participants told to “save carefully” lose less. A cleaner probe inserts a more urgent second goal (check another record’s due date) and counts how many walk away dirty. Native beforeunload copy cannot explain consequences; what you measure is annoyance, not decision quality.

Where it stops holding

A document that syncs on every keystroke should show a brief saved state, not another gate. Edits reverted to the original must clear dirty, or the prompt lies. Read-only view has no gap; back must not dialog. Quitting the app and switching records inside it are different costs: the former is worth a prompt; the latter, if a draft already exists, is better served by “draft saved” than by a block. In co-editing, the prompt covers one’s uncommitted buffer, not someone else’s already-written version—that is conflict, not dirtiness.

Applying it

  • Intercept leave only when local and saved versions differ. Offer three paths: save and leave, discard, stay. Do not ship OK / Cancel alone.
  • Echo the loss scope in the intercept (title, count of unsaved blocks). A bare “you have unsaved changes” is not a decision aid.
  • After autosave clears the gap, leave without a dialog. If save failed, the copy becomes “not saved yet,” not a fake choice.
  • Verify: change text, hit back, confirm a three-way choice that names the scope. Revert the text and go back—no intercept. After a successful autosave, leave again and confirm silence.

Related

  • Within the group: H8.01.1 CRUD actions need a stable place · H8.01.2 Editing and viewing a record must not share an ambiguous state
  • Adjacent: H1.08 Draft Autosave · H8.09 Edit Mode vs View Mode · H3.04 Undo over Confirm
  • Search terms: unsaved changes · dirty state · leave confirmation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H8.01.3