Start with the user interface (UI) and work backwards. That was the advice I shared with search managers developing their existing application or planning a new application during an enterprise search workshop at the recent IntraTeam event in Copenhagen, Denmark. Sinequa recently sent me some examples of user interfaces from its customers (thank you Laurent Fanichet), which showed the variety and inevitable complexity of enterprise search UIs. Too often businesses make a deliberate choice on the technology and give little thought to the UI (so much for the ethos of user-centric delivery!).
The topics outlined below cannot be left to the implementation stage. Most search applications (with the obvious exception of Office 365) are UI neutral and can support almost any UI development language. Early work around these topics is essential, even at the specification stage, to ensure the investment is fit for purpose, not just to specification.
Enterprise information collections are much larger than might be imagined and inevitably contain many near-identical documents. HR and related corporate policies are just one example of this. So delivering the "most relevant" document in response to a query is limited at best.
The rhetoric of personalization through AI usually fails to deliver for two reasons: First, it assumes the user is seeking the information for themselves. Second, AI works on the basis of prior searches, but many of the searches will be by people who are new to an organization or role.
Provide users with filters and facets so they can refine a set of results. But keep in mind, providing filtering just by file format and last revised date is a waste of screen space. Ask people how they might want to filter (e.g. country, date of publication, department, language). With that valuable information in hand, work out how the metadata to drive these filters is going to be derived — either from the text of the document, through tags or a combination.
Related Article: Using AI for Metadata Creation
Quite a lot of work has been undertaken into the format of snippets. One size does not fit all. This is especially the case in enterprise search where the primary assessment of results is through information foraging. The format of the result and what ancillary information can be switched on or off by the user is important to consider. For some searches an expanded snippet with highlighted query terms might be invaluable, but this will limit the number of results displayed per page.
Designing search pages that scroll is a seriously bad idea. Even if the results are scrolled, the ancillary filters and facets will remain stationery, and in any case people will want to see the results in the context of a page of results. When usability testing happens later in the project, it will start with a discussion about which elements of the UI have been the subject of continuing discussion without a clear resolution and need real-life testing.
In the digital workplace, accessibility is very important as there will be few workarounds. At the outset you should be working with accessibility consultants to consider how voice browsers will work with the proposed UI and what the implications are for staff on the dyslexia spectrum.
Related Article: We Need to Build Accessibility Into Our Digital Workplaces
Federated Search/Multilingual Search
The current interest in presenting the results from multiple repositories seems to ignore the challenges in how to present the final results. When there are only two applications (or languages) then two windows might be the best option, but as the number increases so does the complexity of the user interface. This becomes even more acute when results from text searches need to be interleaved with results from enterprise databases.
Training and Support
No matter how well you design a user interface, enterprise search is never going to be intuitive. This is due to the variable quality of the content and the metadata and the wide range of queries. Any discussion about a search UI has to take into account the extent to which training might be required for one or more aspects which will be a challenge to use.
Related Article: When it Comes to Intelligent Search, Don't Expect Magic
Help and Feedback
I rarely see well-designed search help pages or the option to provide contextual (not just, "did you find what you were looking for?") feedback to the search team. In project after project, people tell me they have no idea who is responsible for the search application and no easy way to find out. The search team (even if just one person) must be visible, and receptive to comments about the gaps between expectations and delivery.
See How Others Are Handling Search Before You Design
If you want to get a sense of the problems and options, take a look at the web search pages of EY, PWC, Navigant, Bain, Accenture, Guidehouse and others now that you have read this article and make your own judgements.