H8.05.2collection return pathdesignresearch

Saved items need a findable return path

Aliases: saved folder · reading list entry · bookmarks home

What it is

Pinning is only half the job. Save-for-later pays off at return: later, people walk into that list from a stable entry, recognize the item they pinned, and open it. The entry lives in a stable product slot (nav, profile menu, reading list) and its name matches the star they tapped. This is not whether the star was reachable while browsing, and not how a thousand-item list is classified—without a return path, classification has no object.

Why it happens

Save-for-later pushes the current goal into external memory. That memory has to be retrieved with the same cue: the act was Save, the return entry is Bookmarks, Liked, Later, My content—the cue breaks. People search for a title they did not memorize, or assume the pin failed and pin again. If the only path is a toast at success time, the path dies when the toast dies. Across devices the entry must point at the same list, or a phone pin is invisible on the desktop. If the list defaults to “recently opened” rather than “recently pinned,” a fresh pin is buried under old reads and looks lost.

Studying it

In phase one, people pin several items. After a gap (later in the session, or the next day) they retrieve a named one, with no hint of the entry’s name.

Independent variables: a nav entry that matches the act’s name, toast-only guidance after pin, default sort, cross-device sync. Dependent variables: retrieval success, path used (entry / search / re-browse the source), repeat-saves from thinking the pin failed.

A lab gap that is too short leaves the toast in memory. Overnight, or after an unrelated task, is closer to “later.” Finding the title via search does not count as a successful return entry—that is search, evidence the saved entry was unused.

Where it stops holding

A public Like is a stance, not save-for-later; the return path can be a public profile list, not a private reading list. OS reading lists and in-app saves are two memories; the entry must say which, or people pin in A and look in B. After the author deletes the object, the return path should still list a dead pin, not pretend it was never saved. Without an account, return exists only on this device; that is expected, but the entry should say so.

Applying it

  • Put a stable nav entry whose name matches the act (Save leads to Saved). Success feedback may offer “view list” once; the list must not depend on that toast to be reachable.
  • Default sort is recently saved; opened or read items must not push a new pin off the first screen. Offer an Unread / Unprocessed filter.
  • The same entry on every device shows the same list. If sync is pending, say so; do not show empty.
  • Verify: after a gap, ask people to retrieve a named item. Note whether they enter the slot that matches the star. Searching, re-browsing the original channel, or tapping the star again means the return path was not clear.

Related

  • Within the group: H8.05.1 Save-for-later must be reachable while browsing · H8.05.3 Large collections need organization tools
  • Adjacent: H8.13 Content Search and Location · H8.14 Content Lifecycle and Archiving · G4.03 State Persistence
  • Search terms: reading list · saved items · return path

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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