Handoff must carry state

What it is

When duration drives a task off the watch onto the phone, the phone must not merely open the same app’s home screen. It must open the same unfinished job: the few characters already typed, the list item half-scrolled, the two conflicts already ticked, the dictated sentence not yet sent. What continues is task state, not app identity. This entry is only about whether that moment of transfer carries state. It is not about how the watch later shows “sent to the phone,” and not about how the two devices divide labor over the long run.

Why it happens

The watch has already done the working-memory steps: pick an object, form an intent, leave partial input. A device switch replaces the visual field, the input method, and the window structure. If the new device only offers “an entrance to the same kind of feature,” the person must re-find the object and rebuild the intent, writing off the seconds just spent. Working memory cannot fund that rebuild: names, selections, and unsent text would have to be recalled off-screen, and recall is least reliable while walking and talking. Carrying state removes the rebuild, so the switch costs only the motion of taking out the phone, not a cognitive restart. The missing piece—caret, scroll offset, half a draft—reads as a failed handoff, so people tap the watch again.

Studying it

Use an interruption–resumption task: work on the watch to a planned point (n characters in, k-th item selected), force a move to the other device, and measure whether resumption lands on the same object at the same edit position. Contrast “open the app” with “open a stateful deep link.”

Independent variables: kind of state carried (selection / draft / scroll / filters), delay between devices, system-initiated versus user-initiated transfer. Dependent variables: whether resumption is still on the same object, time from unlock to the next useful input, repeated actions, reports of “having to find it again.”

Labs with tiny object sets undercount the cost of a lost selection; the cost shows once fields multiply. Delay matters: if state arrives after the phone is unlocked, people act on home-screen habits and overwrite the late state.

Where it stops holding

One-shot confirms (read, snooze) have no mid-state to carry; opening the matching thread is enough, without replaying the tap. When state includes payment or authentication, the phone must re-verify; a watch-side “confirmed” is not phone-side authorization. If clocks disagree or a device is offline, a draft may not match the latest server version; label it as “as left on the watch” rather than silently overwriting. If the person has already started a different job on the phone, stale watch state should not steal focus.

Applying it

• For each handoff path, list the fields that must travel: object id, draft, caret, selections, filters; missing one means the transfer is incomplete.
• The phone landing screen must be that object in its in-progress state, not the app home or a read-only detail.
• If state may arrive after unlock, freeze controls that would overwrite it until it is ready, or offer a one-step undo after an overwrite.
• Verify by typing a few unguessable characters on the watch, or selecting an item not on the first screen, then handing off. Landing on home, on an object list, or with an empty draft all count as state not carried.

Related

• Within the group: K4.02.1 Tasks that take more than a few seconds do not belong on the wrist · K4.02.2 Long-running tasks should move to the phone
• Adjacent: K4.07 Division of Labor and Handoff with the Phone · K8.01 Task Continuity · K8.02 Multi-device State Sync
• Search terms: task resumption · handoff state · deep link