Should a search suggestion change the query before the visitor selects it?
A catalogue visitor typing “table” may not intend to select the first product that appears below the search field. Suggestions can reduce typing, but showing an option and accepting it are different actions. This guide addresses the suggestion list that opens while someone types, rather than a no-results page shown after a search. The furniture catalogue below is hypothetical, not a reported client usability test. The selected furniture tile on the cover is a conceptual illustration of this interface decision.
1. Define the job of a suggestion
A search field might suggest a category, product name or model code. Selecting one could complete the query, open a results list or navigate directly to a product. Decide which action belongs to each type instead of mixing them invisibly. For example, “Tables” can identify a category while “Table M-24” identifies a specific item. If similar-looking rows lead to different destinations, a short type label can help explain them. Write the expected behaviour using two actual catalogue examples before deciding how the list should animate or look.
2. Choose manual or automatic selection deliberately
W3C’s combobox pattern distinguishes manually selected list completion from automatic selection. With manual selection, the typed query remains the value unless the user accepts a suggestion. For an open-ended catalogue search, we recommend explicit acceptance as a starting point, rather than assuming every field requires it. A visitor who types “table” should not unexpectedly find another product name when moving away. Where automatic selection is appropriate, record the reason and make the selected state clear. A highlighted first row should not conceal an unexamined decision about the field’s final value.
3. Test continuing and backing out with a keyboard
Type a query, move through suggestions with the arrow keys and close the list without accepting one. In the W3C pattern, Escape dismisses an open popup and Enter can accept the selected suggestion. Verify the consequences in the actual implementation. Closing suggestions should not unexpectedly erase the query. Keep keyboard focus visible and preserve ordinary text-editing keys. A successful mouse click is only one interaction path; it does not establish that someone can explore alternatives, reject them and continue searching without a pointing device.
4. Try a narrow screen and delayed responses
With the mobile keyboard open, check that suggestion rows remain visible and can be selected accurately. Then change the query quickly: a late response for “table” should not overwrite suggestions for a later “lamp” query. This is a development test scenario, not a proposed universal latency target. Try an empty field, a single suggestion, no suggestions and a long product name separately. Check whether the open list extends beyond the screen or blocks essential controls. Record the actual device and conditions rather than presenting a desktop resize as exhaustive mobile testing.
5. Write acceptance criteria around finding a product
A sample task is: “Choose M-24 from the suggestions, then search for a lamp without using a suggestion.” Observe the behaviour without first telling the participant which keys to press. Check preservation of the typed query, the destination of an accepted item and the ability to dismiss the list as separate outcomes. The no-results guide covers the next step when a search finds nothing. Include this interaction explicitly in the website design scope. Suggestions should help people reach the right product rather than simply add another animated feature to the page.
Frequently asked questions
Does every search field need suggestions?
No. A small catalogue may work well with a clear search and results page. Identify the task suggestions would improve before adding them.
Does highlighting the first suggestion mean it is selected?
Not necessarily. Visual highlighting, keyboard focus and the accepted value need an explicit relationship that is tested in the implementation.