In Designing Search, Greg Nudelman explains that one of the most overlooked places to help users who can't find information is the page that appears when no search results are found. Greg writes,
After the system indicates that the no search results condition occurred, it must now help the customer recover. Whenever you display a no search results page, always provide a helpful way forward to get your customer back on track as quickly as possible. Virtually every control on the page should be focused on doing something to help the customer recover from the no search results condition, and any extraneous controls for filtering and sorting search results should be removed. (9)
In other words, the “No search results” page is a key place to present users with alternative ways to find what they're looking for.
It's almost impossible to get the No search results page from a Google search unless you type a fairly long strand of gibberish. More common are “No search results” pages from site searches (or from Google Custom Search, as I have on my site). If so, this is what you see:
Google's best advice is to check spelling and try different keywords.
If you're using the default WordPress theme, here's the “No search results” page:
WordPress essentially has the same response as Google: try again with different keywords, with no help at all in figuring out what the right keywords are.
(FSB, by the way, stands for the Federal Security Service, which is the counterintelligence unit of Russia. It's not something that I've covered very frequently on my blog.)
Previously, when your search query seemed a bit off, Google would ask, “Did you mean …” and present you with a more common spelling. Now Google simply corrects your bad spelling automatically:
The reason you don't see many “No results found” pages with Google is because it's likely that at least some part of your search will match one of the three trillion pages (?) on Google. But if you have an online help file, or a search box on your own website, the chances of users not hitting any results is much higher.
Ideally, when users don't find any results, rather than merely encouraging them to pick new keywords and try again, it might be more helpful to do say something like the following:
No results found. Try the following:
Actually, it would be nice to show these recommendations even when search results are found, since many times the results may not provide the answer. One issue, however, in implementing any customized search results page is that it's not always technically possible to do it. For example, now that I've integrated Google Custom Search, the No Results Found page cannot be customized (at least I don't see a way to do it).
I'm betting that customizing the No Results Found page in many help authoring tools is also a bit of a conundrum. As Robert Desprez explains in his post, Would Faceted Search Assist Your Users?, “the search engine is largely a black box that isn't meant to be significantly customized.” Desprez is highlighting RoboHelp, but only as one example of the many black box search engines in help authoring tools. Even if you were to customize it (it would probably involve hacking the source files), would every new release of the help authoring tool simply overwrite your customization?
Mark Baker points out that because search in help authoring tools is so poor, it's often easier to find content using Google's search engine instead, even if this means that searching trillions of web pages instead of narrowly focusing on specialized sites. Baker explains, “I get better results by searching the haystack than the needle case, even when the needle I want is in the needle case” (see The Best Place to Find a Needle Is a Haystack).
In this case, you're stuck with a dilemma: If you go the Google route for search, the results are better, but you can't customize the search results page. If you stick with your native app, you can perhaps customize the search results page, but the results are poor.
Even with these technical limitations, I think it's a good idea not to give up, because there are workarounds for the technical limitations. The key idea is that successful search involves knowledge of keywords, so when users aren't aware of those keywords, we should help them figure them out (rather than just inviting users to randomly guess new ones).
One strength many help authoring tools have is the ability to integrate keyword synonyms into searches, so that even if a user doesn't realize, for example, that "reserve a resource" is the correct keyword phrase, we can equate the terms on the backend so that a more familiar search for "schedule a room" returns results.
This doesn't guarantee that the search results will now be on par with Google, though. Reason being, Google has a lot more content. Your help content must actually include the answer the user is searching for. Many times these answers aren't in the help in the first place. I wrote about the issue of scope earlier in a post titled, Faulty Assumptions About the Scope of Help Content.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.