A demo search often starts with a query the builder already knows will work. A more useful test starts with a person who remembers the purpose of a resource but not its title.
Here is a small test plan I would use before adding complexity to a personal search tool.
Prepare a realistic collection
Ask a participant to save five to ten resources they genuinely care about. Include a mixture of formats if the product supports them: an article, a screenshot, a link, or a note. Let them add context in their normal words.
Return later rather than testing immediately after saving. The delay is part of the task: the interface should help after the title has faded from memory.
Ask for an outcome, not a query
Instead of “search for onboarding,” ask: “Find the example you wanted to use for your project's welcome screen.” Let the participant choose their own search terms.
Record the first query, any reformulations, which results they inspect, and whether they identify the right resource. Ask them what makes a result look relevant. A result can be retrieved correctly and still be hard to recognize.
Diagnose the failure layer
If the resource never appears, investigate which searchable fields were available. If it appears but is overlooked, examine the title, preview, and saved context. If the user finds it but cannot reuse it, the destination or source may be the problem.
Those are different failures and need different changes. Improving ranking will not repair an unreadable result card.
Repeat after one focused change
Try a change such as exposing the user's note beneath the result title. Use another retrieval task and compare observations. With a small exploratory test, treat the outcome as a design clue rather than a population-wide performance claim.
Némos's “can you find it again?” prompt is useful because it shifts attention from how much we save to what saving lets us do later.
Top comments (0)