H8.13.3empty search diagnosisdesignresearch

Empty results need causes other than a narrow query

Aliases: why nothing was found · search miss reasons

What it is

When the box finds no match, the usual line is “the query is too narrow, broaden it.” In one’s own library, empty results have a set of equally common causes: the object is in trash or archive, the wrong space is selected, no permission, the field set missed the body, spelling differs from the title, it still lives in someone else’s draft. The empty state has to spread those possibilities and offer tappable changes, not only “try a shorter word.” A site-search zero-result page is another layer. Here it is personal or team locate failing for reasons besides the query itself.

Why it happens

Empty is read as “does not exist.” If the real cause is permission or space, people recreate, duplicating, or assume deletion and blame a colleague. Diagnosis splits “no hits” into testable hypotheses: another space? archived? body not in the field set? Each hypothesis maps to an act (switch space, include archive, widen fields), not an inactionable consolation. Offering only “broaden the keywords” blocks those acts. Diagnosis also has to be honest: do not invent causes the system cannot know. If the current filter excludes archive, write “n archived not included.” If it cannot know about same-named items outside permission, do not pretend “the whole library was searched.”

Studying it

Place the target in archive, in another space, behind no permission, in body-only, with a correct query. Compare an empty state that only says not found with one that lists switchable causes and entries.

Independent variables: whether non-query causes are listed, whether each cause is a one-tap scope change, whether excluded sets are counted. Dependent variables: whether the path detours successfully to the target, mistaken new duplicates, still only editing the query.

If the lab lets people wander navigation, empty-state diagnosis is bypassed. Start from the empty state. A spelling-correction hit is still query-layer, not diagnosis success.

Where it stops holding

Gibberish or a still-being-typed query should not dump archive and permission lists. Cross-org content is invisible by design; diagnosis must not hint “maybe another company.” An encrypted library cannot confirm “there is a same-named item you cannot see”; say “only what you can open was searched.” If results are not actually empty and a front-end filter hid them, fix the filter rather than write empty copy.

Applying it

  • List non-query causes that apply to this library: space, archive/trash not included, title-only fields, only what you can open.
  • Each cause has an act: include archived, switch to workspace X, search body.
  • Count exclusions when you can; do not invent a guarantee when you cannot.
  • Verify: put a file in archive, search the correct title. People should reach Include archived from the empty state and retrieve, not create a second copy. For an item they cannot access, the empty state must not claim it does not exist.

Related

  • Within the group: H8.13.1 Search must say whether it covers title, body, or metadata · H8.13.2 Recents and frequents are a path besides search · H8.13.4 Near-duplicate names need extra cues to tell them apart
  • Adjacent: G3.07 Zero-result Handling · H8.14 Content Lifecycle and Archiving · H3.08 Soft Delete and Trash
  • Search terms: zero results · empty state diagnosis · search miss

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H8.13.3