Data and Business Systems
Build search around the questions users actually ask
Search quality depends on the job behind a query. Separate exact record lookup from exploratory discovery, test real wording, and make result context, filters, permissions, and empty states part of the design rather than afterthoughts.
A coordinator searches for a request number. A technician searches for a symptom. A manager searches for overdue work at one site. These are different questions, even if the interface offers one search box. Define the questions and the expected result before deciding whether keyword search, filters, or a more complex engine is necessary.
Collect tasks, not only query strings
Ask users what they need to do after finding a result. Record the words they use, the fields they know, and what makes a match trustworthy. An exact identifier should lead directly to the intended record. An exploratory query needs context that helps distinguish plausible alternatives.
Create a test collection with relevant results and deliberately similar nonmatches. Include abbreviations, old reference numbers, punctuation, and common misspellings when they reflect actual work. For bilingual operations, test both languages rather than assuming one configuration handles every vocabulary equally well.
Choose matching behavior by field
PostgreSQL full-text search normalizes text tokens into lexemes, allowing different word forms to share a searchable representation.[6] That behavior can help prose search. It should not automatically govern identifiers where a changed character means a different record. Choose exact, prefix, or text matching according to field meaning.
Recommend visible filters for structured conditions such as location, owner, or current state. Explain whether a filter combines with the text query or replaces part of it. Keep an accessible reset path so an old filter does not quietly hide the record the operator expects.
Hypothetical example: finding a maintenance instruction
A hypothetical service desk stores approved maintenance instructions and historical request notes. A technician searches for a pump symptom. Results label document type, equipment class, approval state, and revision context. The approved instruction is distinguishable from a customer note containing similar words.
An exact instruction code uses a separate lookup behavior. When no eligible instruction matches, the interface offers a route to the technical owner rather than presenting a historical note as guidance. This requires curated metadata, but it makes relevance a business decision instead of an unexplained ranking score.
Test visibility and unsuccessful searches
OWASP recommends permission validation on every request.[4] Apply record access rules to search results and subsequent downloads. Check whether counts, snippets, or suggestions reveal restricted information. Do not assume a protected detail page makes an unrestricted search preview acceptable.
Search has tradeoffs between broad recall and precise results. Broader matching may find more candidates while increasing review effort. Start with a repeatable task set and inspect failed searches with users. Add complexity only when it solves a demonstrated retrieval problem, and avoid retaining sensitive query content without an explicit purpose. Observe whether users can explain why a result matched before changing its ranking.
- Separate exact lookup from exploratory text search.
- Test representative queries and similar nonmatches.
- Show record type, state, and identifying context.
- Verify filters, empty states, and reset behavior.
- Check permissions for results, snippets, counts, and downloads.
