If you’re using a search solution on your website (Ask Jeeves, EasyAsk, Google, Inktomi, Mercado, Verity etc) or simply offer a search interface that users can use to find products, information or documents with, you may be missing the main feature that will make it work (and give you the return on investment you want): Search Interface and Search Results Usability.
Typical Issues
The search interface runs into these typical problems that most people don’t consider when shopping for a search solution:
1) Search Interface: how the database works typically defines how the search interface will look (see the “Boolean logic” and “Natural Language” issues below)
2) Search Results: how the user configures the search is going to determine how great the results are. Also how the search database works will determine how *robust* search results can be displayed. Displaying search results in a readable, understandable and helpful manner is instrumental to designing the user experience effectively.
Search appears to be perceived as a highly valuable resource by users and marketing managers as an essential “help” feature on a website. As many of my clients can attest to, finding a good search vendor is a bit of a headache. One of the big issues is the feature many search vendors sell called “Natural Language Search”.
Question: What is Natural Language Search?
Answer: Natural Language Search (NLS) is a more robust version than standard “Boolean” searching. Boolean logic says “And this, Or that, Not that” such as with this search interface http://search.internet.com/ (Probably the worst search interface on the web?) In that example the interface exposes the *needs of the database* e.g. you must enter this and that but not that…. the problem with *exposing Boolean logic* parameters to the user is that if they get it wrong, they may end up with nothing or something off-topic.
NLS really is a back-end feature. NLS database matches “fuzzy” records in the database so users can type “What’s for lunch?” and get intelligent results back (supposedly). Ask Jeeves is the classic example (though it is not that great to put it mildly). Google of course has perfected it and Amazon too…but those are very expensive databases used by those two companies.
The main usability question to ask when reviewing a search vendor or evaluating the user experience of your own search solution is, “Can you customize the results?” and “Can you simplify the search interface?”. Those two things matter for ease of use and value to the user. Search Results are as important as the interface.
I noticed Amazon is “culling” search results more…so that if you search “Interaction Design” on Amazon they cut it to 2 top results and then “View 230 others”. The search rule system is imposing something onto results to prioritize them by popularity (or other variables).
Question: Why is it that when I want to find a Starbucks in an unfamiliar place, Starbucks store locator search is useless?
Answer: Starbucks coffee shops occupy multiple addresses in the same area of town across the country. When a colleague you meet wants to have coffee and says: “Meet me at 1134 NW Glisan (Portland, OR) Starbucks” (more specific then meet me at the one Downtown on 3rd for example), when you type in the address it gives you: two in the area, and then, a list with details for 163 stores in the entire city. Even when reducing the default 5 mile radius to two miles, it acts the same way. The Glisan store is on one of the 20 pages of search results! (try it for yourself)
The database is not matching inputted data to the store details page. Instead, it is serving up all results based on geographic data. Result: annoying and unhelpful. Possible solutions include filtering results to match address to actual store pages; adding semantic data to the result (e.g. “across from the Library”); allowing users to search with visual maps of the city and filtering stores based on simple user selection (as in the example below). Starbucks unhelpful search has caused me: to go to the wrong store; pick up the phone and call to confirm; trade 3-4 additional emails to confirm (with the business person I am usually just meeting for the first time). read: hassle
Successful Implementation
Here’s an example of a successful search implementation:
My client used a Boolean search interface before with a 94% search failure rate during usability testing, we changed it to this one, leading to a 44% increase in registrations, two months after the change in search interface and search results usability.
Quote this as: (2003) Spillers, Frank. Web Usability Best Practice Handbook. Experience Dynamics.
Learn more, request a Usability Testing training
See our Usability Testing services
