The website has a search box, yet staff still send people direct links. Before buying a replacement, find out what users search for and why they fail to reach the right material.
The problem may involve search behaviour, document names, outdated content or a missing page that actually answers the question. Separate those kinds of work in the budget.
Build a set of real queries
Collect examples from support staff, editors and users. If search data is available, include queries that return no results. Remove personal details and any information unnecessary for the test.
For each query, record the expected result. Someone searching for “change appointment” may need instructions rather than a policy document where those words happen to appear.
Define where search will look
| Area | What to establish |
|---|---|
| Web pages | Which content types belong in the results? |
| Documents | Are filenames searched, or the contents too? |
| Archive | How are older items distinguished from current material? |
| Multiple sites | Can a result lead to another branch's website? |
Add the required filters and result presentation. Each additional source needs checking for access and updates. Searching a collection of documents can involve different work from searching ordinary pages.
Check quality with examples
Agree the query set and evaluation approach before implementation. Check whether the right answer appears where expected and whether its title and description make it recognisable. Review the no-results experience separately.
Finally, decide who monitors problems after launch and adjusts content or settings. A useful search quote describes specific sources and work rather than merely providing a field with a magnifying-glass icon. Keep the query set for later reviews so you can see whether improvements actually help users find the answers they need.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database