Search and browse need coexisting entry points

What it is

In a single session people switch between typing and walking. Bates’s berrypicking path was never a single strategy; Hearst treats a search user interface as a search box and a browsable structure that must both be present. Search and browse need coexisting entry points is not a product-positioning choice (“we are a search product” vs “we are a nav product”). On the screen where finding starts, both the box and a browse path must be visible and usable, and switching strategies must not dump the context already earned.

Offering only one is deciding in advance which kind of clue the user holds. That decision cannot be made correctly before the task begins.

Why it happens

In the first second people often cannot tell whether they are in a known-item state or an ASK state. Clue strength reveals itself in motion: a missed search shows the name was wrong; two scentless browse levels send them to typing. Switching cost depends on whether the other entry is still there and whether context survives. Hide search in a hamburger and known-item users pay a navigation tax first; remove categories and keep only search and people who cannot name a term have nowhere to learn the collection’s language.

Coexistence is more than two controls on screen. Jumping from browse into search should carry the current category as a removable scope; jumping from search into browse should show which classes the hits fall in. Otherwise a switch is a restart, and constraints just built in working memory are zeroed. Entries also need to be stable: search on some templates and not others prevents the habit “finding starts here,” and predictability drops.

Studying it

Watch strategy switches; do not score search tasks and browse tasks separately.

• Paradigms: a batch of real tasks with no pathway restriction, logging first move, post-failure switches, and whether context is kept; in logs, tag “search launched from a category page” and “category jump from a result list” as cross-strategy events. Hearst’s SUI evaluations treat entry visibility as an interface variable.
• Independent variables: whether search and browse share a viewport, whether a switch keeps the query or the current class, whether one entry is collapsed.
• Dependent variables: switch count, whether the user retypes after a switch, time to complete, whether failure is attributed to “no entry” or “the entry is on another page.”
• Methodological note: labeling lab tasks “please search” or “please use the menu” cancels strategy choice and cannot test coexistence. First moves in the field mix habit with visibility; record whether the entry is above the fold, do not only report “users prefer search.”

Where it stops holding

Single-object tools (flashlight, calculator) have no browsable collection and nothing for a box to hit; coexistence does not apply. Strongly linear flows (checkout, account opening) have a “next step,” not a finding strategy; stuffing search into a stepper scrambles the process. Expert tools whose tasks are known commands can let a command palette dominate browsing, but an occasional exploratory entry should remain rather than deleting collection structure from the product. On a very narrow mobile first screen, coexistence is “one primary entry plus one that is one hop away,” not two equal-width controls fighting for space.

Applying it

• On the main finding surface, place a search box and at least one browsable structure together; do not hide either behind a page that can be reached only by completing the other strategy.
• Across a strategy switch, keep constraints already in hand: search within the current class, see class distribution for the current query; each constraint must be removable on its own.
• Keep the global search entry in a fixed place so the habit can form; avoid templates that sometimes have it and sometimes do not.
• Verify with real tasks that do not prescribe a strategy, and watch the move after failure. If people go hunting for the hidden entry or restart the search, coexistence did not happen. If they can change strategy in the same viewport without restating known constraints, the entries are actually present.

Related

• Within the group: G3.01.1 Known-item lookup is faster through search than through browsing · G3.01.2 Browsing supplies a discovery space when the goal is still vague
• Adjacent: G2.08 Predictability of navigation items · E2.10 Search fields · G3.02 Query formulation
• Search terms: search versus browse · search user interface · information seeking