G3.01.2exploratory searchdesignresearch

Browsing supplies a discovery space when the goal is still vague

Aliases: exploratory browsing · berrypicking · vague-goal finding

What it is

When the user cannot yet say which item is “the one,” they are in Belkin’s anomalous state of knowledge (ASK): a gap is felt, but no query would hit the target. What helps is the discovery space that exploratory search and browsing provide—visible classes, neighboring items, and the words other people use for them. “Something for a damp balcony” is not a product name; “the stuff about remote work” is not a document ID. Browsing spreads the collection so examples can turn a vague need into a nameable one.

A discovery space is not a decorative recommendation wall. It stands in for a query that has not formed yet, using visible structure instead of keystrokes.

Why it happens

A query works only if the user already shares vocabulary with the index. Under ASK that shared vocabulary does not exist: the internal description is situation and constraint (damp, balcony, sit-able); the index holds class and spec (outdoor chair, rust-resistant, IP rating). Forcing a search yields empty sets or accidental literal hits, and the feedback never teaches “what language this collection speaks.”

Browsing and topical exploration slice the collection along scannable differences. Instances in a neighborhood supply labels for the next query—Bates’s berrypicking describes finding as a path that keeps changing words and direction, not one question and one answer. Information scent here judges “this region is still worth staying in,” not “this row is the target.” Without a stay-able neighborhood, exploration collapses into empty punches at the search box.

Berrypicking needs glimpsable neighbors. Compressing exploration into “please enter keywords” demands that the user already possess the product of exploration (a precise query) in order to start exploring.

Studying it

Write tasks as needs the participant cannot yet name; do not issue a target title.

  • Paradigms: Marchionini-style exploratory tasks (learn a topic, compare options); process traces of Bates berrypicking (each query, each category jump, each rephrasing); ASK interviews that elicit the gap, then watch whether the first move is search or browse.
  • Independent variables: presence of a browsable topical neighborhood, whether neighborhood labels come from user language or internal codes, whether neighbors are visible beside results.
  • Dependent variables: steps before the first typeable term is uttered, whether that vocabulary was learned from interface labels, whether the session ends with an account of what was chosen and why.
  • Methodological note: evaluating an exploratory interface with known-item tasks will score discovery as inefficiency—the participant was never supposed to wander. High query counts are a normal berrypicking strategy, not failure. Logs that store only the final submitted query drop the learning that browsing did before any query existed.

Where it stops holding

Under extreme time pressure, people type the coarsest word and take the first hit; browsing’s discovery value never has time to land. If items have no intelligible differences (identical appearance, repeated labels), spreading them still does not make a neighborhood, and exploration gets lost. In compliance or safety settings, glimpsing a neighbor one should not see is a leak; the discovery space must be clipped by permission, not treated as an unfiltered display. When experts already hold a precise query, forcing a browse layer is a tax.

Applying it

  • For tasks that cannot be named, provide scannable entries—theme, situation, constraint—not only an empty search box.
  • At each browse node, show a few real instances and the words they are called, so the next query has terms to borrow.
  • Keep the neighborhood already seen (breadcrumbs, selected themes) during exploration; clearing context on every click severs the berrypicking path.
  • Verify with people who cannot yet name the target and with no canonical name on the task sheet: can they utter, from the interface, the word they later search with. If the word came from a label, the discovery space is working; if it had to be known in advance, browsing is just another row of links.

Related

  • Within the group: G3.01.1 Known-item lookup is faster through search than through browsing · G3.01.3 Search and browse need coexisting entry points
  • Adjacent: G1.02 Organization systems · G1.04 Labeling systems · G3.10 Faceted navigation
  • Search terms: exploratory search · berrypicking · anomalous state of knowledge

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/G3.01.2