After a detour into a subtask, land back in the same slot

What it is

The main flow reaches a slot—shipping address, an attachment, pick a contact—and the person is sent to finish a smaller job. When that job ends they should land in that same slot, with the rest of the main flow still there. Return to place after a subtask is a round-trip on the task graph, not “previous page” popping browser history. System Back may happen to walk it correctly; the place is still a debt the product owes: leave from a slot, re-enter that slot.

Why it happens

In Altmann and Trafton’s memory-for-goals model, an interrupted goal is resumed from cues. The main flow is suspended at the detour; the cues are that slot’s location, neighbouring filled fields, where the page had scrolled. If the subtask ends on its own success page or on home, those cues are not in the viewport, and the person must forage again for “what was I filling.” Working memory stably holds one foreground goal; once the subtask is foreground, the main flow’s cursor has to be held by the interface.

A common product failure is an independent subtask route that navigate('/')s or opens an “added” success page on completion. Browser Back then walks the subtask’s inner steps rather than returning to the slot in one hop; repeated Back may have already torn down the main flow. Restoring place means handing back the main flow’s instance when the subtask closes—same scroll, same focus slot—not remounting a blank form.

Studying it

Insert a mandatory subtask (pick an address, upload a file) in the middle of a long form. After completion, see whether people land on that slot without hunting.

• Independent variables: where the subtask ends (success page / home / original slot), whether the main form stays alive during the subtask.
• Dependent variables: time to the original slot, misuse of system Back through inner subtask steps, verbal “where was I.”
• Methodological note: a one-screen subtask makes the end page and the original place visually close, hiding getting lost. Make the main form long so the slot is off the first screen. Do not score this as “can Back be used”—allow the product’s own Done/Cancel and see whether it hands back that slot. The interruption-recovery lab tradition (Altmann) uses external interruptions; here the product itself launches the interruption, which is ecologically cleaner, but participants will treat the subtask as part of the main task. The brief must say “finish that small job, then continue the form.”

Where it stops holding

If the subtask is simply the next step of the main task (wizard step 2), there is no detour; ending should go forward, not back to place. If the user abandons the main flow inside the subtask (logo to do something else), the debt is cancelled. If the subtask completes in a new window and the original window is still there, place never moved; what is needed is focus returning to the original window, not another navigation.

Applying it

• When a slot launches a subtask, record a return anchor (route + slot + scroll). Both Done and Cancel navigate to that anchor, not to a success page or home.
• Keep the main flow alive or fully restorable during the subtask; the original slot is in view and focused.
• Do not rebind system Back to “return to place” in a way that deletes the subtask’s inner Back. Inner steps still pop their own stack; only closing the subtask hands back the anchor.
• Verify: from a slot more than one screen down, open address picker, complete. The first frame is that form, that slot—not “address added” followed by a hunt. Cancel returns to the same slot with the value unwritten.

Related

• Within the group: G4.06.2 A subtask’s result must be brought back into the main flow · G4.06.3 Nested tasks need an explicit return stack
• Adjacent: G4.01 Back stack and back semantics · G4.04 New window versus in-place navigation · G4.05 Resume from interruption
• Search terms: nested task · return to slot · goal memory