Enterprise Search Development: Start With the User Interface

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.

Metadata

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.

Snippet Options

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.

Usability

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.

Accessibility

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.

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.