← Back

Refri

A personal library that captures a link or file as fast as a message to yourself and keeps it findable later.

Project overview

Type: Product · 6-week 0→1
Project type: 0→1 · Personal Knowledge & Bookmarking · Capture & Retrieval · Local-first
Role: Lead Product Designer · Interaction Design · UX Research · Experiment Design
Methods: Diary study · contextual inquiry · usability testing · A/B
Tools: Otter.ai · Figma + Dev Mode · Amplitude · Statsig
Case thesis: Designing a personal library that captures a link or file as fast as a message to yourself and, through optional per-item context added later, keeps it findable, so saved things stop disappearing into a graveyard.

The context

People save things they do not want to lose all day (a link, a tool, a PDF, a video, a track), and the place they reach for is whatever is already open: a chat to themselves on WhatsApp, or the notes app. Content saved inside a platform is borrowed: a reel or video vanishes if the creator deletes it, and there is no longer an owned, portable file the way an MP3 once was. The capture surface people use is the lowest-friction one, and it is also where saved things go to be forgotten.

The problem

What gets saved rarely gets seen again. In research, people saved links to a self-chat or notes app 71% of the time, yet revisited only 14% of what they saved (behavioral, self-report + audit). The reasons were consistent: the context faded ("why did I save this?"), the item scrolled away in a thread of unrelated messages, and there was no way to search it by what it was for. People chose the surface for capture speed and accepted that retrieval would fail.

The goal

Make capture as fast as a message to yourself and make saved items findable later with the reason they were kept, measured by capture rate, revisit and find-success, and retention, rather than by how many fields an item could hold.

Empathize — People saved to their own chat for the speed and revisited only 14% of it, because context was lost and items scrolled away

In this section: Research foundation · Key insights

Research foundation (method)

Phase 1 — Interviews (n=20, ~35 min, heavy content-savers, recruited via dscout, transcribed in Otter.ai): where they save, why there, and what happens to it.
Phase 2 — Save-and-retrieve audit (n=24): participants tried to find and act on something they had saved in their usual place.
Phase 3 — Survey (n=190; 18.1% response, 12.5% completion; select-all and single-select labeled per question): on saving habits and lost saves.
Phase 4 — Prototype pilot (Amplitude-instrumented, 65 users): capture and revisit behavior on the library.

Key insights

1. People save in the lowest-friction surface already open. The self-chat won because it is instant and requires nothing, and anything that asked for a login or a form at save time lost to it. Triangulation:

Behavioral: 71% saved to a self-chat or notes app; the most cited reason was that it was already open and took one step.
Verbatim — coded: Capture speed: "I'm not going to open some app and log in and tag things, I just paste it to myself and move on."

2. That same surface destroys retrieval. Once saved, items lost their reason and sank into an undifferentiated stream, so they were almost never found again. The behavior that made capture easy made retrieval fail.

Behavioral: 14% of saved items were revisited; in the audit, most participants could not recall why they had saved a given item.

3. Saved content is borrowed and impermanent. Items saved inside a platform disappeared when the source was deleted, and there was no owned, exportable copy, so even a "saved" thing was not reliably kept.

Verbatim — coded: Ownership: "I saved a video I loved and one day it was just gone, and I had no copy of it anywhere."

Dashboard — Saved, then never seen again

Saved, then never seen again
Scope: save-and-retrieve audit (n=24) + survey (n=190)
Guiding question: What happens to the things people save?

  Save to a self-chat / notes app ......... 71%
  Saved items ever revisited .............. 14%
  Could recall why an item was saved ...... low

Key Insight: The surface people use for capture is the one that loses the
item, so saving and finding-again are two problems the self-chat splits.

Define — Capture had to be as fast as a self-chat, and saved items had to stay findable with the reason they were kept

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. A person needs to capture a link or file as fast as a message to themselves and still find it later with the reason they saved it, because the friction-free surfaces they use today lose the context and bury the item.

How Might We

How might we make capture as instant as a self-chat, with no registration and no form?
How might we let context be added later, optionally and per item, so saving stays instant and the item stays findable?
How might we keep saved items owned and permanent, so a save is reliably kept?

Design principles (each traceable to an insight)

Capture at self-chat speed. The app opens ready to save, with no login and local-first storage, so the first save costs one step. (Insight 1)
Enrichment is optional and progressive. Context, title, tags, and the rest are added later, one field at a time, only when useful. (Insight 1, 2)
Saved items have a state and a way back. A status and retrieval by context, tag, and category keep items from sinking into a stream. (Insight 2)
The library is owned and portable. Items live locally, sync when the user registers, and export as a package the user keeps. (Insight 3)

Insight → decision map

Insight (from Empathize)	Concrete design decision
People save where it is instant and login-free	Refri opens to a paste-or-upload field and saves locally with no account; registering later syncs the local items across devices
Context fades and items sink in a stream	Each item takes optional fields one at a time (context, title, notes, tags, category) and a status of inbox, reviewed, or important, with search and filters to find it
Saved platform content disappears	Items, including files, are stored and exportable as a portable package the user can load into any Refri account

Ideate & Craft — Saving was one instant action; context was optional and added one field at a time

In this section: Design execution · Before → after · Other deliverables

Design execution

Instant capture — opening the app or a shared link lands on a field ready to paste a link, drop a file (audio, .md, video, PDF), or write a note, and a single action saves it. No registration; everything is stored locally first.
Optional, per-item context — an item can be left as a raw dump or enriched later with a context line, extra files, a title, notes, tags, a main category, and a status of inbox, reviewed, or important. The fields are added one at a time, never as a form to fill on every save.
Retrieval — search plus filters by tag, category, status, and collection bring an item back, so the library answers "the thing I saved for X" rather than scrolling a timeline.
Store or Playlist — saving either stores the item in the library or starts a Playlist: a shareable collection with its own link that anyone can open and consume without registering, or add into their own account.
Own it and keep it — registering syncs local items across devices, and the whole library exports as a portable package the user can reload into any account, the way an Obsidian vault stays theirs.

Before → after

	Before (self-chat / notes app)	After (Refri)
Capture	One step, but in a thread of noise	One step, into a library built to keep it
Context	Lost as the item scrolls away	Optional fields added later, per item
Finding it again	Scroll and hope	Search and filter by tag, status, category
Ownership	Borrowed; can vanish	Local-first, synced, and exportable

Other deliverables

Built in Figma with Dev Mode handoff: the instant-capture field and item model, the optional per-field enrichment pattern, the status and retrieval system, the Playlist share flow, and the local-first sync-and-export architecture.

Dashboard — Capture stays instant and items come back

Capture stays instant and items come back
Scope: Last 30 days · pilot (65 users)
Guiding question: Did items get saved fast and found again later?

  Items revisited within 30 days .......... 14% → 49%
  Items given context after capture ....... 64% (added later, voluntarily)
  Find-success in the retrieve task ....... 46% → 88%

Key Insight: One-step capture kept saving instant, and status plus
retrieval brought items back instead of letting them sink.

Prototype / Test — A cleaner reverse-chronological feed was easy to save into and reproduced the graveyard; status triage and retrieval brought items back

In this section: The experiment · What it taught

The first build organized saved items as a single reverse-chronological feed, newest on top, on the assumption that a cleaner version of the self-chat would be enough. It was A/B tested against a status-triaged, retrieval-first library in Statsig across the pilot.

The failed variant. The feed was just as easy to save into, but it reproduced the problem it was meant to fix: old items sank as new ones arrived, there was no path back to a specific save, and the revisit rate landed at 18%, barely above the self-chat baseline. A tidier stream was still a stream, and items still disappeared down it.

A cleaner stream is still a stream
Scope: Statsig A/B · pilot · n=2 variants
Guiding question: Which model gets saved items found again?

  Variant A — Reverse-chronological feed
    Capture speed ................... instant
    Items revisited within 30 days .. 18%   (vs 14% self-chat baseline)
    Find a specific past save ....... slow, often failed

  Variant B — Status triage + retrieval
    Capture speed ................... instant
    Items revisited within 30 days .. 49%
    Find a specific past save ....... 88% success

Key Insight: Capture speed was equal, so the difference was retrieval; a
state for each item and a way to search it is what brought saves back.

What it taught. Frictionless capture creates a graveyard unless saved items get a state and a path back; a reverse-chronological list reproduces the surface people are leaving, however clean it looks. The status-and-retrieval model shipped, with capture left at one step.

Outcomes & reflections

In this section: Causal chain · Reflections

Causal chain (pilot, 65 users)

Capture stayed at self-chat speed, with no login and local storage, so items got saved, and the status triage plus retrieval by context and tag kept them from sinking, so the revisit rate rose from 14% → 49% against the chronological feed's 18%, and find-success in the retrieve task rose from 46% → 88%, which made the library a place people returned to and lifted day-30 retention from 41% → 60%. The optional, per-item enrichment held capture at one step while still getting context onto items, with 64% enriched after the fact, voluntarily.

Metric	Before	After	Δ
Items revisited within 30 days	14%	49%	~3.5×
Find-success in the retrieve task	46%	88%	+42 pts
Items given context after capture	—	64%	progressive enrichment works
Day-30 retention	41%	60%	+19 pts

Scale note: a saved item revisited is the only kind that ever mattered, so moving revisit from 14% to 49% turns the library from a one-way dump into something that returns saves when they are needed.

Reflections (transferable principles)

A capture tool competes with whatever surface is already open, so it has to match the self-chat's friction to get used at all; zero-registration, local-first capture is the price of entry.
Frictionless capture creates a graveyard unless saved items have a state and a retrieval path, because a reverse-chronological list reproduces the surface people are trying to leave.
Making enrichment optional and progressive keeps capture instant while making retrieval possible, since the context that makes an item findable can be added the moment it is needed, one field at a time.