如何設計讓未來的自己找得到的書籤記錄

A save button creates a record. It does not answer the question that comes a week later: “Where was that example I wanted for the onboarding screen?” For a personal knowledge tool, that question is a useful starting point for the data model.

Store the reason alongside the resource

Consider this proposed record:

{
  "title": "A useful onboarding example",
  "source_url": "https://example.com/onboarding",
  "saved_for": "Compare welcome screens for my side project",
  "intent": "use",
  "keywords": ["onboarding", "welcome", "side project"]
}

The URL identifies the resource. The other fields describe its relationship to the person saving it. Keeping those concepts separate means a later change of project does not require changing the source itself.

Do not make every field mandatory. If capture becomes a form-filling exercise, people will skip it. A reasonable first version accepts the resource immediately and offers one optional prompt: “What will you use this for?”

Show the context in search results

Storing the note is only half the work. Put it beside the title when presenting results. Two nearly identical article titles become easier to distinguish when one says “for the pricing page” and the other says “for the client workshop.”

Treat automatic labels as suggestions. Keep the user's own note available for editing, and avoid silently replacing it with a generated summary.

Test retrieval rather than collection

Ask someone to save five real resources. Later, give them a task that needs one of those resources, without reminding them of its title. Observe the words they search for and the result they choose.

The useful outcome is a resource they can confidently reuse, not a bigger collection of saved links.

This is one of the product questions behind Némos: how can a saved item keep the context that made it useful?