Frequent interruptions mean a task must be pausable

What it is

The transfer amount is filled in when the verification SMS arrives; a call cuts into an edit; seats are chosen when the system backgrounds the app. An interruption severs work in progress; the person comes back later. On a phone this is normal: calls, alerts, someone speaking, a ticket gate all steal the foreground. The design question is whether the cut can be joined—whether drafts, steps, and scroll position survive, or the path must be walked from screen one. This entry is only about resumability. It is not about someone who only budgeted tens of seconds, and not about whether walking and talking leave enough attention to read.

Why it happens

The phone is rarely the only activity. It sits inside talk, walking, and other apps, so an external event can take the foreground. Goals in working memory decay fast: people remember “I was buying a ticket” without remembering which service or which field held the promo code. Resumption lag is the time to reload those goals; if the interface has cleared the intermediate state, lag becomes a full redo. Persistence externalizes the goal: the unsent form on disk, the wizard step, the list item. That is not the same fact as a short session. Someone can intend a long task and still be cut; someone in a short window can be cut too. The issue is not how long the window was. It is whether state at the cut was caught. A call is forced by the system; ducking out to read a message is voluntary. When the process is reclaimed they look the same: a relaunch that lands on an empty home screen has broken the task.

Studying it

Use an interruption–resumption paradigm: insert a forced break at a known step (incoming call, lock, jump to another app) and then let the person continue. Diaries capture the source of natural interruptions and what happened after return.

Independent variables: step at which the break lands, duration of the break, whether state was written to durable storage, whether return lands at the leave point. Dependent variables: resumption lag, step errors after return, abandon-after-break rate, whether work restarts from step one.

Lab interruptions are scheduled by the experimenter; in the interface they are calls and notifications at uncontrolled moments, so ecological validity does not transfer. Final completion rate mixes “redone after a break” with “never cut”; code “continued from the cut” separately. Do not treat a process kill as a voluntary abandon.

Where it stops holding

Single-tap actions (torch, one QR scan) finish before a break arrives; there is no intermediate state to restore. A paused stream is player state, not wizard resumability. Some interruptions are the task: the app was opened to take the call. Navigation apps kept alive in the foreground shift the problem to whether location is still right on return. In a live multi-person thread, what must come back is the local draft versus what the other party already said—those are different recoveries.

Applying it

• Write uncommitted state at steps that can lose the foreground: amount in progress, chosen seats, wizard index—not memory only.
• Relaunch onto the screen that was left, not home. If the state has expired (seat gone, code stale), say why and offer the nearest continuable point.
• Do not block a system interruption with “leave without saving?”—a call will not wait on a dialog. Make save the default, not a last-second choice.
• Verify by placing a call or killing the process after the amount is filled and before the code is submitted, then reopen. Check that the number, caret, and step remain. Any path back to a blank form is a cut that was not caught.

Related

• Within the group: K1.01.1 Mobile use comes in short, fragmented bursts · K1.01.3 Attention is split by the environment; focused use cannot be assumed
• Adjacent: K1.08 App Switching and Background Reclamation · A5.08 Interruption Cost and Task Resumption · G4.06 Task Chains and Recovery
• Search terms: resumption lag · task interruption · state persistence