A long flow has to save its progress

What it is

Account opening, tax filing, job applications, and other forms designed to take more than one sitting will be closed, moved across devices, interrupted by meetings. A long flow must save progress: which step was reached, and the values already submitted or recoverable on each step, become a task that can be opened again, rather than living only in this page session. It is not the input draft left when someone casually leaves a short form, and it is not crash recovery from memory. It is the product admitting that this task was always going to be interrupted.

Why it happens

Work in a long flow accumulates by step; interruption probability rises with duration. If progress exists only in this SPA routing memory or in this wizard URL, closing the tab zeroes it. At the step where they must leave, people weigh “if I go now, do I re-fill,” and many abandon. Mid-funnel drop-off is not all regret; a share is lawful interruption with no way to resume. Writing progress to the account (or to a declared local draft when logged out) turns the work from “this open” into “this application.”

The grain of the save is the step, not the keystroke. Each time a step is completed or left, there is a recoverable cursor: current step, steps already passed, fields entered on the current step but not submitted. Saves that wait for “Save draft” often never fire—interruptions are unscheduled. Saving only submitted steps and dropping the half-finished current step makes people believe the whole step is gone and restart it.

Studying it

Use a multi-step task of real duration (at least fifteen minutes, or explicitly across days). Insert close-tab, switch-device, overnight. Compare no save, local only, account-side progress.

• Independent variables: write timing (on leaving a step / explicit button / final submit only), storage location.
• Dependent variables: which step is resumed after interruption, abandonment caused by the interruption, how often already-done steps are re-filled.
• Methodological note: fifteen lab minutes is still short; people will tough it out. Cross-day, or a forced “you must go to another meeting now,” is what exposes lawful interruption. Do not use completion of a short wizard to prove progress need not be saved. Autosave studies on forms measure field-level drafts; here, score separately whether the task cursor still exists.

Where it stops holding

A two- or three-step checkout that takes a few minutes often costs more in leftover incomplete orders than it gains from saved progress; finishing in one sitting is the main path. Legally timed steps (payment confirmation, e-signature) can be saved up to the step before; the confirmation instant should not freeze into a “continue later” draft. On a public computer with no login, account-side progress does not exist and a local draft is a leak; leaving should state that it will not be remembered.

Applying it

• For flows expected to span sessions, write the cursor and the current step’s values to the account (or to an explicit local draft if logged out) each time a step is left. Do not wait for a “Save and leave” button.
• Re-opening the same task should land on the unfinished step, not on step one’s empty form.
• Include the half-finished current step; do not persist only steps that already clicked “Next.”
• Verify: fill halfway through step 3, close the tab, enter with the same account. Land on step 3 with the values still there. Repeat on another device. An in-memory implementation starts at blank step 1—that is a long flow not treated as a cross-session task.

Related

• Within the group: G4.05.2 The resume entrance must be findable · G4.05.3 Saved progress must state how long it remains valid
• Adjacent: H1.08 Draft autosave · H3.09 Crash and offline recovery · G4.07 State persistence and position restoration
• Search terms: save progress · wizard resume · cross-session flow