Turn Favorites Into a Usable Library With Two Fields

Every product with content has a favorites feature. Users tap a heart, the item gets saved to a list, and then… nothing. The list grows, but it is never revisited. The feature becomes digital hoarding — content that is technically one click away but practically invisible.

We see this pattern often when auditing operational systems. A team builds a favorites capability because it is expected, ships it quickly, and moves on. The deeper need — helping users return to what mattered — goes unaddressed.

The cost is not just a dead feature. It is a missed opportunity to turn passive saved content into active learning, reference, or decision material. In knowledge-heavy products — training platforms, compliance systems, technical documentation tools — the gap between saving something and actually using it is the entire value of the product.

When a user saves an item, they are making a judgment: this will be useful later. But the saved item arrives in the list stripped of everything that made it useful — the reason it was saved, the context it was found in, and what the user expected to do with it.

• 14 articles about API design
• 7 tutorials on data modeling
• 3 videos about database indexing
• 2 talks on system reliability

So they do what most users do: they stop coming back.

This is not a UX polish problem. It is an information architecture problem. The list has no distinguishing dimensions, so it cannot support retrieval, prioritization, or learning.

The fix is not a better layout or a search box. It is adding the two pieces of metadata that make saved content retrievable and actionable:

1. Source — where the content came from or what kind of content it is. A video, an article, a course module, an internal doc, a conversation. This gives the user a fast filtering dimension and a way to recognize the content format at a glance.

1. Outcome — what happened when the user engaged with it. The simplest high-signal version is a binary: solved or got wrong. Did this resource resolve the problem, or did it leave you stuck?

![[[IMAGE: fig-1 | Before-and-after comparison of the same favorites feature: the left side shows a flat list of identical icon bookmarks with no metadata, the right side shows the same saves tagged with source type and solved-versus-got-wrong outcome, making the list filterable]]]()

The outcome field is the critical one. It converts a favorites list from a storage space into a learning tool. Once every save is tagged as solved or got-wrong, the user can do things they could not do before:

• Filter for unsolved items and retry them
• Review solved items quickly as reinforcement
• See, at a glance, patterns in what they struggle with
• Track whether their saved library is actually helping

There was a reason we chose exactly these two fields, and it matters more than it might first appear.

Source is a classification of the content itself. It is unambiguous — a resource is either a video or an article or a course module. There is no overlap between categories, and together they cover every kind of content the user can save. The taxonomy is mutually exclusive and collectively exhaustive (MECE).

Outcome is a classification of the user's relationship to the content. It is also MECE — a resource either solved the problem or it did not. There is no third state that matters at the level of the binary, and no gap in coverage.

This MECE property is not academic. It is what makes the system filtering-friendly and automatically maintainable. When categories do not overlap, a new save does not require a judgment call about which bucket it belongs in. Users stop hesitating, tagging becomes fast, and the data stays clean without manual curation.

Consider the alternative: a favorites list with tags like "interesting," "hard," "reference," "to-read." These categories overlap. Is a tough article also a reference? Is a to-read item also interesting? Every save becomes a small decision, and users resolve the ambiguity by skipping the tagging entirely. The feature silently degrades into the same dead list it replaced.

A typical implementation of this pattern works like this.

When a user saves an item, the save interaction prompts for two quick fields. The source can be pre-filled by detecting the content type — a video embed, a PDF attachment, a link to an article — with the user correcting it only when needed. The outcome starts as an explicit choice: solved or got wrong.

![[[IMAGE: fig-2 | Flow diagram showing a user tapping save on a video tutorial, then the system asking two questions — what kind of content is this and did it solve your problem — before the item appears in the library as a filterable row]]]()

The saved item now carries structure:

{
  "item_id": "tutorial-3821",
  "source": "video",
  "outcome": "got_wrong",
  "saved_at": "2025-11-14T09:30:00Z"
}

The library view becomes filterable table or card layout. The user can pull up all unsolved videos, or all solved articles, or everything they saved last week. The list stops being a static wall of bookmarks and becomes a queryable personal archive.

The design deliberately keeps the schema minimal. Two fields. Nothing else. More metadata categories — tags, priority, difficulty, notes — could be added, but each addition costs the MECE property and the speed of saving. For most products, source and outcome are enough to create real retrieval value.

Once this pattern is in place, the observable behavior of the feature changes.

This pattern is not universally right.

The outcome field assumes the content has a binary "correct understanding" endpoint. That works for tutorials, problem sets, documentation, and training material. It fits poorly for content that is exploratory or open-ended — a thought-provoking essay, a reference manual, a design inspiration board. If your content does not have a right or wrong outcome, a binary solved/got-wrong field will feel forced.

The source field works best when content types are genuinely distinct. If your product saves one kind of content only — say, nothing but articles — the source dimension adds little and may not justify the extra field. The pattern earns its keep when users save heterogeneous content and need a way to separate it quickly.

There is also a cost tradeoff. Every required field at save time is friction. If the fields are optional, the data becomes sparse and the retrieval value weakens. If they are required, you risk users abandoning the save action entirely. The right answer usually sits in between — pre-fill what you can detect, keep the remaining choice to a single tap, and make the fields required but fast.

If you are about to build or rebuild a favorites capability, the first question is not what icon should the button use. It is what will the user do with the saved item next week.

Worth mapping the current workflow in your product? Trace what a user does after saving content today — if the save is a terminal action, there may be an opportunity to close the loop with the same structured approach.