User Experiences

• 1: Bulk Import from a Prior Provider
• 2: Delete Content and Leave
• 3: Join as an Invited User
• 4: Receive Shared Content
• 5: Share Content
• 6: Upload Content
• 7: View and Organize Content

1 - Bulk Import from a Prior Provider

One-line definition: A user moving off a commercial cloud provider brings their entire existing library — with its dates and organization intact — into their own storage in one go, so they can trust this as their new home and stop paying the old provider.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is a recently-provisioned user — one of the parent capability’s Primary actors — who is mid-migration off a commercial cloud provider. They have already joined (see Join as an Invited User) and understand the deal; now they want to move their history, not just their new captures.

• Role: A user with a large, years-deep library sitting on a commercial provider (e.g. Google Photos, iCloud Photos, a Nextcloud instance they are leaving). They are not a data engineer; they think “my whole photo library,” not “an export archive with sidecar metadata.”
• Context they come from: They have decided — or are close to deciding — to stop paying the commercial provider. The one thing standing between them and cancelling is their existing content. This is explicitly a one-time migration, distinct from the routine ongoing capture in Upload Content.
• What they care about here: Getting everything over — with the capture dates and albums it already has — and being confident nothing was silently dropped before they pull the trigger on cancelling the old subscription. The fear underneath the whole journey is “what if I cancel and then discover a year of photos never made it?”

Goal

“I want my whole existing photo library — years of it, with the dates and albums it already has — brought over in one move, and I want to be confident nothing got dropped before I cancel my old provider.”

Entry Point

The user has decided to leave their prior provider and comes to this system to move their history across. Concretely, they arrive having obtained (or being about to obtain) an export/takeout archive from the prior provider — produced by that provider’s own export process, which this system does not control. Their state of mind is a mix of relief (finally leaving the vendor) and low-grade anxiety (this is their life’s photos; a botched move is not acceptable).

They may arrive before enabling routine device backup, or after — the two are independent. This journey is specifically about the back-catalog, not the go-forward stream.

Journey

1. Obtain the takeout from the prior provider. The user runs the prior provider’s export and ends up with an archive of their library. What that archive contains and how faithful its metadata is are entirely the prior provider’s doing — the user (and this system) inherit whatever the vendor chose to include.
2. Hand the archive to this system for import. The user gives the archive to the system and asks it to bring the library in. From here the user’s job is mostly to wait and, at the end, to verify. This is a fully self-service action: the user does not need the operator to run, stage, or babysit their import, and the operator is not a step in the routine path. That posture is deliberate — an operator-assisted import would turn every migration into bespoke operator labor, which the neighboring platform capability’s operator-maintenance-budget KPI explicitly guards against (migrations must not become one-off projects). If a user genuinely cannot complete an import self-service, that is treated as a product gap to close, not as routine operator work. The system accepts takeout from an explicitly named, deliberately small set of supported providers — the ones the operator’s closed circle actually leaves (e.g. Google Photos Takeout, an Apple/iCloud Photos export) — rather than promising to swallow any arbitrary archive. For each supported source it publishes an honest, per-source fidelity contract: what it can promise about capture dates and album/grouping survival from that specific provider’s export, because providers differ wildly (one splits metadata into JSON sidecars, another flattens album structure). A source the system does not support is refused plainly up front — “this provider isn’t supported” — rather than best-effort imported into a silently degraded library, because a generic guess would violate the honest-expectations principle this whole journey rests on. The supported-source list grows by operator decision as the circle’s needs demand, matching the capability’s closed, small user set.
3. The import runs — potentially for a long time. Years of media is a lot. The user perceives that it is working and gets a legible sense of how far along it is and roughly how much remains, so a long-running import reads as “progressing,” not “hung.”
4. Content lands, dated and organized. As the import completes, items appear in the user’s library carrying their capture dates and — as far as the takeout preserves it — their existing organization (albums/groupings). The user’s history slots into place as history, not as an undated dump. Items whose takeout carried no reliable capture date are not dropped, hidden, or stamped with an invented date; they land in an explicit, first-class “undated” state the user can later resolve — assigning the right date or album by hand — rather than sitting under a permanent, un-actionable flag. These items are fully stored, private, and durable from the moment they land; only their metadata is pending, so Zero data loss never waits on a date being figured out. The actual correction happens over in View and Organize Content; this journey’s job is to surface the undated set honestly and make it fixable, not to guess.
5. Verify completeness. Before doing anything irreversible, the user gains genuine confidence that the import is complete — that what was in the old library is now in the new one. This is the pivotal step: the whole journey’s value hinges on the user being able to trust the import, not just be told it finished. Concretely, completeness is presented as a reconciliation against the archive the user actually handed over, layered so a non-technical user can trust the headline and still drill in when they want to: (a) a top-line count reconciliation — “of the N items in your archive, M imported” — as the at-a-glance trust anchor; (b) an explicit, itemized exceptions list of everything that could not be imported and why (unsupported item types, corrupt files, items with no usable metadata), so “couldn’t import” is never silent; and (c) where the source preserved albums, a per-album check so the user can confirm the groupings they care about came across intact rather than trusting a single aggregate number. The reconciliation is deliberately scoped to the archive the user handed over — not “everything you ever had” — and it says so plainly, so the user cannot mistake “imported everything in this takeout” for “imported everything that ever existed” when the vendor’s export was itself short (see Edge Cases).
6. Cancel the prior provider. Only after that verification does the user cancel the commercial subscription. This ordering is the point at which the capability’s Longevity and cost-avoidance outcomes actually land — the user has stopped depending on the vendor and stopped paying them, without a gap.

Flow Diagram

flowchart TD
    Decide([User decides to leave prior provider]) --> Takeout[Obtain takeout/export<br/>from prior provider]
    Takeout --> Hand[Hand archive to this system<br/>for import]
    Hand --> Run[Import runs — possibly long;<br/>progress is legible]
    Run --> Interrupt{Interrupted or<br/>partially failed?}
    Interrupt -->|Yes| Resume[Resume / re-run<br/>without mangling or duplicating]
    Resume --> Run
    Interrupt -->|No| Land[Content lands with capture dates<br/>& existing organization]
    Land --> Verify{User confident<br/>import is complete?}
    Verify -->|Not yet| Investigate[Investigate the gap<br/>before cancelling anything]
    Investigate --> Verify
    Verify -->|Yes| Cancel[Cancel prior provider]
    Cancel --> Home((History now lives in private storage —<br/>Longevity & cost-avoidance realized))

Success

A successful bulk import leaves the user with:

• Their whole history in their own private storage — dated and organized closely enough to what they had that it feels like the same library, moved, not a pile of loose files.
• Enough confidence to cancel the commercial provider. The emotional core of success is the moment they cancel without dread — because they verified completeness rather than hoping.
• The capability’s outcomes made real. This is the journey where Longevity (no longer depending on a vendor’s roadmap or pricing) and cost avoidance (stop paying per-GB) stop being promises and become facts for this user.
• A private result. Everything imported is visible only to them; the operator cannot see it (see Constraints Inherited — Private by default).

Edge Cases & Failure Modes

• Import is interrupted or partially fails. Experience-level handling: the import can be resumed or safely re-run without producing a mangled half-library or a doubled one. The user is never left unsure whether they now have some, all, or one-and-a-half copies of their history.
• The takeout has missing or degraded metadata. Some providers strip or flatten capture dates, or scatter album structure across sidecar files. Where the archive lacks a capture date, the system must set honest expectations — it surfaces that those items arrived without reliable dates rather than inventing plausible-but-wrong ones. The user would rather know “these 40 items have no date” than silently get 40 wrong dates. Those items land in the fixable “undated” state described in Journey step 4 — visible, resolvable by the user later, and never blocking the rest of the import.
• Overlap with content already added. If some items were already brought in via Upload Content or an earlier partial import, the user must not end up with a doubled library. Re-importing the same takeout is safe.
• A very large archive takes a long time. The user can walk away and come back; the import does not demand babysitting, and its progress remains legible across sessions so the user can check in.
• Gaining genuine confidence the import is complete — the crux. Premature trust is the dangerous failure here: the user believes the import is done, cancels the old provider, and only later discovers a silent gap that is now permanent (a Zero data loss failure). So the experience must give the user a real basis for the completeness judgment — a way to see that the count/scope of what came in matches what they had — not just a green “import finished” that hides omissions.
• The prior provider’s export itself is incomplete. If the vendor’s takeout was missing content to begin with, no import can conjure it. This is outside the system’s control, but the experience should not let the user mistake “imported everything in the archive” for “imported everything you ever had” if those differ — the verification should be about the archive the user actually handed over, and the user should understand that boundary.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• No storage quotas. A user’s entire multi-year library must fit — there is no per-user cap, and the user never has to prune to make room. Capacity planning is the operator’s concern. Without this rule, bulk import would be self-defeating.
• Private by default. Everything imported is private to the user. No third party — including the operator — can see the imported library. Import is not a sharing action.
• Off-site backup is allowed. Imported content benefits from the same durability guarantees as any other content, including any off-site replication, provided privacy is preserved. Invisible to the user, but part of why “it’s safe now” is true.
• Lost credentials = lost data. Once the user cancels the prior provider, this system holds the only live copy of their history, concentrated behind a single account whose credentials only they hold — so the same trade-off that protects that history (no operator backdoor) is now the one they carry: losing their credentials means losing the imported library, unrecoverably. That makes the unrecoverable-credentials trade-off (covered in depth by Join as an Invited User) especially consequential here, and raises the stakes on the habit of pulling proactive exports (see View and Organize Content); the import is the moment those habits stop being abstract.
• KPI — Zero data loss. This journey has an unusually sharp relationship to the KPI, because the user takes an irreversible external action (cancelling the prior provider) based on the import’s completeness. A silent drop that would be a minor annoyance elsewhere becomes permanent loss here. The verification step exists specifically to protect this KPI.
• Purpose priority — Longevity and cost avoidance. Bulk import is the concrete moment the capability delivers its Longevity outcome (independence from a vendor) and its secondary cost-avoidance outcome (ending the subscription). The journey is designed so the user only realizes these once the content is safely across — Longevity is never traded for the convenience of cancelling early.
• KPI — Number of active users. A successful import is a strong signal of a genuinely adopted user — someone who moved their real history in, not just an idle provisioned account. It also front-loads a large amount of content that the user will then view, organize, and share, feeding sustained activity.

Out of Scope

• Routine, ongoing capture. Everyday uploads and automatic device backup — the go-forward stream — are Upload Content. This doc is strictly the one-time back-catalog move.
• The prior provider’s own export process. How the user generates the takeout on Google Photos / iCloud / etc. is the vendor’s flow, not this system’s. This journey begins when the user has an archive in hand.
• Verifying, browsing, and re-organizing the landed library in depth. Confirming completeness is part of this journey, but living in the library afterward — searching, making new albums, pulling a full export — is View and Organize Content.
• Sharing the imported content. Making any of it visible to others is Share Content.
• Leaving this system and taking data back out. The reverse move — exporting from here on departure — is covered by View and Organize Content (on-demand export) and Delete Content and Leave (departure).

Open Questions

None remaining. The four questions this journey previously carried have been resolved and folded into the sections above:

• Accepted takeout formats & per-source metadata fidelity → the system accepts an explicitly named, deliberately small set of supported providers (the ones the operator’s closed circle actually leaves) and publishes an honest per-source fidelity contract for date/album survival, rather than promising to swallow any arbitrary archive; unsupported sources are refused plainly instead of silently degraded (Journey, step 2).
• How completeness verification is presented → a reconciliation against the archive the user handed over, layered as a top-line count reconciliation, an itemized exceptions list of what couldn’t be imported and why, and a per-album check where the source preserved albums — scoped explicitly to the handed-over archive, not “everything you ever had” (Journey, step 5).
• Self-service vs. operator-assisted → fully self-service; the operator is not a step in the routine import path, because an operator-assisted import would make every migration bespoke labor the platform capability’s operator-maintenance-budget KPI guards against. An import a user genuinely cannot complete alone is treated as a product gap to close, not routine operator work (Journey, step 2).
• Handling items without reliable metadata → they land in an explicit, first-class, fixable “undated” state the user can resolve later (never an invented date, never a permanent un-actionable flag), while remaining fully stored, private, and durable in the meantime (Journey, step 4 and Edge Cases).

2 - Delete Content and Leave

One-line definition: A user removes content they no longer want — with a 30-day safety net — and, if they ever choose, leaves the system entirely, exporting first because after the retention window their data is gone for good.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is a user managing or removing their own footprint — a Primary actor from the parent capability’s Stakeholders — acting anywhere on the spectrum from deleting a single unwanted photo to departing the system entirely.

• Role: An everyday user exercising control over their own content: getting rid of what they don’t want, and — at the far end — deciding to leave altogether. Non-technical is the default assumption; they think “delete this,” “I’m done with this service,” not “issue a purge.”
• Context they come from: Small deletions come up constantly (a bad shot, a duplicate, something embarrassing). Departure is rare and weighty — a decision to leave the circle, or simply to stop using the system. Both are moments where the user wants to feel in control and safe from their own mistakes.
• What they care about here: Removing what they mean to remove, not losing something by accident, and — if they leave — taking their archive with them and understanding, honestly, that the system’s copy will be gone afterward.

Goal

“I want to get rid of stuff I don’t want — but not lose something by accident — and if I ever decide to leave, I want to take my archive with me and know my data is truly gone afterward.”

Entry Point

Two related entries, distinguished by scope and weight:

• Delete specific content. The user is in their library (View and Organize Content) and decides one or more items should go.
• Leave the system entirely. The user decides they are done — or the operator is removing them under the Closed user set rule (e.g. a credible No illegal content violation, or simply parting ways). This is a deliberate, infrequent, high-stakes act.

Journey

Branch A — Delete specific content

1. Select and delete. The user picks the content and deletes it. It disappears from their main library view immediately, so the library reflects their intent right away.
2. Safety net — a private “Recently Deleted” surface, 30 days. Deleted content moves into a “Recently Deleted” surface the user can open at any time within the window. It is self-service and visible to the user alone (never to the operator — Private by default), it shows each item with the time remaining before purge, and the user can restore any item back into their library themselves, with no operator involvement. This is the safety net made usable: recovery is a thing the user does, on their own, not a favor they request.
3. Permanent purge. After 30 days, the content leaves “Recently Deleted” and is permanently purged — genuinely gone, with no operator recovery path. The window exists for accident recovery, not indefinite retention.

Branch B — Leave the system entirely

1. Decide to leave (or be removed). The user initiates departure, or the operator removes them (only the operator can add or remove users). A voluntary departure follows the gated, reversible flow below; an operator termination for a credible No illegal content violation is handled differently — see step 5 and Edge Cases.
2. Export first — gated, not merely offered. Before a voluntary departure completes, the user must pass through an explicit “export first” step that plainly states the stakes: the system’s copy ends after 30 days, and an export is their only lasting copy (see View and Organize Content). The experience gates departure behind an informed acknowledgment — the user cannot leave by accident or without being told, and export is offered right there. The system does not, however, force the download to actually happen (it cannot verify the user kept the file); the acknowledgment ensures the choice is informed and deliberate, and the 30-day window backstops a rushed exit. This step is available only while the system is healthy (Operator succession).
3. Access ends. The user’s access to the system is closed.
4. Retention — 30 days, reversible via the operator. Their data is retained for 30 days. Because it still exists and has not purged, a departure is reversible within the window: if the user changes their mind, the operator re-provisions them (Closed user set — only the operator can re-add a user) and the retained data reconnects to the restored account. Departure starts the purge clock; it does not, by itself, sever the data. This reversal is operator-mediated and whole-account — deliberately unlike the self-service, per-item “Recently Deleted” restore of Branch A.
5. Purge. After 30 days, their data is purged. From that point it is gone irreversibly — the same finality as Lost credentials = lost data — and re-provisioning after purge is a fresh start, not a recovery. If they kept no export and the window has passed, only what they previously pulled survives.

Flow Diagram

flowchart TD
    Start([User exercises control over their footprint]) --> Scope{Scope?}

    Scope -->|Delete specific content| D1[Select & delete]
    D1 --> D2[Disappears from library view immediately]
    D2 --> D3[Moves to private 'Recently Deleted'<br/>— self-restore, 30 days]
    D3 --> D4{Self-restore within window?}
    D4 -->|Yes| Restored[Content restored by user]
    D4 -->|No| DPurge[Permanently purged after 30 days]

    Scope -->|Leave the system| L0{Voluntary, or operator<br/>termination for violation?}
    L0 -->|Operator termination| LT[Access ends;<br/>no reversal window granted]
    L0 -->|Voluntary| L1[Gated 'export first'<br/>informed acknowledgment]
    L1 --> L2[Export complete archive<br/>— only while system is healthy]
    L2 --> L3[Access ends]
    L3 --> L4[Data retained 30 days<br/>— window against rushed departure]
    L4 --> L5{Change of mind<br/>within window?}
    L5 -->|Yes| Reprov[Operator re-provisions;<br/>retained data reconnects]
    L5 -->|No| LPurge[Data purged — gone irreversibly;<br/>only prior exports survive]
    LT --> LPurge

    DPurge --> Gone((Gone for good))
    LPurge --> Gone

Success

A successful delete-and-leave experience leaves the user with:

• Their intent, realized safely. What they meant to remove is gone from their view immediately, and they were protected from their own mistakes by a real recovery window.
• No accidental loss. The 30-day net means a fat-fingered deletion or a rushed “I’m leaving” is recoverable — the capability’s Zero data loss promise holds even around destructive actions.
• A clean, honest departure (if they leave). They walked away with their archive in hand and a clear understanding that the system’s copy ends after 30 days — no false hope of an indefinite backup, and no nasty surprise.
• Confirmation of control. Deletion and departure both feel like their decision, fully in their hands, with the operator unable to peek at or resurrect content against the privacy posture.

Edge Cases & Failure Modes

• Accidental deletion. Experience-level handling: self-recoverable within the 30-day window from the private “Recently Deleted” surface (Branch A) — the user restores the item themselves, no operator request needed. This window is precisely what keeps intended deletion from ever becoming unintended data loss. (See the KPI note below for why deliberate deletion is not a KPI breach.)
• Two recovery mechanisms, not one. Experience-level handling: recovering an individually deleted item and recovering a whole departed account are deliberately distinct experiences, and the user should never confuse them. Deleted items live in the self-service, per-item “Recently Deleted” surface the user restores from alone; a departed account is brought back only through operator re-provisioning at whole-account granularity. Different scope (item vs. account), different agency (self-service vs. operator-mediated), different weight (casual undo vs. reversing a deliberate exit) — the experience keeps them from blurring so a user tidying their library never feels they are “leaving,” and a user reconsidering departure never expects a one-click item-style undo.
• Change of mind about leaving, within the window. Experience-level handling: a voluntary departure is reversible for the full 30 days, because the user’s data is retained and unpurged the whole time. Reversal runs through the operator (Closed user set — only the operator can re-add a user), and on re-provisioning the retained data reconnects to the restored account; departure starts the purge clock but does not sever the data on its own. The experience is honest about what it does promise: not a self-service, one-click return (re-entry is operator-mediated, a variant of Join as an Invited User), but the real assurance that “your data still exists, and the operator can bring you back to it, until the window closes.” After purge there is nothing to reconnect to, and return is a fresh start.
• Deleting content that was shared. If the user deletes an original they had shared, recipients lose the shared view (cross-reference Share Content and Receive Shared Content), but copies recipients already downloaded remain theirs. The experience is honest that deletion reaches the owner’s copy and the shared views of it, but not copies that already left.
• Operator-initiated removal for illegal content. Experience-level handling: this is treated differently from a voluntary departure — the reversible 30-day safety net does not apply. The retention window exists to protect a user from their own rushed or mistaken exit; it is not a courtesy hold owed to a user terminated on credible evidence of a No illegal content violation, and holding flagged content for 30 days would cut against the very reason for removing it. So a violation termination ends access without granting the user a reversal window, and the operator is free to remove the offending content on its own timeline rather than parking it in retention. The operator still cannot inspect content directly — termination acts on credible external evidence, not inspection — and there is no gated “export first” step for a removal the operator initiates. (A user’s voluntary departure remains fully reversible per the case above; the two paths are deliberately distinct.)
• Waiting too long to export on the way out. The complete export is available only while the system is healthy (Operator succession). A user who defers grabbing their archive until the system is down may find only previously-pulled exports survive. The experience should encourage exporting before leaving, not as a later step.
• Deleting an album vs. deleting content. Emptying or deleting an album is organizing, not deletion of content, and is handled in View and Organize Content. This journey is about deleting the underlying content itself. The two must stay clearly distinct so a user cannot destroy originals while merely tidying.
• Purge is truly irreversible. Once the 30-day window elapses, there is no operator recovery path — by design. The experience must not imply any “call the operator to get it back” escape hatch after purge; that would contradict both Lost credentials = lost data and the privacy posture.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• 30-day retention after deletion / departure. The spine of this entire journey. Deleted content and departed users’ data are retained for 30 days for accident recovery, then purged. Both branches are literal expressions of this rule.
• KPI — Zero data loss (precise reading). The KPI is: no user ever loses content they did not themselves delete. Deliberate deletion, and its permanent purge after the window, are expected behavior — not a KPI failure. The KPI is protected here by the recovery window (against accidents) and by the non-destructive-organizing guarantee elsewhere. The experience should make this distinction real: the user destroys their own content on purpose, with a safety net, and that is the system working as intended.
• Lost credentials = lost data. Departure and post-window purge share the same finality as losing credentials: once gone, gone, with no operator backdoor. This is the deliberate privacy trade-off, applied to the exit.
• Operator succession. The export-before-leaving step is the user-facing use of the capability’s on-demand-export mechanism, including the “only while the system is healthy” caveat. Exports are what preserve the user’s data across their departure.
• Closed user set. Only the operator adds or removes users. A user leaving, or being removed, and any later return, all pass through the operator — there is no self-service account deletion-and-recreation loop that bypasses this.
• Private by default. Throughout deletion, retention, and purge, the operator cannot see the user’s content. Retention is not an operator-readable archive; it is a private safety net that purges itself.
• Off-site backup is allowed. Because durability may rely on off-site replication, a deletion — and the eventual purge after the window — must reach those copies too. From the user’s seat, deleting is a single decision that takes effect everywhere; they should never have to wonder whether a backup somewhere still holds what they removed after the window closes.

Out of Scope

• Organizing (deleting albums, un-grouping). Non-destructive tidying is View and Organize Content, not deletion of content.
• The mechanics of exporting. Pulling the complete archive is described in View and Organize Content; this doc references it as the “export before you leave” step but does not re-specify it.
• Revoking a share without deleting the content. Taking back access while keeping the content is Share Content. This journey covers deletion of the underlying content (which also ends shared views of it).
• Re-onboarding after departure. If a departed user returns, their re-provisioning is a variant of Join as an Invited User, governed by the operator. Within the 30-day window that re-provisioning reconnects the user’s retained data (see Journey Branch B step 4); the mechanics of the join flow itself live in that experience, not here.
• Operator-side capacity reclamation. What the operator does with freed space after a purge is an operational concern, not part of the user’s experience.

Open Questions

None remaining. The five questions this journey previously carried have been resolved and folded into the sections above.

• Can a departed user return within the 30-day window and recover their data, and how? → Yes — departure is reversible for the full window; it starts the purge clock but does not sever the data. Because the data is retained and unpurged, the operator re-provisions the user (Closed user set) and the retained data reconnects to the restored account. Return is operator-mediated (a variant of Join as an Invited User), not one-click self-service; after purge there is nothing to reconnect to (Journey Branch B step 4, Edge Cases).
• Does the 30-day retention window apply to operator-initiated termination for illegal content? → No — a violation termination is handled differently and grants no reversal window. The retention net protects a user from their own mistaken exit; it is not owed to a user removed on credible No illegal content evidence, and the operator may remove offending content on its own timeline rather than hold it. The operator still cannot inspect content directly (Journey Branch B step 1, Edge Cases).
• Is there any distinction between “delete this content” recovery and “I left” recovery? → Yes — they are deliberately distinct. Deleted items are recovered by the user alone, per-item, from the private “Recently Deleted” surface; a departed account is recovered only through operator re-provisioning at whole-account granularity. Different scope, agency, and weight, kept from blurring so the two are never confused (Journey, Edge Cases).
• How is the user reminded to export before leaving, and how strongly? → Departure is gated behind an informed acknowledgment, with export offered right there — stronger than a mere offer, short of forcing the download. A voluntary departure cannot complete without passing an explicit “export first — the system’s copy ends after 30 days, this is your only lasting copy” step; the system cannot verify the file was kept, so the gate ensures the choice is informed and deliberate, with the 30-day window backstopping a rushed exit (Journey Branch B step 2).
• What exactly does a user see during the retention window? → A visible, private “Recently Deleted” surface they self-restore from — not invisible-but-recoverable-on-request. Deleted items appear there for the user alone (never the operator — Private by default), each showing time remaining before purge, and the user restores any item themselves with no operator involvement (Journey Branch A step 2, Edge Cases).

3 - Join as an Invited User

One-line definition: A person the operator has chosen is invited into the closed circle, sets up credentials only they hold, comes to genuinely understand the trade-offs they are accepting (private by default, no quotas, lost credentials = lost data), and ends up with a ready but empty library.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor here is a prospective user — a family member or friend the operator (Carson) has personally decided to invite. They map to the parent capability’s Primary actors, but at the very start of their relationship with the system, before they have stored anything.

• Role: A newly-invited member of the operator’s trusted circle. Assume they are not technical: they think in terms of “my photos” and “my account,” not credentials, keys, or recovery flows.
• Context they come from: They likely already keep their photos on a commercial cloud provider and have a vague unease about privacy, cost, or lock-in — or they simply trust the operator’s recommendation. They did not seek out and sign up for this system; they cannot, because there is no public sign-up. They are here because the operator reached out to them.
• What they care about here: Getting an account that is genuinely theirs, understanding in plain terms what they are agreeing to, and knowing what to do next. Underneath that: they want to feel they have been let into something private and trustworthy — not enrolled in a product that will mine their photos.

The operator is a secondary actor in this journey: they initiate and provision, but a load-bearing property of the whole capability is that the operator drives this onboarding without ever gaining the ability to see the user’s future content.

Goal

“I’ve been invited to this thing Carson runs. I want to get my own account set up, understand what I’m actually agreeing to, and know how to start putting my photos somewhere I trust — somewhere that’s really mine.”

The goal is not merely “an account exists.” It is “an account exists that only I control, and I understood the deal well enough to rely on it.” The understanding is part of the goal, because the capability’s central trade-off (lost credentials = lost data) only works if the user genuinely accepted it rather than clicking past it.

Entry Point

The journey begins out of band, on the operator’s initiative. The operator — in a conversation, a text, an in-person chat — tells the person they are being added and starts provisioning them. There is no invite link the person discovered, no “request access” button they pressed, no waitlist they joined.

This is a direct consequence of the Closed user set rule: the operator is the only person who can add a user, and there is no self-signup. The prospective user’s state of mind is therefore one of having been offered something by someone they trust, not of having shopped for a service. That trust is the currency the rest of the journey spends and must not betray.

Journey

The journey is a mostly-linear flow with one decision point (accept or decline) and a strong emphasis on a single comprehension beat in the middle — the moment the user actually understands the lost-credentials trade-off.

1. The operator invites and begins provisioning

The operator decides this person belongs in the circle and starts setting up their account. From the prospective user’s perspective, this is simply “Carson said he’s adding me.” Nothing is required of them yet.

Because provisioning is entirely operator-driven, the user is never asked to prove eligibility, pick a plan, or agree to terms-of-service boilerplate. The “terms” they will accept are the handful of real trade-offs surfaced in step 4, in plain language — not a legal document.

2. The person receives the invitation

The person perceives an invitation to set up their account — an unmistakable signal that it is their turn to act, arriving through whatever channel the operator uses. What matters at the experience level is that it is clearly for them, clearly from the operator they trust, and clearly time-bound to a setup action they take now.

The invitation is genuinely time-bound: it carries the credential the person uses to establish their account, and a setup credential that stays valid forever is a standing security liability. So an unaccepted invitation expires after a bounded window (on the order of a week — long enough that a real person acting in good faith is not rushed, short enough that a stale setup link does not linger). Expiry is quiet and carries no penalty or stigma: if the person let it lapse, they are still exactly as invited as before. The operator simply re-invites them — the same one-step action as the original invitation, producing a fresh time-bound setup credential. There is no distinct “expired, please retry” flow the user must navigate; from their seat, the invitation just arrives again.

3. Accept or decline

The person decides whether to join.

• Decline. The circle is closed and trust-based; there is no pressure and no consequence. Nothing further is provisioned, and the journey ends here. This is a legitimate outcome, not a failure — a person choosing not to store their photos here is simply not part of the user set.
• Accept. They proceed to establish their credentials.

4. Establish credentials only they hold — and understand what that means

The person sets up the credentials they will use to sign in. The defining property, which they must come to understand, is that only they hold these credentials. The operator does not learn them and cannot reset them into any form that would expose the user’s content.

This is the comprehension beat — the emotional and conceptual center of the whole onboarding. Before the user relies on the system, they are walked, in plain terms, through the deal they are accepting:

• Their content will be private by default. No third party — including the operator who runs the system — can see their photos unless they explicitly share them. This is stated as a promise, not a setting.
• There are no storage limits. They will never be told they are out of space or asked to pay for more. (For someone leaving a commercial provider, this is a pleasant surprise worth naming.)
• They can always get their stuff out. They can pull a complete copy of everything they own, on their own, whenever the system is healthy — and they are encouraged to do so periodically. This is their safety line and their exit.
• If they lose their credentials, their data is gone. This is the hard one. The operator cannot rescue them — not “won’t,” can’t — because the same property that keeps the operator out of their content also keeps the operator from recovering it. This is a deliberate Signal-style trade-off in service of privacy.

The experience-level obligation here is informed consent: the user should leave this step genuinely understanding the no-recovery trade-off and knowing they are responsible for safeguarding their credentials (e.g. keeping them in a password manager). Burying this in fine print would be a failure of the journey, because a user who did not understand it will later experience an unrecoverable loss as a betrayal rather than a known trade-off they accepted.

The confirmation itself is a simple explicit acknowledgement — after the plain-language explanation, the user affirms once that they understand losing their credentials means losing their data. It is deliberately not a quiz, a typed recovery-phrase re-entry, or any other gate: the trusted-circle relationship is the point, and turning onboarding into a bureaucratic checkpoint would betray it. This does place real weight on the explanation rather than the mechanic — the load-bearing consent work is the operator’s plain-language walkthrough and the honest framing above, not the tap that follows it. That is a conscious trade-off in favor of a low-friction, trust-based experience, accepting the residual risk that a determined user can still click past a simple acknowledgement.

5. First sign-in to a ready, empty library

The person signs in for the first time and lands in their own space: private, theirs, and empty. The emptiness is an invitation — the system points them at what to do next.

6. Pointed toward first content

The account is ready, so the journey hands off to the user’s first real use. They are oriented toward the two natural next steps: uploading content (a first photo, or turning on automatic device backup) or bulk-importing their whole existing library from a prior provider. This handoff is where “provisioned” starts becoming “active.”

This handoff is deliberately passive direction rather than active hand-holding: the empty library clearly points at those two next steps, but the system does not march the user through a scripted first upload. Even for a non-technical person, an obvious, plainly-labelled pair of choices respects their autonomy and keeps onboarding from feeling like a wizard that won’t let them out. The trade-off is a higher risk that some users land and stall; that risk is not solved by force here but watched — dormancy is tracked through the Number of active users KPI, and chronic stalling is a signal to revisit this choice rather than a reason to bolt on a mandatory tour.

Flow Diagram

flowchart TD
    Start([Operator decides to invite this person]) --> Provision[Operator begins provisioning<br/>account — no self-signup]
    Provision --> Invite[Person receives invitation to set up]
    Invite --> Decide{Accept?}
    Decide -->|Decline| End[Nothing provisioned.<br/>Journey ends — a legitimate outcome]
    Decide -->|Accept| Creds[Person establishes credentials<br/>only they hold]
    Creds --> Understand[Comprehension beat:<br/>private by default · no quotas ·<br/>can always export · lost credentials = lost data]
    Understand --> FirstLogin[First sign-in →<br/>ready, empty, private library]
    FirstLogin --> NextStep[Oriented toward first content:<br/>upload or bulk-import]
    NextStep --> Active((Poised to become an active user))

Success

A successful onboarding leaves the person with:

• An account only they control. The credentials are theirs alone; the operator provisioned access without acquiring the ability to read their content.
• Genuine understanding of the trade-off. They did not merely click “I agree” — they can state, in their own words, that losing their credentials means losing their data, and that this is the price of nobody (including the operator) being able to snoop. They accepted it knowingly.
• A clear next step. They know how to start — upload a photo, turn on backup, or import their old library — so the empty library is a starting line, not a dead end.

Emotionally, success feels like being let into a trusted, private circle — the opposite of signing up for a product. The person’s trust in the operator has been honored, not spent down.

Edge Cases & Failure Modes

• The person declines the invitation. Handled in the journey: nothing is provisioned, no pressure is applied, and this is recorded simply as “not a user.” The closed, trust-based nature of the circle makes declining unremarkable.
• The invitation lapses before the person acts. A good-faith invitee who got busy and let the setup window pass is not a failure state. The invitation simply expires, and the operator re-invites with the same one-step action, issuing a fresh setup credential. The user experiences a second invitation arriving, not an error to recover from. Distinguishing an innocent lapse from a soft decline is not the flow’s job — either way the remedy is identical and cost-free (re-invite, or don’t).
• The person loses their credentials immediately after setup, before storing anything. The loss is genuinely unrecoverable — but the stakes are near zero because the library is empty. Experience-level handling: treat this as a low-cost teaching moment. The operator can re-provision a fresh account (the operator can always add a user), but this is a new account, not a recovery of the old one — consistent with lost-credentials-equals-lost-data. The value of losing an empty account is that it reinforces the trade-off before anything is at stake.
• The person never uses the account after provisioning. They become a dormant provisioned user, not an active one, per the Number of active users KPI. Experience-level handling: this is not an error state to fix inside the flow, but the journey should end by pointing clearly at a first action, precisely so that provisioned-and-idle is the exception rather than the default. Chronic dormancy is a signal the capability isn’t meeting the person’s real need — it is tracked, not papered over.
• The person doesn’t understand, or is uncomfortable with, the no-recovery deal. This is the most important failure mode to get right. Experience-level handling: the honest response is to make sure they understand before they rely on the system — informed consent is part of onboarding, not fine print. If, having understood it, they are not comfortable with it, that discomfort is legitimate and may mean this system isn’t right for them. The wrong handling would be to soften or hide the trade-off to keep them; that would only convert a clear up-front choice into a future betrayal.
• The operator later removes the person from the circle. Only the operator can do this (closed user set). From the user’s side this is a departure, and it is governed by the same 30-day retention mechanics as leaving voluntarily — see Delete Content and Leave. It is out of scope for the onboarding journey itself.
• Someone tries to join without an operator invite. There is no path for this — there is no front door to knock on. Not an edge case the flow handles so much as a property of the closed user set that this journey depends on.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• Closed user set. The entire entry point is operator-initiated. There is no self-signup, no invite link the user found on their own, no request-access flow. The operator is the sole party who can add a user, and this journey is the operationalization of that rule from the invited person’s seat.
• Lost credentials = lost data. This is the conceptual center of the journey (step 4). The onboarding’s job is not just to create credentials but to secure the user’s informed consent to the fact that losing them is unrecoverable, because the operator cannot reset access in a way that exposes content. Getting this comprehension right at onboarding is what makes a later loss a known accepted trade-off rather than a support failure.
• Private by default. Surfaced explicitly during onboarding as a promise: the operator who is provisioning the account cannot see the content that will live in it, and no other user can either, absent an explicit share. The user should leave onboarding believing this, because it is true.
• No storage quotas. Named during the comprehension beat as a concrete benefit, especially salient for someone migrating off a metered commercial provider.
• Operator succession. The user-facing half of this rule — “you can pull a complete on-demand archive of your own content, and you should do so proactively while the system is healthy” — is introduced here as the user’s standing safety line and exit path. The sealed-successor half is an operator concern and not surfaced to the user.
• KPI — Number of active users. This journey is the top of the funnel for that KPI. Provisioning a user is necessary but not sufficient; the metric counts users who actually {upload, view, download, share}. Ending the flow by pointing at a concrete first action is how onboarding contributes to active rather than merely dormant counts.
• KPI — Zero data loss. A precise boundary matters here: a user losing their own credentials is not a violation of this KPI. The KPI is about the system never losing content the user did not themselves delete or lose access to. Onboarding must convey this distinction so the guarantee (“we won’t lose your stuff”) isn’t heard as a promise the trade-off contradicts (“even if you lose your key”).

Out of Scope

• The user’s first upload or import. Onboarding ends at a ready, empty library pointed at the next step. The actual first-content journeys live in Upload Content and Bulk-Import from a Prior Provider.
• The operator’s provisioning mechanics. How the operator stands up an account (identity technology, invitation delivery, account creation steps) is a design and operational concern, not part of the user’s experience. This doc only covers what the invited person perceives.
• Removal / departure and the 30-day retention window. When the operator removes a user, or a user chooses to leave, that is Delete Content and Leave. This journey only notes that operator-initiated removal exists and is governed there.
• Credential recovery. Explicitly excluded by the capability itself. There is no recovery journey to document; the absence is the design.
• Sharing and being shared with. A brand-new user with an empty library is neither sharing nor receiving yet. Those are Share Content and Receive Shared Content.

Open Questions

None remaining. The three questions this journey previously carried have been resolved and folded into the sections above:

• Depth of the comprehension check → a simple explicit acknowledgement after the plain-language explanation, deliberately not a quiz or gate (Journey, step 4).
• Invitation expiry and re-invitation → unaccepted invitations expire after a bounded window, and the operator re-invites with the same one-step action, no penalty (Journey, step 2 and Edge Cases).
• Guided vs. self-directed first step → passive direction: the empty library points at upload/import and lets the user proceed, with dormancy watched via the active-users KPI rather than forced away (Journey, step 6).

4 - Receive Shared Content

One-line definition: A user who has been granted access to someone else’s content finds it, views it, downloads the copies they want, and understands the boundaries of what’s been shared with them.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is a recipient — the capability’s Secondary actor / consumer: an existing, provisioned user whom a content owner (see Share Content) has explicitly granted access to specific content, individually or via a shared group/album. This journey is the mirror image of Share Content, seen from the other side.

• Role: A user on the receiving end of a share — the grandparent who was given access to the new baby photos, a family member in the shared “family album.” They are a full user in their own right (they have their own library), but in this journey they are consuming someone else’s content, not managing their own.
• Context they come from: Someone in the circle decided to show them something. They arrive either because the shared content surfaced for them, or because they were told out of band (“check the album, I added photos”).
• What they care about here: Seeing what was shared, keeping the parts they care about, and understanding the relationship — what is theirs versus what they are merely being shown — without confusion.

Goal

“Someone in our circle shared photos with me — I want to see them, keep the ones I care about, and know what I’m allowed to do with them.”

Entry Point

The recipient becomes aware that content has been shared with them. Critically, they arrive at shared content — they never arrive by browsing the owner’s private library, because they cannot: they only ever see what was explicitly shared to them (see Constraints Inherited — Private by default). Awareness comes in one of two ways, and the system leans on the first as its baseline: the shared content simply appears in a distinct “shared with me” surface the next time the recipient looks (a pull signal they discover on their own terms), optionally reinforced by an out-of-band nudge from the owner (“check the album, I added photos”). The system deliberately does not push a dedicated alert, email, or notification of its own — it neither operates a notification channel nor reveals recipient presence/activity back to the owner, keeping sharing a quiet relationship inside the circle rather than an eventful one. The trade-off is accepted openly: a recipient who never looks may not notice a share until they next visit, and nudging is left to the people, not the system.

Journey

1. Notice the shared content. The recipient perceives that new content has been shared with them, kept clearly distinct from their own library so the two never blur together.
2. View it. They look through what was shared — the photos, the video, the album — as a guest of that content, not as its owner.
3. Download what they want to keep. For items they want a lasting personal copy of, they download the original. A downloaded copy becomes their own content, now living under their control (and their own deletion/retention behavior if they later remove it). The copy carries no system-enforced provenance — once saved it is indistinguishable from the recipient’s own uploads, with no “originally shared by X” marker the system maintains or surfaces. This is the clean, honest consequence of the boundary model: a downloaded copy is fully theirs, not a tracked derivative the owner still has a thread into. (If a recipient wants to remember where a photo came from, that is theirs to note; the system does not do it for them, and does not report the download back to the owner.)
4. Understand the boundaries. The recipient understands, through how the experience behaves, that:
   • the content still belongs to the owner;
   • the owner can revoke the shared view at any time, at which point the recipient sees a plain “no longer shared” state rather than a silent disappearance (see step 5 of Share Content and Edge Cases below);
   • a copy they downloaded is theirs and is not revoked when the owner revokes the share;
   • removing a shared item from their own view does not delete the owner’s original — they can only dismiss it from their side.
5. Keep shared and owned separate. Throughout, “shared with me” stays visually and conceptually separate from “my own library,” so the recipient never mistakes one for the other.

Flow Diagram

flowchart TD
    Notice([Content shared with the recipient]) --> Distinct[Appears separate from their own library]
    Distinct --> View[View as a guest of the content]
    View --> Keep{Want a lasting copy?}
    Keep -->|Yes| Download[Download original —<br/>becomes recipient's own content]
    Keep -->|No| Leave[Just view it]
    Download --> Owned((Personal copy under recipient's control))
    Leave --> Boundary
    Owned --> Boundary[Understands: owner still owns the original]
    Boundary --> Change{Owner revokes or deletes original?}
    Change -->|Revokes share| GoneView[Shared view disappears —<br/>downloaded copies unaffected]
    Change -->|Deletes original| GoneView
    Change -->|No change| Stay[Shared view remains available]

Success

A successful receive-shared experience leaves the recipient with:

• What was meant for them, seen clearly. They viewed exactly what the owner intended to show, with no friction and no accidental exposure to the owner’s other content.
• The copies they wanted, under their own control. Anything they chose to keep is now genuinely theirs.
• An accurate mental model. They understand the borrowed-view-versus-owned-copy distinction, so nothing about a later revocation or deletion feels like a betrayal or a bug — it matches what they already understood.
• No clutter or confusion. Shared-with-me content never contaminates their own library.

Edge Cases & Failure Modes

• The owner revokes access. Experience-level handling: the recipient’s shared view is removed going forward, but it does not simply blink out of existence — the recipient sees a plain, neutral “no longer shared” state, enough to read the change as intentional (“the owner changed their mind”) rather than a bug or a loss. That message is deliberately incurious: it does not reveal why access ended, and it does not distinguish a revoke from the owner deleting the original — so a recipient can never reverse-engineer the owner’s private actions from it. Anything they already downloaded remains theirs; revocation does not reach copies that already left the owner’s control. This is the recipient-side mirror of the resolution in Share Content.
• The owner deletes the original. The shared view goes away for the recipient (consistent with revocation); a copy the recipient already downloaded is unaffected. Cross-reference: Delete Content and Leave.
• Confusing shared-with-me for my-own. The recipient must never believe that deleting a shared item removes the owner’s original — it does not. They can only remove it from their view. The experience keeps this unambiguous so a recipient “cleaning up” cannot imagine they are affecting someone else’s library.
• A recipient loses their own credentials. The Lost credentials = lost data trade-off applies to the recipient exactly as to any user: copies they downloaded and keep live in their account, and are as unrecoverable as anything else they own if they lose access. Being a recipient does not exempt them from the capability’s core trade-off.
• Wanting to re-share onward. Experience-level handling: re-sharing the owner’s shared view is not possible — a recipient cannot forward, re-share, or add anyone else to what was shared with them. This preserves the owner’s guarantee that content reaches only the people the owner explicitly named. The one path by which shared content ever reaches someone new runs through the boundary the capability already accepts: the recipient downloads it, at which point the downloaded copy is their own content, and they may share that copy as its new owner — a fresh share of a distinct copy they own, not the owner’s original share propagating onward (the owner’s original and its access list are untouched). This is the single, consistent answer shared with Share Content.
• A downloaded copy carries no provenance. Experience-level handling: once the recipient downloads and keeps content, it becomes indistinguishable from their own uploads — the system attaches no “originally shared by X” marker and maintains no ongoing link back to the owner. This is intentional: it keeps the copy genuinely the recipient’s, avoids a lingering tracking thread that would sit oddly against the no-surveillance posture, and matches the clean owned-vs-borrowed split the rest of the journey relies on. Any memory of where a copy came from is the recipient’s to keep, not the system’s to enforce.
• Never seeing the owner’s other content. No path in this journey ever exposes the owner’s broader private library. The recipient’s world is bounded by what was explicitly shared.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• Private by default. The recipient sees only what was explicitly shared to them — never the owner’s wider library. This rule defines the entire boundary of the recipient’s experience. The operator, likewise, sees nothing extra as a result of any share between users.
• Closed user set. The recipient is themselves a provisioned member of the circle; only users can be on the receiving end of a share. There is no anonymous or public recipient.
• Lost credentials = lost data. Applies to the recipient’s own copies. Content they download and keep is theirs, protected by their own credentials, with the same no-recovery trade-off as any user’s content.
• No affected-party recourse process. If the recipient is also someone depicted in content shared by another, they have no special in-system removal right by virtue of being depicted; that is resolved interpersonally, per the capability. Their rights in this journey come from being an explicitly-named recipient, not from being a subject.
• KPI — Number of active users. Viewing and downloading shared content are two of the four counted active-user actions ({upload, view, download, share}). A recipient who regularly engages with shared content is an active user, even in periods when they upload nothing of their own — shared consumption is a legitimate, counted form of getting value from the system.
• KPI — Zero data loss (precise reading). This KPI is about a user losing content they own and did not delete. A recipient losing a shared view when the owner revokes or deletes is not a data-loss failure — the recipient never owned that view; they were a guest. Only the recipient’s own downloaded copies fall under the KPI for them. The experience should reflect this so a vanished shared view reads as “the owner changed their mind,” not “the system lost my data.”

Out of Scope

• The owner’s side of sharing. Deciding to share, choosing recipients, and revoking are Share Content. This doc is only the recipient’s experience.
• Managing the recipient’s own library. Once a recipient downloads a copy, browsing/organizing/exporting it is View and Organize Content, and deleting it is Delete Content and Leave — the same journeys as for any content they own.
• Becoming a user in the first place. The recipient is already provisioned; onboarding is Join as an Invited User.
• Group administration. How shared groups (e.g. a family album) are created and who manages membership is a shared concern surfaced in Share Content, not resolved here.

Open Questions

None remaining. The four questions this journey previously carried have been resolved and folded into the sections above. The re-sharing and revocation-visibility questions are shared with Share Content; the answers below are the single, consistent resolution both journeys use.

• May a recipient re-share content shared with them? → No — re-sharing the owner’s shared view is blocked. A recipient cannot forward, re-share, or add anyone else to what was shared with them. Content reaches someone new only when the owner shares it directly, or when the recipient downloads it: a downloaded copy becomes the recipient’s own content, which they may then share as its new owner. The owner’s original share never propagates onward (Edge Cases). (Shared with Share Content.)
• How is the recipient notified of a new share? → A pull-based “shared with me” surface, optionally reinforced by an out-of-band nudge from the owner — no dedicated system alert. Shared content appears in a distinct surface the recipient finds when they next look; the system pushes no alert of its own and reports nothing about the recipient back to the owner. The accepted trade-off is that a recipient who never looks may not notice until their next visit (Entry Point).
• What does the recipient see when a share is revoked or the original deleted? → A graceful, neutral “no longer shared” state, not a silent disappearance — enough to read the change as intentional, without revealing why access ended or distinguishing a revoke from a delete, and with any already-downloaded copies left untouched (Journey step 4, Edge Cases). (Shared with Share Content.)
• Does downloaded shared content carry provenance? → No. Once downloaded and kept, a copy is indistinguishable from the recipient’s own uploads — the system attaches no “originally shared by X” marker and keeps no ongoing link to the owner. The copy is genuinely the recipient’s, consistent with the download boundary and the no-surveillance posture (Journey step 3, Edge Cases).

5 - Share Content

One-line definition: A content owner grants a specific fellow user, or a shared group/album, access to chosen content — and can review and revoke that access later — while everything else stays private.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is a content owner — a Primary actor from the parent capability’s Stakeholders — who wants to let someone else in the trusted circle see specific media of theirs. The recipient’s side of this interaction is a separate journey (Receive Shared Content); this doc is strictly the owner deciding to share and staying in control of that decision.

• Role: A user who owns content and wants a specific person, or a defined group, to see specific items — a grandparent seeing the new baby photos, a “family album” the whole family can see.
• Context they come from: They are in their own library (View and Organize Content) and something there is worth showing to someone. Their reference point is the commercial photo app’s sharing — but with a sharper expectation of privacy, because privacy is why they left.
• What they care about here: That exactly the people they intend can see exactly what they chose — no more — that the rest of their library stays private, and that they can take access back later if they change their mind.

Goal

“I want just these photos seen by just this person — or our family album — nobody else, and I want to be able to take that access back later.”

Entry Point

The owner is in their own library and decides that some specific content should be seen by someone specific. The trigger is social, not systemic: a moment worth sharing, a person who would want to see it, an album the family keeps together. They arrive already knowing what they want to share and roughly with whom.

Journey

1. Select the content. The owner picks the specific item(s) to share — one photo, a set, a whole album’s worth. Everything they do not pick stays private; sharing is strictly additive and scoped to the selection.
2. Choose the recipient. The owner picks who gets access, in one of two shapes:
   • One-to-one — another named existing user in the circle.
   • A shared group — e.g. a “family album” that a defined set of users can see. A shared group is owned and administered by the user who creates it, not by the operator: that owner draws the group’s members from the closed user set and decides what content the album holds (members and content can change over time). The operator’s only role stays provisioning users into the circle — group administration is a user-level act, not an operator burden. In both shapes, the recipient must already be a user (see Constraints Inherited — Closed user set). There is no sharing to an email address, a public link, or anyone outside the invited set.
3. Grant access. The owner shares. The content becomes visible to the chosen recipient(s) and to no one else.
4. See exactly who can now see it. The owner gets a clear, truthful picture of who has access to this content as a result — so “who can see this?” always has an answer they can check, not a vague sense that they shared it “somewhere.”
5. Review and revoke later. At any later point the owner can look at what they have shared and with whom, and revoke access. Revocation removes the recipient’s shared view going forward. On the recipient’s side the view does not simply blink out of existence — they see a plain “no longer shared” state (see Receive Shared Content), enough to read the change as intentional. That message is deliberately neutral: it does not reveal why access ended or distinguish a revoke from a deletion, so revoking never leaks the owner’s private actions.

A note on what revocation can and cannot do

Revocation reliably removes the shared view. It cannot reach a copy a recipient already downloaded — once a recipient saves a copy, that copy is theirs (see Receive Shared Content). The experience must be honest about this boundary so the owner shares with correct expectations rather than a false sense of total recall.

Crucially, the system does not report a recipient’s activity back to the owner — the owner is not notified when a recipient views or downloads shared content. Sharing here is a relationship inside a trusted circle, not a surveillance channel over the people the owner chose to share with; feeding the owner a log of recipient views would erode those recipients’ privacy exactly as the operator’s non-visibility protects everyone else’s. Because the owner therefore cannot know whether a copy was already downloaded before a revoke, the honest posture is the same one the download boundary already demands: treat anything shared as potentially already kept. This makes “notify on download” not just unnecessary but beside the point — the owner should share only what they are comfortable leaving in a recipient’s hands, and the experience sets that expectation up front rather than offering after-the-fact tracking.

Flow Diagram

flowchart TD
    Start([In their library, owner decides to share]) --> Select[Select specific content]
    Select --> Who{Choose recipient}
    Who -->|One person| Named[A named existing user]
    Who -->|A group| Group[A shared group / family album]
    Named --> Closed{Recipient already a user?}
    Group --> Closed
    Closed -->|No| Invite[Can't share outside the circle —<br/>operator must invite them first]
    Invite --> Who
    Closed -->|Yes| Grant[Grant access]
    Grant --> Confirm[Owner sees exactly who can now view it]
    Confirm --> Live((Recipient can see it;<br/>rest of library stays private))
    Live -->|Change of mind| Revoke[Review shares & revoke]
    Revoke --> Note[Shared view removed going forward —<br/>already-downloaded copies remain with recipient]
    Note --> Live

Success

A successful share leaves the owner with:

• Precisely-scoped visibility. Exactly the intended people can see exactly the intended content, and nothing else of theirs leaked.
• A clear, checkable picture of access. They know who can see what, and can revisit it — sharing never becomes a fog of “who did I show this to?”
• Retained control. They can revoke, and they understand the one honest limit (downloaded copies), so their expectations match reality.
• Undisturbed privacy everywhere else. The act of sharing one thing did not weaken the privacy of everything else; their library is still private by default.

Edge Cases & Failure Modes

• Sharing with someone who isn’t a user yet. Experience-level handling: not possible directly. The owner can only choose from people already in the Closed user set. To share with someone new, that person must first be invited and provisioned by the operator (Join as an Invited User); only then can the owner share with them. There is no public link and no external-email share — this is a deliberate consequence of the capability’s Public sharing being out of scope.
• Revoking after a recipient has downloaded. The shared view disappears, but a downloaded copy is now the recipient’s own and is beyond the owner’s reach. The experience states this plainly rather than implying revocation claws back copies.
• A recipient wants to pass the content on. Experience-level handling: re-sharing the owner’s shared view is not possible — a recipient cannot forward, re-share, or add someone else to what was shared with them. This keeps the owner’s guarantee intact: content reaches only the people the owner explicitly named. The one path by which shared content ever reaches someone new runs through the honest boundary the capability already accepts — a recipient downloads it, at which point the downloaded copy is their own content, and they may share that copy as its new owner. That is a fresh share of a distinct copy the recipient owns, not the owner’s original share propagating onward; the owner’s original and its access list are untouched. This is the single, consistent answer shared with Receive Shared Content.
• Shared-group membership changes. A shared group is administered by its owner (the user who created it — see Journey step 2), who adds and removes members from the closed user set. When someone is added to or removed from the group, the experience makes clear how that affects who can see content already shared to the group — so the owner is never surprised by a new group member gaining access to old content, or a removed member losing their view going forward (a removed member is revoked exactly as an individual revoke, and any copy they already downloaded remains theirs).
• A person depicted in the shared media objects. There is No affected-party recourse process in the system — a non-user depicted in a photo has no system-provided way to force its removal, and even a user who is merely depicted (not the owner) has no override. Such objections are expected to be resolved interpersonally, outside the system; the owner decides. The sole exception is the operator’s termination lever under No illegal content: where a depiction is itself illegal in the operator’s jurisdiction, the operator may act on credible evidence — but the operator still cannot inspect content directly. The experience should not imply any in-system “report this share” flow beyond that narrow, operator-driven lever.
• The operator is not a privileged viewer. Sharing among users never makes content visible to the operator. The operator sees a user’s content only if that user explicitly shares it to the operator, exactly as they would with anyone else.
• Over-broad selection. If the owner accidentally selects more than they meant (e.g. a whole album when they wanted one photo), the review-access step is their safety check — they can see the full scope of what they just exposed and pull it back before it matters.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• Private by default. This is the rule the whole journey turns on. All content is private to its owner unless the owner explicitly shares it. Sharing is the only mechanism by which anyone else — including the operator — ever sees a user’s content. Nothing about this journey erodes the default; it is a scoped, deliberate exception the owner controls.
• Closed user set. Recipients must be members of the invited circle. Only the operator adds or removes users; an owner cannot conjure a recipient. There is no public sign-up and, correspondingly, no public sharing — Public sharing is explicitly out of scope in the capability.
• No affected-party recourse process. People depicted in shared media have no system-provided removal path; objections are resolved interpersonally. This is a deliberate capability decision, not a gap this UX should try to fill.
• No illegal content. The single operator lever that can override an owner’s sharing is termination on credible evidence of illegal content, governed by the operator’s jurisdiction. This UX surfaces that lever precisely and does not overstate it into general operator moderation of shares.
• Lost credentials = lost data. Sharing does not create an operator backdoor or a recovery path. A recipient still holds their own credentials, and the privacy posture (no operator visibility without explicit share) is preserved throughout.
• KPI — Zero data loss. Reviewed here for the guarantee it imposes on this journey: sharing and revoking are non-destructive to the owner’s content. Sharing is purely additive — it grants visibility, and never moves, copies out, or deletes the underlying item — so it cannot cause the owner to lose anything. Revoking a share must remove visibility, never the content itself; a revoke that deleted the owner’s original would be a zero data loss failure hiding inside a sharing action. The one place data does leave the owner’s control — a recipient’s downloaded copy surviving revocation — is not a loss of the owner’s data (their original is untouched); it is a limit on recall, addressed honestly in the revocation note above. This journey therefore has no path that undermines the zero-data-loss guarantee.
• KPI — Number of active users. Sharing is one of the four counted active-user actions ({upload, view, download, share}). A circle that actually shares with each other is a circle getting real value from the system — sharing is arguably the strongest signal that the capability is meeting a social need the old provider met.

Out of Scope

• The recipient’s experience. What the recipient sees, does, and is allowed to do with shared content is Receive Shared Content. This doc stops at the owner’s side of the interaction.
• Selecting and browsing content to share. Finding and picking the content happens in View and Organize Content; this doc picks up once the owner has decided to share.
• Provisioning a new recipient. If the intended recipient isn’t a user yet, inviting them is the operator’s job, covered by Join as an Invited User.
• Deleting shared content. What happens to a share when the owner deletes the underlying content (recipients lose the view; downloaded copies remain) is covered by Delete Content and Leave.
• Public sharing of any kind. Sharing outside the invited circle is explicitly out of scope for the entire capability and therefore impossible in this journey.

Open Questions

None remaining. The four questions this journey previously carried have been resolved and folded into the sections above. The first and last are shared with Receive Shared Content; the answers below are the single, consistent resolution both journeys use (Receive Shared Content adopts them in its own doc):

• Can a recipient re-share content? → No — re-sharing the owner’s shared view is blocked. Content reaches someone new only when the owner shares it directly, or when a recipient downloads it: a downloaded copy becomes the recipient’s own content, which they may then share as its new owner. The owner’s original share never propagates onward, preserving “exactly the people the owner intends” (Edge Cases). (Shared with Receive Shared Content.)
• Is the owner notified when a recipient views or downloads? → No. The system does not report recipient activity back to the owner — sharing is a trusted-circle relationship, not a surveillance channel. The owner is instead guided to treat anything shared as potentially already-downloaded-and-kept, which is the honest posture the revocation limit already demands (see the revocation note under Journey).
• Who owns and administers a shared group? → The user who creates it — not the operator. That owner draws the group’s members from the closed user set and decides what content the album holds; the operator’s only role stays provisioning users into the circle (Journey step 2, Edge Cases).
• What does a recipient see when access changes? → A graceful “no longer shared” state, not a silent disappearance — neutral enough to read as an intentional change, without revealing why or distinguishing a revoke from a delete, and with any already-downloaded copies left untouched (Journey step 5). (Shared with Receive Shared Content.)

6 - Upload Content

One-line definition: A provisioned user gets their media into their own storage — sometimes a specific file they deliberately choose, sometimes automatically from their device without thinking about it — and trusts it landed safely and privately.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is an active user — one of the Primary actors (initiators) named in the parent capability’s Stakeholders: the operator, a family member, or a friend, acting on their own content. They have already been invited and provisioned (see Join as an Invited User); this journey is about the everyday act that makes the account worth having.

• Role: An everyday user putting their own photos, videos, and files into their own storage. Non-technical is the default assumption — they think in terms of “my photos,” not “objects” or “buckets.”
• Context they come from: They just took a photo, shot a video, or have a file on a device they want kept safely. Their prior mental model is a commercial cloud provider’s camera-roll sync — the thing they are trying to replace. They expect “it just backs up” to be the baseline, not a feature they have to earn.
• What they care about here: That the content they intend to keep is actually kept, that it is private to them, and — for automatic backup — that it keeps happening without their attention so they never lose a memory to a dropped, lost, or upgraded device.

Goal

“I want my photos, videos, and files safely in my own storage — sometimes a specific thing I pick, sometimes just automatically from my phone — so I never lose a memory, and so nobody but me can see it.”

Entry Point

There are two distinct entry points into the same journey, and the difference in the user’s state of mind is the whole reason both belong in one doc:

• Manual upload (deliberate, attended). The user has a specific thing in mind — a photo they want off a borrowed camera, a document they want kept, a video someone sent them. They come to the system on purpose and expect to watch it land.
• Automated device backup (passive, set-and-forget). The user configured backup once, at some earlier moment, and is now not thinking about the system at all. New captures on their device are expected to flow in on their own. The user only re-engages to occasionally reassure themselves it is working — or when something makes them doubt it.

Both entries share the same goal (content stored, private, durable) and the same success condition (trust that it landed). They diverge only in how much attention the user is paying.

Journey

Branch A — Manual upload

1. Choose the content. The user picks the specific item(s) they want stored — one photo, a handful, a large video, an arbitrary file. There is no size or count ceiling they have to plan around (see Constraints Inherited — No storage quotas).
2. Send it. The user starts the upload and stays with it — this is the attended case.
3. Perceive progress. For anything that takes more than a moment (a long video, a batch), the user sees that it is progressing and roughly how much remains. Progress is legible enough that they are not left wondering whether the system is stuck.
4. Get an unambiguous confirmation. When it is done, the user sees a clear signal that the content is now durably stored and private to them. This confirmation is load-bearing: it is what lets them safely delete the copy on their device. A vague or premature “done” that isn’t actually durable would quietly threaten the Zero data loss KPI, so the confirmation must mean what it says.

Branch B — Automated device backup

1. Turn it on once. At some earlier point the user enables backup for their device. This is a one-time, deliberate act; everything after is passive. What backup covers is deliberately not a folder-by-folder configuration exercise: enabling it backs up the device’s photos and videos — the camera roll, the irreplaceable memories that match how this user thinks (“my photos,” not “my filesystem”) — as a single on/off per device. Arbitrary non-media files are not swept up automatically; when the user deliberately wants a specific document or file kept, that is the manual path (Branch A), which already accepts any file. Keeping the automatic scope to media as one toggle protects the “not having to think about it” quality for a non-technical persona — a per-folder selector would trade that calm for configuration the user never asked for.
2. New captures flow in on their own. From then on, new photos and videos taken on the device are picked up automatically, in the background, without the user initiating anything. The user’s expectation — inherited from the commercial product they are replacing — is “I take a photo, and later it is just there in my storage.”
3. Reassure at a glance. When the user does look, they can quickly confirm that recent captures are backed up and see whether anything is still pending — enough to trust the mechanism without having to audit it item by item. The default signal is aggregate, not per-item: a plain “all caught up as of ” state plus a count of anything still uploading, because a non-technical user replacing a commercial product expects one reassuring status, not a receipt for every photo. Per-item certainty is still available on demand for the one case that needs it — when the user is about to free space on a specific item, they can confirm that item is durably stored before deleting it. This “aggregate by default, per-item on demand” split is how the Zero data loss trust is earned without drowning the user in confirmations.
4. Catch up after being offline. If the device was offline, out of range, or powered off for a while, backup resumes and catches up when connectivity returns. The user does not have to babysit it or manually re-trigger the missed items.

Where the branches meet

Whichever entry the user came through, the end state is identical: the content is in their private storage, it counts as their content under every rule the capability defines, and the act of putting it there registered them as an active user for that period.

Flow Diagram

flowchart TD
    subgraph Manual [Branch A — Manual upload]
        M1[User has a specific item in mind] --> M2[Choose the content]
        M2 --> M3[Send it, stay with it]
        M3 --> M4{Progress visible?}
        M4 -->|Interrupted| MInt[Perceived as paused]
        MInt --> MResume[Resumes from where it stopped]
        MResume --> M5
        M4 -->|Completes| M5[Clear confirmation:<br/>durably stored & private]
    end
    subgraph Backup [Branch B — Automated device backup]
        B1[User enabled backup once, earlier] --> B2[New captures flow in automatically]
        B2 --> B3{Device online?}
        B3 -->|Offline a while| B4[Queues; catches up on reconnect]
        B4 --> B2
        B3 -->|Online| B5[Recent captures backed up]
        B5 --> B6[User glances, reassured]
    end
    M5 --> Stored((Content in private storage —<br/>counts as an active-user action))
    B6 --> Stored
    Stored --> Trust[User trusts it landed;<br/>safe to free device storage]

Success

A successful upload experience leaves the user with:

• Trust that what they meant to store is stored. For manual uploads, the confirmation is explicit enough that they will delete the on-device copy without anxiety. For backup, they have a standing, low-effort way to confirm the mechanism is keeping up.
• A private result. They know the content is visible only to them — no third party, including the operator, can see it (see Constraints Inherited — Private by default).
• Freedom from the old provider’s anxieties. No quota warning, no “you’re running out of space, upgrade now.” The system quietly absorbs whatever they throw at it.
• For backup specifically: the feeling of not having to think about it. The best version of this experience is invisible — the user takes photos for years and their memories are simply, continuously safe.

Edge Cases & Failure Modes

• Network drops mid-upload. Experience-level handling: the upload is perceived as paused, not failed, and it resumes from where it stopped when connectivity returns — it is not silently abandoned, and it does not restart from zero. The user is never left believing something was stored when it wasn’t.
• The same photo is already backed up. Re-running backup, or a device re-reporting content it already sent, must not pile up duplicates. The user is not punished for caution; their library does not fill with copies of the same moment. (How de-duplication is achieved is an implementation concern, not part of this experience.)
• A very large file or video. There is no quota to bump into, but large items take longer. The experience keeps the user informed (Branch A) or simply handles it in the background over time (Branch B). The user is not forced to sit and watch.
• Device offline for days, then reconnects. Backup catches up on its own. The user who returns from a trip with a full camera roll finds it all backing up without manual intervention.
• The user needs to believe “backed up” before freeing device space. This trust is the crux of the Zero data loss KPI at the moment of upload: users delete on-device copies based on the system’s confirmation. So the experience must never show “backed up” for something not yet durable. If there is any state where an item is in progress versus safely stored, the user can tell the two apart before they rely on it.
• Partial batch upload. If some items in a batch land and others don’t (e.g. connectivity died mid-way), the user can see which succeeded and which still need to complete, rather than getting an all-or-nothing verdict that hides a gap.
• Backup silently stops. Permission gets revoked, the backup process is killed for good, or the device simply stops checking in — and the user, by design not paying attention, keeps taking photos believing they are safe. This is the single most dangerous failure for Zero data loss, so it is the one place the backup experience is deliberately not passive: prolonged silence is treated as suspicious, not successful. When backup has made no progress for longer than an expected check-in window, or when permission is affirmatively revoked, the user is actively notified — a push/alert that reaches them even though they are not looking — in plain language, naming the single corrective action (re-grant permission / re-enable backup). A quiet in-app indicator alone is insufficient here precisely because the endangered user is not opening the app. The alert is calibrated not to cry wolf over a normal overnight or out-of-range gap, but when in doubt it errs toward telling the user, because an unnoticed dead backup is the worst outcome this KPI can suffer.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• No storage quotas. Users upload freely; there is no per-user limit to plan around and no upsell. Capacity is the operator’s problem, not the user’s. The experience must never confront the user with a quota wall.
• Private by default. Uploaded content is visible only to its owner. No third party — including the operator — can see it. Nothing in the upload flow shares content; sharing is a separate, explicit act (see Share Content).
• Off-site backup is allowed. Durability may be achieved partly by replicating content off-site, provided the off-site copy preserves the same privacy properties. From the user’s seat this is invisible — it simply strengthens the “it won’t be lost” promise behind their confirmation.
• Lost credentials = lost data. Uploaded content is bound to the user’s own account, which only they can access. This is not central to the act of uploading, but it frames what “their storage” means: it is theirs alone, and the same trade-off that protects it (no operator backdoor) is the one covered in depth by Join as an Invited User.
• KPI — Zero data loss. The upload confirmation is the exact point where this KPI is won or lost in daily use: users free device space on the strength of it. “Confirmed stored” must be genuinely durable, and a paused upload must never masquerade as a completed one.
• KPI — Number of active users. Uploading is the canonical active-user signal (the KPI counts {upload, view, download, share} in a trailing 30-day window). Automated device backup is what turns a one-time uploader into a continuously active user, because content keeps arriving without the user having to remember to act — making it the single most important contributor to non-attrition on this KPI.

Out of Scope

• Bulk-importing an existing library from another provider. Moving years of history out of Google Photos / iCloud in one go is a different journey with a different mindset (a one-time migration, verified for completeness before cancelling the old provider). It lives in Bulk Import from a Prior Provider, not here. This doc covers routine, ongoing capture.
• Viewing, searching, and organizing what was uploaded. Once content is stored, browsing and arranging it is View and Organize Content.
• Sharing uploaded content. Making content visible to another user is Share Content.
• The initial decision to enable backup during onboarding. Where and how a new user is first pointed at “turn on backup” is part of Join as an Invited User. This doc assumes an already-provisioned user.

Open Questions

None remaining. The three questions this journey previously carried have been resolved and folded into the sections above:

• Granularity of backup status → aggregate by default, per-item on demand: a plain “all caught up as of ” signal plus a pending count for everyday reassurance, with per-item durability verifiable at the moment a user is about to free space on a specific item (Journey, Branch B, step 3).
• Backup scope → the automatic path backs up the device’s photos and videos as a single on/off per device; arbitrary non-media files are kept deliberately via the manual path rather than swept up by a per-folder selector (Journey, Branch B, step 1).
• Notification when backup silently stops → the backup experience is deliberately not passive here: prolonged silence or revoked permission triggers an active, plain-language alert that reaches the user even when they are not looking (Edge Cases).

7 - View and Organize Content

One-line definition: A user browses, finds, and organizes their own media, views and downloads originals, and can pull a complete on-demand export of everything they own.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is an active user — a Primary actor from the parent capability’s Stakeholders — spending time in their own library. They have already stored content (via Upload Content or Bulk Import from a Prior Provider) and now want to use it.

• Role: An everyday user browsing, finding, arranging, and retrieving their own photos, videos, and files. Non-technical is the default assumption — they think “my albums,” “that trip,” “the photo of the receipt,” not “queries” or “objects.”
• Context they come from: They are here to relive a memory, find one specific thing, tidy up, or grab an original to use elsewhere. Their reference point is the commercial photo app they left, which set expectations for fast scrolling, a timeline, search, and albums.
• What they care about here: That their library feels like theirs — well-ordered, quick to move through, private — and that they can always get their originals, and their whole archive, back out.

Goal

“I want to look through my own memories — see them by time, find a specific moment, group things into albums — get the original file when I want it, and be able to pull my whole archive out whenever I choose.”

Entry Point

The user opens their own library. The trigger is usually one of:

• Relive / browse — no specific target, just looking through their memories.
• Find one thing — they need a particular photo or file (the receipt, the photo to print, the document to attach somewhere).
• Tidy — they want to arrange things into albums or groups.
• Retrieve — they want the original file to use outside the system.
• Safeguard — they want to pull a complete copy of everything, for their own peace of mind or on a schedule.

Whatever the trigger, they arrive already authenticated as themselves, seeing only their own content.

Journey

1. Open the library. The user lands in their own content — and only their own. Someone else’s photos are never mixed in here; content shared with them lives in a separate experience (Receive Shared Content).
2. Browse. The user moves through their library in a way that matches how they remember — typically chronologically. Scrolling through years feels responsive rather than laborious.
3. Search / filter. When they have something specific in mind, they narrow down to find it. In this journey, search spans only metadata the system already holds without having to “understand” the content — filenames, capture dates and date ranges, and the user’s own organization (album names, favorites). It deliberately does not include content-understanding search (e.g. typing “beach” and matching pixels) in the baseline, because the tiebreaker in the parent capability is Privacy beats convenience: any feature that derives searchable meaning from the content itself is only acceptable if it can do so without ever exposing that content — or the derived index — to the operator or any third party. Until such a mechanism exists (per-user-key or on-device derivation that stays unreadable to the operator), richer content-based search stays out; if it is ever added, Private by default governs it, not the other way around. A search that matches nothing returns a clear empty result, not an error or a dead end.
4. Organize. The user groups content into albums — the one organizing primitive this journey commits to, chosen because it maps directly onto how the non-technical persona already thinks (“that trip,” “the kids”). Alongside albums, two lightweight aids ride on metadata the system already has, so they cost the user nothing to learn: favorites (a one-tap “keep this handy” marker) and date/date-range navigation over the existing timeline. Heavier taxonomy — freeform tags, nested collections, place-based search — is deliberately deferred, not designed in: it adds cognitive load for a non-technical user and, in the case of place/content search, reopens the privacy question above, so it waits until a real need in the operator’s circle pulls for it rather than being built speculatively. Crucially, organizing is non-destructive: albums and favorites are ways of seeing their content, not copies of it and not the content itself.
5. View a specific item. They open an individual photo, video, or file to look at it closely.
6. Download originals. When they want a local copy — to print, to send outside the system, to edit — they retrieve the original file, not a degraded version.
7. Pull a complete on-demand export. At any time, the user can request a full archive of everything they own, without operator involvement, while the system is healthy. This is the user-facing home of the capability’s Operator succession export mechanism: users are expected to pull these proactively, and may do so on a schedule, because on-demand export is only available when the system is up. This is also the concrete expression of the Longevity and Control outcomes — their data is always theirs to take. Two things about the archive are settled here in favor of the stronger Longevity guarantee:
   • What’s in it: the export contains originals plus the user’s organization, not originals alone. Originals land as first-class, unmodified files; the user’s structure — album membership, favorites, and capture dates — travels alongside them in an open, self-describing, non-proprietary form (a portable manifest/sidecar readable without this system). A takeout that dropped album structure would be a weaker Longevity guarantee — the user would keep their pixels but lose the years of arranging that made the library theirs — so the archive is designed to be understandable, and re-importable, even if this system no longer exists.
   • Scheduling and destination: the user can schedule recurring exports themselves, self-service, exactly as the capability’s “may schedule periodic pulls” language intends — no operator step. Because the entire point of a proactive pull is to survive the system being down, a scheduled archive must land somewhere the user controls that is independent of this system’s health (a destination the user designates — their own machine or their own off-system storage). An “export” that only ever wrote back into the same system would defeat its own purpose, so the destination is deliberately outside the system’s fate.

Flow Diagram

flowchart TD
    Open([User opens their own library]) --> Own[Sees only their own content]
    Own --> Intent{What did they come to do?}
    Intent -->|Relive| Browse[Browse chronologically —<br/>feels responsive]
    Intent -->|Find one thing| Search[Search / filter]
    Intent -->|Tidy| Organize[Group into albums<br/>— non-destructive]
    Intent -->|Retrieve| View[View a specific item]
    Intent -->|Safeguard| Export
    Search --> Found{Match?}
    Found -->|No| Empty[Clear empty result]
    Found -->|Yes| View
    Browse --> View
    Organize --> AlbumNote[Deleting an album ≠<br/>deleting the photos]
    View --> Download[Download originals]
    View --> Export[Pull complete on-demand archive<br/>— only while system is healthy]
    Download --> Done((Library feels theirs;<br/>originals & archive always retrievable))
    Export --> Done
    Empty --> Own

Success

A successful view-and-organize experience leaves the user with:

• A library that feels like theirs. Ordered, searchable, and arranged the way they think about their own memories — good enough that they stop missing the commercial app they left.
• What they came for. They found the specific thing, relived the trip, or grabbed the original they needed.
• Standing assurance of control. They know they can always download originals and pull their entire archive out — so the system never feels like a place their data is trapped. This is what makes them comfortable treating it as their primary store.
• No accidental destruction. They tidied without fear, because organizing never risks their content.

Edge Cases & Failure Modes

• A large library. Experience-level handling: browsing years of media feels responsive; the user can leave and come back without losing their place, and no single view forces them to wait on the whole collection loading before they can do anything.
• Organizing must never destroy content. Deleting or emptying an album removes a way of seeing the content — it does not delete the photos in it. The experience keeps this distinction unmistakable, so a user tidying up can never be tricked into destroying originals. (Actual deletion of content is a separate, deliberate act — see Delete Content and Leave.) This guard is a direct defense of the Zero data loss KPI.
• Export only while the system is healthy. The on-demand full archive is available when the system is up. If the system is down, only previously-pulled exports survive — an honest caveat inherited from Operator succession. The experience should make proactive/scheduled pulls feel like the natural habit, not an afterthought, precisely because a user who waits until the system is down has waited too long.
• A search finds nothing. The user sees a clear “nothing matched,” not an error — and can adjust and try again.
• A very large export takes a while. Pulling everything is a big operation; the user perceives it as progressing and can retrieve the finished archive when it is ready, rather than being blocked staring at it.
• A scheduled export’s destination is unreachable. Because a scheduled recurring export targets a user-controlled destination outside this system, that destination can be full, offline, or revoked when a run fires. The experience treats a failed scheduled pull as legibly failed, not silently skipped — the user learns their safety habit didn’t run, so a lapsed backup never masquerades as a healthy one. This honesty is what keeps scheduled export a real hedge rather than a false sense of security.
• Downloading a huge original or batch. Retrieving originals — especially many at once or a large video — is legible and resumable in spirit (the user is not left guessing whether a stalled download failed), consistent with how uploads behave in Upload Content.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• Private by default. The user browses only their own content, and no third party — including the operator — can browse it. There is no operator “view all libraries” surface. Content becomes visible to anyone else only through the explicit, separate act of Share Content. This is the rule that keeps content-understanding search out of the baseline (Journey, step 3): any search index derived from the content itself would be a new surface on which the operator could read content, so it is not built unless it can be derived and stored in a form the operator cannot read.
• Operator succession. The on-demand full export lives in this journey. The capability requires that every user can pull a complete archive of their own content without operator involvement while the system is healthy — this UX is where that promise is exercised, including the “only while healthy” caveat and the expectation that users pull proactively. The capability’s “may schedule periodic pulls” language is resolved here as user-scheduled, self-service recurring exports whose archive lands in a user-controlled destination outside this system (Journey, step 7), so a scheduled pull actually survives the system going down.
• No storage quotas. Nothing in browsing or organizing pushes the user toward pruning to save space; they organize for their own sake, not to stay under a limit.
• Off-site backup is allowed. Invisible here, but it is part of why the originals the user retrieves are trustworthy and durable.
• Lost credentials = lost data. The on-demand export is the user’s hedge against loss, which is why the journey urges pulling it proactively — but the experience must stay honest that it is not a recovery mechanism: a user who loses their own credentials loses access to the library itself, exports included, with no operator backdoor. Export protects against the system failing; it does not protect against the user losing their key.
• KPI — Zero data loss. The non-destructive-organizing guarantee is this journey’s contribution to the KPI: tidying, re-arranging, and deleting albums must never cost the user actual content.
• KPI — Number of active users. Viewing, downloading, and organizing are three of the four counted active-user actions (the fourth being sharing). A user who comfortably lives in their library is, by definition, an active — and retained — user. A library that feels slow or untrustworthy would show up as attrition on this KPI.

Out of Scope

• Getting content in. Uploading and device backup are Upload Content; the one-time migration of a prior library is Bulk Import from a Prior Provider.
• Sharing. Selecting content to share starts from the library, but the act of granting someone access — choosing a recipient or a shared group, and revoking later — is its own journey, Share Content.
• Viewing content shared with the user. Content others shared with them is not part of their own library; it is Receive Shared Content.
• Deleting content and leaving. Deletion is initiated from the library too, but its safety net (30-day retention) and the departure journey are Delete Content and Leave.

Open Questions

None remaining. The four questions this journey previously carried have been resolved and folded into the sections above:

• Organizing primitives → the journey commits to albums as the single organizing primitive (it matches how the non-technical persona already thinks), plus two zero-learning aids that ride on metadata the system already holds — favorites and date/date-range navigation. Heavier taxonomy (freeform tags, nested collections, place-based search) is deliberately deferred until a real need pulls for it, rather than designed in speculatively (Journey, step 4).
• What search spans → only metadata the system already holds without “understanding” the content — filenames, capture dates/ranges, album names, favorites. Content-understanding search (e.g. “beach”) is kept out of the baseline under the Privacy beats convenience tiebreaker, and may be added later only if it can be derived and stored in a form the operator cannot read — Private by default governs it, not the reverse (Journey, step 3 and Constraints).
• What a “complete export” contains, and in what form → the stronger Longevity guarantee: originals plus the user’s organization (album membership, favorites, capture dates) in an open, self-describing, non-proprietary form readable and re-importable without this system — not originals alone (Journey, step 7).
• User-scheduled recurring exports and their destination → yes, self-service, with the archive landing in a user-controlled destination outside this system so a scheduled pull actually survives the system going down; a failed scheduled run fails legibly rather than silently (Journey, step 7, Edge Cases, and Constraints).