Search on intranets has become a little box of desperation. We need to move away from thinking of enterprise search as being a single search box on the top right of our intranets. Instead, we should offer dedicated search experiences tailored to specific tasks. The result is that the user should see search boxes appropriate to the context of what they’re looking at in different places across the intranet. The technology to do this already exists, so there’s a big opportunity to improve results by a little more effort on the user experience side.
Gerry McGovern points out that we don’t search for “Cheap flights” anymore, but tend to use dedicated search tools like Kayak. For intranets, is our model like Google search for our internal web, or more like a product search within Amazon? This distinction matters: We know Google only indexes a small percentage of the internet (even generous estimates put it at 12%), but we expect Amazon to index every one of its products. Often, people expect intranet search to be like both Google and Amazon, and are disappointed with the results. A 2013 Findwise survey of Enterprise Findability reported that in 64% of organisations it is ‘difficult to find information’.
The thing is, most intranets are far bigger than most websites; enterprise intranets contain millions of pages and documents. Even where websites are very large, they tend to be mono-task sites – databases of items for retail, or reference, such as the US Library of Congress. Intranets are more diverse in the kinds of content they have to retrieve. Websites that become so diverse struggle as well – as anyone stuck in a perpetual loop of Microsoft domains and re-directs will know. Technology improvements such as Microsoft’s Office Graph and Delve (previously known as Oslo) will help people discover content they might like, but we also need to support pro-active searching too.
What we need is a more layered approach to enterprise search – more like finding Kayak on the web and then using the dedicated search experience to refine our flights. SharePoint, for example, has sophisticated options for search refiners that allow nuanced searches on a large library of sales material, picking out only brochures or those for a specific product. This means that individual site owners can create their own search boxes just for a specific set of content. Not everything has to come through the top-right search box.
Crucially, the language of the search interface is specific to the content, just as Kayak talks about flight duration and stopovers. Most users have unsophisticated search skills so they need this level of support. Site and content owners are the people best placed to know what that language should be. For example, different parts of the organisation may talk about ‘suppliers’, ‘third parties’ and ‘partners’ all meaning the same thing.
We do see this kind of dedicated search experience occasionally – but it tends to be inadvertent in the enterprise: when one set of data is held in a stand-alone repository, like a Document Management System (DMS), so has its own search tool. The downside is the DMS’s existence and content tends not to be indexed at all by the enterprise-wide search engine, and the way it presents results can be entirely inconsistent.
Ideally, it is site and content owners that should be driving findability. Their work doesn’t end when they upload content; they need to ask ‘what should I do to ensure people can find what they need?’.
We should design search interfaces and functions that are specific to different tasks, rather than one big search box of despair.