Digital products ·
Site search should recognise the visitor’s task
A visitor may know a product code, remember its purpose or look for a document using a single word. They use the same search field but expect different results. Designing site search begins with those differences: what records exist, how people describe them and what helps them choose.
Gather queries with an expected answer
Start with a manageable test set: an exact name, product code, familiar abbreviation, task and misspelling. Enquiries to the team and existing search logs can provide examples. Without that evidence, use clearly labelled test scenarios rather than claiming they represent customer behaviour.
In a hypothetical hardware catalogue, someone might search for a code, “shelf fixing” or a material. Identify suitable records for each scenario before building the interface. That makes quality testable and gives a discussion about relevance something concrete to work with.
Prepare the records first
Search depends on names, descriptions, categories, specifications, codes and availability. A new field cannot repair dimensions buried in an image, inconsistent naming or obsolete records. A catalogue owner needs to define required fields and responsibility for maintaining them.
Synonyms need similar care. A customer’s term may differ from an internal name, and connecting them can help. An overly broad match can also mix incompatible products. Check model identifiers, units and variants separately: similar names do not establish interchangeability.
Make results distinguishable
An exact code should lead to its record. A broad task may need several options with useful specifications. Discuss ranking through examples: when does the name matter most, when the category, and when availability? Keep conditions that prevent an order visible.
A result should explain itself before the click: record type, concise name, relevant specification and an image where useful. When products, manuals and articles appear together, label their roles so a visitor knows what will open.
Let filters refine the query
The field accepts a person’s words; filters narrow structured attributes. Preserve the query when a category or size is selected and show active constraints. Otherwise disappearing results can look like a failure.
On a phone, test returning from a product page: are the query, filters and list position retained? This matters when comparing several options. Give the field an accessible label. W3C’s guidance explains how a label can remain available to assistive technology when visually hidden.
Empty results still need an answer
No matches may mean an unavailable item, unfamiliar wording or a restrictive filter. Show what was searched and offer a relevant next step: remove a constraint, browse a category or ask the team. Do not disguise an exact search failure with an unexplained assortment.
A failed request is a different state from a successful search with no matches. Explain when search is unavailable and preserve the query for a retry.
Test the route to the next action
Run the test set with someone who knows the catalogue and someone who does not. Record useful matches, difficulties and whether they can reach the right record or enquiry. Resolve specific mismatches before adding sophisticated suggestions.
Measurement can distinguish empty results, result clicks and subsequent actions. Search volume alone does not establish value. Queries can contain personal information, so decide what may be retained and who can read it.
As part of [website development](/en/dialogue), I can help define the fields, tasks and acceptance criteria for a catalogue search. Bring representative records and visitor tasks rather than an instruction to imitate a large marketplace. The complete sales journey is covered in [the online store article](/en/apocrypha/online-store-development).
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.